使用指南

怎么让 ChatGPT Dot 指挥 Codex？委派任务、隔夜提 PR、批准卡住和 94 个真实案例

ChatGPT Dot 可以替你开 Codex 线程、夜里跟进、在手机上汇报，合并和部署仍然等你点头。这里有 94 个开发者的真实案例，还有批准传不到任务、CloudThreadNotFoundError、Codex Cloud 上的 UNKNOWN、找不到本地项目的解决办法，以及 Codex 额度的消耗情况。

GPT Dot · 更新于 2026-10-17

先看结论：能做什么、怎么设置、会卡在哪里

一句话结论

部分可以。让 Dot 当 Codex 的协调人，现在已经做得不错：它会替你开线程、把要求交过去、你不在时跟进，再告诉你哪些已经可以看了。Kurt Bell 一觉醒来，bug 已经修好，还有一份早报；Eduardo 出门吃饭时，Dot 合并了 16 个 PR；余佳恆现在把读工单、拆任务和合并都交给 Dot，Codex 只负责实现。但要把 Dot 当成进入 Codex 的唯一入口，现在还不够稳：你在 Dot 对话里给的批准常常传不到任务里，你自己开的 Codex 线程它常常接不上，它在你电脑上开的任务也可能拿不到你自己的 Codex 会话里有的 MCP 工具和 AGENTS.md（案例 73、74、84、87、89、93）。如果你已经在用 Codex，愿意让 Dot 来开任务，合并和上线由自己把关，也不介意偶尔打开任务亲自批准，Dot 会很合适。

怎么设置

创建 Dot（见上手指南），再从桌面应用连接这份工作要用的电脑和应用（见连接电脑和应用）；代码仓库怎么连，请看 Dots 连接 GitHub。在那台电脑上登录 Codex，并允许远程连接。soloist 的 Dot 一度只能在自己的云电脑上开发，polaris 给出的就是这个解决办法。
想好每件活在哪里跑。新建本地任务时，那台电脑要保持在线，并开着 ChatGPT 应用。云端编程任务跑在你事先建好的 Codex 云环境里（包括仓库和配置），这时你的电脑可以关机。Dot 自己的云电脑不能作为 Codex 任务的运行目标，所以 u/dry_towelette99 第一次发起任务失败了，连上一台闲置的 Linux 电脑以后才成功。之后再给 Dot 换选定的电脑，已经存在的任务不会跟着搬过去（见任务与记忆）；Mete Polat 还发现，自己的电脑一次只能配对一台（案例 93）。
先做一次小测试：「列出 [仓库] 里我还开着的 Codex 任务，先别新建。」之后的新任务，尽量让 Dot 自己来建。在 Takanashi-Rikka1 的测试里，Dot 自己建的任务之后能读取和跟进，手动开的线程却读不出来。要把已有的线程交给 Dot，就点名是哪一条、要改什么，并让它先只读一次试试。
每个任务都按同一套方式交代：仓库、项目、目标、验收标准和在哪里跑，一个任务只放一个目标，并约好汇报时间。项目要在开工前说好，因为 houmark 事后把 Dot 建的对话移进项目没有成功。如果你的工作依赖 ~/.codex/AGENTS.md 或操作手册，就让每个任务先读一遍；SmithLabsLLC 的任务就是这样恢复正常的（案例 87）。
一开始就把规矩定好：每个修复都要测试，只开草稿 PR，合并、上线和删除都等你点头，Kurt Bell 和 @bezzabuilds 的通宵任务就是这样跑的。默认用哪个模型也要说清楚，因为 Alp Z 只提过一次某个模型，Dot 就把它当成了默认设置（案例 82）。
通过「活动」（Activity）跟进。在桌面应用里打开 Dot 的个人资料，选择「活动」，再打开某个任务，就能看到进度、文件和结果；任务在等你做决定、登录或批准时，直接在那里回复（见管理你的 Dot）。人不在电脑旁时，让 Dot 在 Slack 或短通话里给你一份状态清单或早报，也可以像あやみ那样，让 Dot 维护一张任务表（案例 92）。

常见卡点和解决办法

在 Dot 对话里给的批准，传不到任务里。Dot 转过去的批准，任务的审核会当成不可信的文字，哪怕一字不差也一样（gro83j、moruku36，案例 73、89、93）。解决办法：从「活动」里打开那个任务，在任务里直接批准，cedar_circuit 和 moruku36 都是这样通过的；一次只批准一个具体操作，把完整草稿、收件人和附件一起交过去；如果任务接着停在「approval policy is never」，就去检查这个任务的已连接应用权限，OpenAI 支持团队告诉 nickcaracappa，这项权限和 Dots 的访问权限是分开设置的。菜单里勾了完全访问（Full access），Dot 的下一轮也不一定真有这个权限（Azad-Zhang），所以长时间工作之前，先让任务报出它实际拿到的权限。同一条转达也不要反复重试：progressorZ 的重试就被当成了绕过上一次拒绝的尝试。
任务看着很慢，其实是在等人。まー的活经过 Dot 好几个小时没有进展（案例 75）；Eliot 得逐个线程去催、去批准（案例 73）；COOLak 的权限卡最长等了约 26 分钟（案例 86）；Kamimoto 的 Codex 安装失败了，直到他问一句「进度呢？」才被发现。有用的做法：每件活约好汇报时间，状态清单里写明「等你批准」，而不是一律写成「进行中」（Senple，案例 91；Kentaro Mori）；再让 Dot 维护一张任务表，状态一变就更新（あやみ，案例 92）。记得明确要求它自己去更新，因为 itsplayai 发现，不交代的话，它只在被问到时才会改。
任务从侧边栏消失，或者进了错误的项目。这些报告里，活本身都没有丢：houmark 的对话没有归进项目，Chase 的任务落在了「最近」（Recents）里，RFinal3 做完的任务在侧边栏里找不到。解决办法：从 Dot 资料页的「活动」或「已完成」（Completed）里打开任务，或者用 Dot 给你的链接打开（RFinal3、rizlah）；开工前先说好放进哪个项目；想知道进度就直接问 Dot，别看侧边栏，SlopSurfer4444 的子代理还在干活，侧边栏却显示已完成。
你自己开的 Codex 线程，Dot 接不上。往线程里发消息时报 CloudThreadNotFoundError 或「unsupported placement」，可这条线程在 Codex 应用里明明好好的（Stefan，案例 74；Kamber88；Takanashi-Rikka1）。行得通的办法：新工作从一开始就让 Dot 来建；已有的线程，继续在 Codex 里自己推进，再把摘要贴给 Dot，或者让 Dot 在那台电脑上新开一个任务，读完线程再回来汇报（Jeremy Devz 的「Dot Bridge」、iAmBoosted 的 Work 任务）。Stefan 的分工也站得住：让本地协调器管电脑上的线程，Dot 在上面统筹。
创建或继续任务时报 UNKNOWN 或 NOT_FOUND。这不是批准的问题，再多批准几次也没用（robjshore、b0ggs，案例 90）。行得通的办法：直接在 Codex 里手动启动任务（robjshore、TDove）；把桌面应用升级到最新版（imyhxy 在 Linux 上升级后，DesktopProjectsUnavailableError 不再出现；n572770 在 Windows 上升级以后，Dot 又能接着做已有的任务了）；在排查自己的设置之前，先让 Dot 查一查 OpenAI 有没有正在发生的故障（Dave）。
在你电脑上开的任务，拿不到你本地的工具。Dot 发起的任务拿不到本地 MCP 工具（案例 84）、全局 AGENTS.md（案例 87）、在本地对话里能用的 OAuth MCP（报「Auth required」，案例 88）、Computer Use（Blizzme）和读线程的工具（pimenov、Eduardo Vidal）。有用的做法：开工之前，先让任务列出它实际能调用的工具；让它先读 AGENTS.md 和操作手册，这一招对 SmithLabsLLC 管用；需要用到缺失工具的那一部分，放到你自己开的 Codex 对话里去做。Dot 发起的任务在后台运行，如果你需要盯着终端、随时叫停，也把那一部分放到 Codex 里自己跑（Blizzme）。
Windows 上，只有经过 Dot 时浏览器或命令才出错。BUILD LOCAL LAB（案例 76）和 yvesgagnongesys（案例 85）的浏览器在初始化时就报错，直接开的会话却没事；一次更新之后，Whanzo 的任务连 Get-Location 都跑不起来。有用的做法：浏览器相关的活交给另开的本地 Work 会话（案例 76）或直接开的 Codex 会话（案例 85）；任务坏掉时，让 Dot 新开一个，而不是恢复旧任务（ngderf）。把沙盒切到「unelevated」能让 gelbuilding 的命令重新跑起来，但会削弱隔离保护，要想清楚值不值得再用。Dot 电脑上的 Codex 登录不了时，只读的检查往往可以改在 Dot 的浏览器里做（案例 77）。
额度用得比预想的快。Alp Z 只提过一次某个模型，Dot 就一直用它，把额度全用光了（案例 82）；habibi 一觉醒来，Codex 用量只剩 0%，还多了六个新任务。交给你本机 Codex 的活，用的是你的 Codex 额度（polaris）；どりゃー还发现，经过 Dot 发出去的任务也会消耗 Dots 的用量。有用的做法：默认模型由你自己来定；给循环定好轮数或结束条件；与其从头交代任务，不如让 Dot 直接去读已有的 PR（どりゃー）。
语音通话交不出任务。Kevin Kaiser 和 Dot 通话时，任务交不到 Codex 那边（案例 83）；Senple 的通话到两小时就会断（案例 91）。有用的做法：把同样的请求打字发出去，在语音通话页里，6 个卡住的语音请求有 3 个就是这样送达的。重复发送语音请求之前，先去线程里看一眼，因为送达情况有时显示「未确认」（OKhan99）。

能做到和暂时做不到

已经做得不错的事：

替你开 Codex 线程、把要求交过去，再把结果汇总给你（John Voorhees、Diana Park、XiaoYao）。
通宵修 bug、跑测试、提 PR（Kurt Bell、Vaibhav Sisinty，以及老章以草稿 PR 交付的 Windows 移植），并在你的规矩要求时，停在合并和上线之前（Kurt Bell、@bezzabuilds）。
你出门时批量合并 PR，中间等 CI、解决冲突（Eduardo，16 个 PR）。
同时跑好几个 Codex 任务，再给你一份总体进展（@donghyuk65、Paul J Lipsky、余佳恆七个优先任务里的六个）。
指挥 Codex 以外的代理：通过 SSH 指挥 Claude Code（Ryo Tsukuda）、接你自建的 MCP 服务器（yusen）、统筹一整队 AI（Kentaro Mori）。
维护一个你看得懂、也能对着它下指令的进度页或任务表（月花凪，案例 78；あやみ，案例 92）。
在你排查自己的设置之前，先查到 OpenAI 那边的故障（Dave）。

暂时做不到或不够稳定的事：

把你在 Dot 对话里给的批准传进任务（案例 89、93）。
读取或接着做你自己开的本地 Codex 线程（案例 74）。
让它开的任务用上你本地的 MCP 工具、全局 AGENTS.md 或 OAuth MCP 登录（案例 84、87、88）。
在部分 Windows 电脑上，通过 Dot 发起的任务打开浏览器（案例 76、85）。
同时把你的两台电脑都当成它的本机；Mete Polat 一次只能配对一台（案例 93）。
不用你问，就讲清哪些在跑、哪些做完了、哪些卡住了（案例 73、93，Ethan2438）。
从语音通话里稳定地交出任务（案例 83）。
在它自己的 Linux 云电脑上做 Windows 和 Android 开发；Robert Ellison 估计要另配一台虚拟机。

一条可以直接复制的指令

这条指令综合了 Kurt Bell、@bezzabuilds、Kentaro Mori 和 Senple（案例 91）行之有效的做法，加上案例 87 里先读 AGENTS.md 的办法和案例 82 里定默认模型的做法，也避开了上面讲到的批准和 UNKNOWN 问题：

[仓库] 的 Codex 工作由你来协调。每件活都由你自己新建一个 Codex 任务，放在 [项目] 项目里，在 [我的 Mac / Codex 云环境] 上运行，一个任务只放一个目标。任务里写清仓库、目标和验收标准，并要求它先读 ~/.codex/AGENTS.md 和 [操作手册]，再做别的事。除非我为某个任务点名换模型，否则一律用 [模型]。每个修复都要测试，只开草稿 PR；合并、上线和删除都等我决定。维护一份状态清单，写明每个任务的名称、链接、在哪里运行和当前状态（进行中、等我批准、卡住、等审阅、已完成），状态一变就自己更新，并在 [时间] 给我发一份汇总。任务需要我批准时，告诉我具体是什么操作、该在「活动」里打开哪个任务，我直接在那里批准。如果某个任务缺了需要的工具，或者创建、继续任务连续两次报 UNKNOWN 或 NOT_FOUND，就停下来，给我一段可以直接粘贴的指令，我自己去启动。

批准、找任务、缺工具等单项问题的指令，见页面底部的「更多可以直接复制的指令」。

适合谁看

如果你平时用 Codex 写代码，希望 ChatGPT Dot（OpenAI Dots）来当协调人：替你开 Codex 线程、夜里盯着进度、只在你点头后才合并或审阅，并在手机上告诉你哪些已经可以看了，下面的内容就是为你准备的。这里收了 94 个点名的一手案例，都来自 DevDay 之后头几周里的开发者，每条都附原帖、原视频或原始 issue 的链接。案例先按交给 Dot 的工作分组，再按卡住的地方分组：批准传不到任务、任务找不回来，以及在你电脑上开的任务缺工具。上面的结论和做法都来自这些案例，括号里的编号对应带编号的案例，人名对应下文的其他案例。

先回答几个常见问题

ChatGPT Dot 能拿 Codex 做什么？它当协调人：替你开 Codex 线程、把你的要求转过去、你不在的时候跟进，再告诉你哪些已经可以看了。John Voorhees 的做法是每个大想法拆进一个单独的 Codex 线程，让 Dot 管着；入江慎吾（@iritec_jp）让 Dot 直接在自己 Mac 上的 Codex 应用里开了线程；Diana Park 的 Dot 名叫 EA，主要替她找对线程，再给她一份执行摘要。余佳恆现在让 Dot 读工单、拆任务、派活、验收和合并，Codex 只负责实现和审阅。名古屋彩美让 Dot 为每件活开一个 Work 或 Codex 会话，并让它维护一张任务表，哪件停住了一眼就能看到（案例 92）。

活到底在哪里跑？有三个不同的地方：Dot 自己的云电脑、你连接的电脑（要保持联网，ChatGPT 应用要开着），以及你事先建好的 Codex 云环境。这三处不能互相替代。u/dry_towelette99 发起任务失败，就是因为 Dot 的云电脑不能作为 Codex 任务的运行目标；他连上一台闲置的 Linux 电脑以后就成了。如果有东西好像不见了，先问 Dot 用的是这三处里的哪一处，下面 Eliot 和 Stefan 的报告都说明了这一点。

会用掉我的 Codex 额度吗？Dot 发起的 Codex 或 Work 任务，算在这两个产品各自的额度里；Dot 自己做的活单独计算（收费与额度）。所以 @uhak_crew 的用量几乎没动，余佳恆的 Codex 额度还剩 96%，而 @ev.gert 在 100 美元套餐上差点用完 Codex 额度。polaris 补充说，交给你自己电脑上 Codex 的活，用的是你的额度；どりゃー还发现，经过 Dot 发出去的任务也会消耗 Dots 的用量。

能让它夜里自己修 bug、提 PR 吗？能。跑通的案例都把合并、部署和删除留到主人点头之后。Kurt Bell 一觉醒来，bug 和数据问题都修好了，还有一份早报；一个测试过的功能改进，Dot 没有擅自上线。Eduardo 出门吃饭时，Dot 合并了 16 个 PR；@bezzabuilds 定了规矩，不经他同意，Dot 不能合并或删除任何东西。

我在 Dot 对话里点了同意，任务为什么还是不认？你在 Dot 对话里给的批准，经过 Dot 转给任务以后，任务的审核会把它当成不可信的文字，哪怕一字不差也一样。gro83j 和 moruku36 都是这样被拒的。cedar_circuit 和 moruku36 用成的办法是在任务里面直接批准：在 Dot 的资料页打开「活动」（Activity），找到那个任务，在里面回复。

CloudThreadNotFoundError、UNKNOWN 和 DesktopProjectsUnavailableError 是什么意思？意思是 Dot 看得到这份工作，却没法启动或接着做，所以再多批准几次也没用。robjshore 和 Stefan 接手已有线程时报 CloudThreadNotFoundError，b0ggs 碰到的是 UNKNOWN 和 NOT_FOUND，TDove 的多个 Dot 能列出 Codex Cloud 环境、也能读结果，但通过 Dot 创建或继续任务会返回 UNKNOWN，而直接在 Codex 界面里做同样的事是成功的；meotimdihia 的 Dot 连 Mac 上的项目都列不出来。robjshore 和 TDove 改成手动启动任务就成了。imyhxy 说 Linux 上 26.1007.21434 版桌面应用已经修好了列项目的问题，所以先把应用升级到最新版。

怎么开始？先创建 Dot，再从桌面应用连接这份工作要用的电脑和代码库，然后用一句话测试：「列出 [仓库] 里我还开着的 Codex 任务，先别新建。」在欧洲经济区、英国和瑞士以外，Pro 套餐带 Dot；Business Premium 也带；Enterprise 要等管理员开启（怎么获得 ChatGPT Dots、ChatGPT Dots 在欧盟和英国能不能用）。什么时候用 Dot、什么时候直接用 Codex 或 ChatGPT Work，请看 Dots、Codex 与 ChatGPT Work 的区别；代码库怎么连，请看 Dots 连接 GitHub；Dot 不回复了，请看 Dots 不显示或用不了。

把活交给 Codex，让 Dot 负责协调

Sam Diaz（Creative Tech）。在视频《My AI Team: 7 Ways I Use ChatGPT Dots + Codex for Real Client Work》里，他以播客工作室客户项目为例，走完一条完整链路：Dot 负责把项目理清楚、规划下一步，Codex 负责技术落地，他自己定方向并审结果。章节覆盖人不在时怎样跟进、怎样给 Codex 下清楚的任务、把网站做得更有用、调研潜在客户、把调研变成营销，以及产出创意内容。他也讲了一次隔夜客户交接怎样才站得住，以及为什么确认权限和跟进仍然重要。
John Voorhees（MacStories），Dot 名叫 Puck。单条 Dot 对话太拥挤时，他的办法是：想法一旦变成完整项目，就拆进一个 Codex 线程，让 Dot 继续管着。他已经这样做过好几次，说这是减少主对话来回的可靠办法。新的 Codex 线程不会知道上一个线程里的内容，除非有人把上下文交过去。MacStories 初体验
Chase（Chase AI），Dot 名叫 Winston。他在语音通话里让 Winston 在一个现有项目里新开 Codex 线程，做一个对比 Dots 用法的网站。Winston 建好线程、把开发交了出去，边做边核对产品说法，网站最后顺利上线。有个小问题：这个任务出现在“最近”列表里，而不是项目文件夹里。YouTube
入江慎吾（@iritec_jp）。他从 Dot 那里直接在自己 Mac 上的 Codex 应用里新开了一个线程，并在里面下达指令。他的感想是：“这下什么都能做了。”X 帖子
Daniel Mac（@daniel_mac8）。他录屏展示了 Dot 自己创建 ChatGPT 和 Codex 线程，然后在干活过程中主动往这些线程里发消息。X 帖子
u/Fantastic_Self_5151（r/codex）。他让 Dot 去吩咐另一台机器上的 Codex 做事并把结果带回来，或者让两边自己商量到跑通为止。他说这样省了大量时间。Reddit
@donghyuk65。他说现在的感觉像是自己当上了组长：“这个改一下”“那个丢给 Codex 跑”“再做一张图”“现在做到哪了？”，Dot 都会马上回答。他把好几个 Codex 任务同时丢出去，然后直接问 Dot 整体进度，不用一个个去看。云端的活在他关掉自己电脑以后也会继续做。Threads
@uhak_crew。他让 Dot 去找可以报名的比赛，查看评审邮件并把意见写进方案，再把产品从头点一遍，整理出 UX 流程的改进点。等他要方案文档时，Dot 把活交给 Codex 去做，做完向他汇报；Codex 一跑偏，Dot 就进到 Codex 会话里调整指令。他说这一套如果直接在 Codex 里做，要花掉一周的额度，这样做额度几乎没有减少。Threads
Kevin Ly（@thedadintheloop），Dot 名叫 Dex。他在手机上问一个项目做到哪了，Dex 查了他连接的 Mac，列出哪些已经完成、哪些还要继续做。查找花了一些时间，中间还要他补充说明，第一次打电话也没接通；但他很看重能在一个地方问清所有 Codex 项目的进度。Instagram
伊藤貴將（いとぱん，note），Dot 名叫“シバット”。他用 Codex 做了好几个应用，以前每次开工都要先找项目放在哪、上次做到哪，光这一步就很费时间。现在他直接告诉 Dot 项目名称、在哪台 Mac 上（他的 MacBook Pro）、要参考哪些资料、这次想做到什么程度，Dot 就从那里接着往下做。他正在开发一个用 3D 观察肺和横膈膜运动的应用“身の内”，Dot 读了存在 Mac 上的讲义，给应用加上一份观察身体形态和动作的指南；另一个用 3D 眺望北阿尔卑斯山的应用，也交给它接着开发。应用的活在跑的时候，他照样和 Dot 聊别的制作，回头再看结果。他的体会是，把项目、机器和资料说清楚，“接着做那个”才行得通；浏览器报错、回复慢、上下文搞混的情况也都遇到过。note，2026 年 10 月 3 日，日文
Diana Park（@madebydia），Dot 名叫“EA”。10 月 14 日，她在回复 @_simonsmith 时写道：她给 Dot 起名 EA，它主要替她管理 Codex 线程。她不用再为某个话题或项目去翻找对应的线程，Dot 会把她的意图转达过去，再给她一份结果的摘要。她说，这是她目前为止对 Dot 想到的最好的理解方式。
Sarrazola（@sarrazola）。10 月 13 日他写道：Dot 用起来没有 Hermes 那么强大灵活，可他反而用得多得多，原因是 Dot 连着他整套 Codex 环境。现在他用 Dot 统筹几十个线程和项目，以及几百段对话。
Matthew MacKinnon（@MatthewMacK）。10 月 14 日他对 @thsottiaux 说，自己现在所有的 Codex 工作都从 Dot 那里发起，所以 Codex 新加的输入框预测功能对他没什么用，希望 Dots 里也能有。
XiaoYao（@XiaoYaony）。10 月 14 日，XiaoYao 在回复 @libukai 时写道：Dots 这次更新里帮助最大的一点，是 Dot 能直接读 ChatGPT 会话，也能派发 Codex 任务。有了这两项，XiaoYao 就能把 Dot 当成项目总管来用。在这之前，Dot 只能另外建一个云端任务，再去检索其他会话，中间传话很麻烦。
bbshark（@bbshark_13），Dot 名叫 Bob。10 月 14 日，bbshark 向 @thsottiaux 介绍了自己的流程：先在聊天里想点子、做设计，再把需求说明提交到 Git。Bob 读到这些说明后规划集成方案，交给 Codex 去开发，并且一路盯着 Codex，不让活停下来。bbshark 还提到，Codex 开着 fast 模式，感觉还是比以前慢。

人不在时修 bug、跑测试、提 PR

jammyrob28（OpenAI 社区，2026 年 10 月 12 日）。他可以在同一条 Dot 对话里谈好几个项目，把活交给 Codex，回来直接看结果，而不用在多个聊天之间来回复制说明。一个具体例子：他反馈 Android 游戏缺声音，经历排查、修复和新的 Expo 构建，他自己测过并确认可用。同一天他在上班时，Dot 还准备好了 Play 商店的说明文案和配图。他们另外做了一个每日挑战原型，并在他人不在时用家里电脑上的本地 Codex 做检查。写代码之外，它还发现了 Google 账号安全提醒，并核对是不是他自己改过（他确实改过）。他仍然自己审阅和测试；远程批准提示仍有毛刺。社区帖
Kurt Bell（@softypapa）。他睡前留下一个软件 bug 和一个数据问题，醒来两个都解决了：Dot 逐项处理、测试并核实了修复，还留了一份晨报。它另外发现并测试了一个可能的产品改进，但没有他的批准就没有上线。X 帖子
还是 Kurt Bell，这次在散步。10 月 8 日早上他出门散步，顺手问 Dot 进度怎么样；绕街区才走了一半，1,148 个测试已经全部通过。X 帖子
Vaibhav Sisinty。他做隔夜测试时只给了 Dot 一个目标：读 alpha 版的 bug 报告，修好最新的那个 bug，提一个 PR，合并之后在 Slack 里回复。他的视频里可以看到，Dot 在 GitHub 上读代码、修 bug、开 PR，合并后又在 Slack 发了消息。他说这像一个会把活干完的同事。Instagram
@rennsong，Dot 名叫 benny。他现在把所有工程工作都交给 Dot 分派，benny 在多个线程和云端环境之间派活，并持续跟进未完成的任务。排查一个问题时，benny 在旁边的函数里又发现了一个严重 bug，并问他要不要先提一个草稿 PR。X 帖子
Eduardo（@martiano），Try Omarchy 发版。他出门散步吃饭，Dot 在家里合并大约 15 个 PR、等 CI、解决冲突，然后构建应用、更新依赖包。他晒出的手机通知写着 16 个 PR 全部合并完成，可以交给他接手了。X 帖子
@bezzabuilds。他给 Dot 安排了一份固定的夜班：找出应用里的 bug 并修好，每个修复都要有测试证明；再提出并做出新功能，每个功能都交给一个“挑刺”代理打分，不合格就退回重做，最后给通过的功能录演示视频。他醒来时有 3 个做好的功能等着审阅。按他定的规则，没有他同意，Dot 不能合并或删除任何东西。Instagram
@DevAdventur3s。他在 DevDay 上跟 Gabriel Chua 提过一个 Codex bug（截图让对话变得很臃肿）。后来他在露台上给 Dot 打电话：Dot 找到了那条旧的 Codex 线程，通过 Codex CLI 提交了 bug 报告，还给 Gabriel 发了私信跟进。X 帖子
@huke1484。这位开发者在用 Codex 干活时，把自己手上做到一半的代码审阅交给了 Dot，说结果还不错。同一个 Dot 还在全天候跑建模任务。Threads
Robert Ellison（个人 Pro 套餐）。他开通 Dot，主要就是想在路上也能写代码。到 10 月 9 日，Dot 已经通过 GitHub 集成、指挥 Codex，替他的博客修好了三个 bug，上线了一个新功能，还在他的 Todoist 里加了待办，提醒他之后复查这些修复。他的博客直接从 GitHub 发布，所以他一批准 PR，改动就上线了。他遇到的限制是：他平时大量做 Windows 和 Android 开发，Dot 的 Linux 云电脑拿来叫 Uber 没问题，跑这类开发却不合适，他可能还得另外准备一台虚拟机给 Dot 用。Dot 日志
Ai学习的老章（人人都是产品经理）。他开源的音频生成工作台之前只有 macOS 原生版，不少读者一直在催 Windows 版。睡前他给 Dot 下了一条指令：把项目完整移植成 Windows 客户端，跑通所有测试，再打包一个免安装的便携版。Dot 在自己的云电脑上动手（他查到的配置是 Debian 系统、9 核 CPU、9.7GB 内存、32GB 磁盘），克隆仓库，装好 Node 和 Electron 编译环境，重写了底层音频接口。第二天早上，GitHub 上多了一个独立分支和一份草稿 PR：101 项单元测试、19 项界面测试、9 项真实 Windows Electron 测试全部通过，打包后的 EXE 也能正常启动；GitHub Actions 还编译出一个约 158MB 的便携包，适用于 Windows 10/11 x64，不用另装 Node 或 Python 就能直接运行。人人都是产品经理，2026 年 10 月 3 日，中文
clggest（linux.do）。他有个纯靠 vibe coding 写出来的项目，GitHub Actions 的额度用完了。他让 Dot 照着原有的 Actions 流程，在自己的云电脑上把项目构建出来，再推送了 release。他自己的电脑一直很干净，也不用再搭虚拟机；按他的说法，这些活都没有用掉 Codex 额度。linux.do，2026 年 9 月 30 日，中文

并行线程、子代理和任务队列

@kagamitei。他从深夜到早上给 Dot 丢了一个大任务做测试，6 个子代理全开。这类活他平时都交给 Codex，结果他认为毫不逊色；按他的经验，Codex 通常只开 2 个子代理。Threads
余佳恆（@tachichocolate）。读工单、理解和拆分任务、分派、验收、合并，现在全部交给 Dot；Codex 只负责实现和审查。后来的一张截图里，7 个优先任务中有 6 个从早上起一直由 Dot 在跑，Mac 上的 Codex 只跑 1 个，Codex 额度还剩 96%。Threads：从工单到合并 · Threads：7 个任务里跑 6 个
鮑聖文（@nbaobao24）。他觉得单用 Codex 太慢，于是让 Dot 直接管理他的 Pi AI 代理和 Codex，说产出大约翻了四倍。Threads
Seth Rosen。他把 Dot 当成 Codex 工作的总调度，设计、测试、演示和策略都归它统筹，下面再开更多并行线程。X 帖子 · 相关帖子
Pat Simmons（AI for Mortals），Dot 名叫 László。László 找到了他的代理们共用的 Code Queue 看板，核对了 MCP 连接，并安排每个工作日晚上 9 点在 Slack 发状态摘要。通话里它报告有 137 条进行中、122 条待审，大多已经过期；Pat 让它在 Slack 里列出建议关闭的条目，等他批准后再关。AI for Mortals
Gabriel Chua（@gabrielchua，OpenAI 员工）。他以前会专门留一两个 Codex 线程去调度其他 Codex 线程，现在直接问 Dot。他的截图里，Dot 开了一个本地修复线程，先确认应用归哪个仓库，再复现问题并测试修复。X 帖子
Thomas Ricouard（@Dimillian，在 OpenAI 做 Codex）。他在飞机上做自己的游戏，让 Dot 协调家里那台 MacBook Air 上的任务和云端任务。X 帖子
Ethan2438（LINUX DO）。在 Ethan2438 看来，Dot 像个总管，真正的活都派给背后的子代理去做；按这位用户的说法，最多能调用 6 个子代理，加上 Dot 本身一共 7 个。子代理的状态默认看不到，所以 Ethan2438 让 Dot 写了一个监控子代理状态的简单页面，还在帖子里问其他用户有没有更好的查看办法。OpenAI 的控制你的 Dot 说明页提到，在桌面应用里打开 Dot 的资料页，进入「活动」（Activity），就能看到它委派出去的任务，以及每个任务的进度、文件和结果。LINUX DO，10 月 3 日，中文
Grumble8167（LINUX DO）。10 月 10 日同一天的用法：把仓库丢给 Dot，让它拉到自己的云端电脑上跑测试。Grumble8167 觉得这条路比 6.1sol 更聪明、更快，体感接近 Astra，还能多路并发，不太容易一并发就「降智」。LINUX DO
dafire（LINUX DO）。同一帖里，dafire 主要把 Dot 当成协调者：大约可以同时跑 6 条工作流。dafire 还提醒，云端空间会不定时重置，没有固定周期，所以放在云端的项目要及时存进 Space。LINUX DO
Paul J Lipsky（一通电话交代三件事）。在一期由培训公司 Outskill 赞助的 YouTube 视频里（2026 年 10 月 4 日；赞助已标明），Paul 给自己的 Dot 打了一通电话，一口气交代了三件事：为周二要拍的 ChatGPT Spaces 视频做调研，把提纲写进他已经建好的 Obsidian 笔记页；打开 Dayboard 应用（接 Obsidian 的那一版）已有的 Codex 线程，加上一个能把改动存回 Obsidian、并带“在 Obsidian 中打开”按钮的简易 Markdown 编辑器；在游戏 Schmela 已有的 Codex 线程里，修好爬陡坡时走路和攀爬卡住的问题，并在上帝模式里加上无限箭矢和更快移速，方便他查 bug。通话里 Dot 把三件事都排上了（Spaces 调研已开始；Dayboard 编辑器已排队；Schmela 修复已排队）。他说 Dot 会盯着这些线程，直到目标做完，需要他拍板时再推到手机上。
supernovae（@byron_miller）。supernovae 付费买的是 Codex，并不只是为了 Dots；Dot 负责调度，让工作在没人盯着的时候也能跑下去（X，10 月 11 日）。Dot 会把活拆成一个个任务，每个任务都有自己的对话记录，supernovae 觉得这比一层套一层的机器人好管得多（X）；这些任务以卡片的形式记在 Notion 看板上，从待办、进行中一路挪到完成（X）。结果是"这周大约提了 100 个 PR"，剩下的唯一一个权限问题，是 Dot 用不了 Codex 里的 SSH 密钥（X，10 月 13 日）。在 Windows 上，Dot 起初没法用 SSH 或 WSL2（X，10 月 12 日）；后来 Dot 读了一个公开的 Codex issue，照着里面的变通办法试了一遍，就能从 PowerShell 里连 SSH 了，详见 Dots 连接 GitHub。
Drake（@Copypaster3000）。Drake 给 Dot 在 Codex 里做了一个叫「sup」的技能：它会汇报哪些任务正在跑、哪些刚做完或在等本人审、队列里还有什么。Drake 说自己已经用它很多次了。X 帖子
Authority Hacker（@authorityhacker）。他们的 Codex 额度在重置前还有剩余，于是让 Dot（10 月 13 日，附视频）自己去找有用的活，做好后交给他们审阅。
Jialin（@0xjialin）。10 月 14 日，Jialin 写道：用了一阵 Dots 以后，交给它的任务越来越多，却没有一个统一管理的地方。哪些在推进、哪些卡住、什么时候需要自己拍板，都得再问一遍，或者回聊天记录里翻；任务一多，连任务本身都会忘掉。帖子里提出的是一个供大家交给自己 Dot 去实现的思路，并不是已经做好的成品：用 ChatGPT／Codex 的站点功能部署一个个人任务看板，由 Dot 更新进度、整理卡点和建议，每一项都能一键回到对应的对话；任务结束后，再把成果、经验和值得优化的技能与流程沉淀下来。帖子下面，itsplayai 回复说这样没用：Dot 不会自己更新任务状态，要本人实时去问，它才会去更新。

不只是 Codex：Claude Code、自建 MCP 服务器和一整队代理

Jason Rivard（@j.t.rivard）。他电脑上的一个 Claude Code 会话停在那里等他回复，他就打电话问 Dot。Dot 在自己的 Linux 电脑上用浏览器打开他开了 Remote Control 的 Claude Code 会话，告诉他会话在等什么，再把他的回答替他输进去。他说这个用法有点傻，但确实是真实场景。Instagram
@ev.gert。他在 100 美元的套餐上差点把 Codex 额度用完，于是又加了 Claude，把所有工具都围着 Dot 搭起来。每来一个任务，Dot 先问 Jev 该交给哪个代理，再亲自把任务发出去：发到它的服务器、交给 Claude、派到他的本地电脑，或者直接启动合适的程序或脚本。他嫌在几个代理之间来回转发消息太累，就给它们开了一个共享的 Google 文档，现在它们直接在文档里互相留言。Threads
yusen（@yusen0411）。他不放心让 OpenAI 直接操作自己的电脑，就把 Dot 接到一台自己架设的 MCP 服务器上，由这台服务器决定哪些工具、文件夹和指令可以使用。通过它，Dot 读写了文件、跑了程序，还列出了电脑上装的软件。他的体会是：让 Dot 操作他自己的云主机，速度明显比连回本机快；走本机的好处是数据和权限都握在自己手里。Threads
도리（@dori.2678）。他给 Dot 做了一次性能测试，又让它搭了一个简单的测试框架。他的评价是：几乎没用掉多少 Codex 额度，活干得利落，也很少越界。Threads
Kentaro Mori（Zenn 上的 SeaOtter），Dot 名叫“ドッチー”。这位云工程师在 10 月 1 日到 7 日给一支 AI 团队当产品负责人，由 Dot 整理需求，决定每件活交给哪个代理、在哪台机器上跑，再汇报进度：ChatGPT 和 Codex 负责设计和审阅，Claude Code 主要写代码和修改，Gemini 和 Antigravity 做原型和调研，Qwen 跑本地 GPU 测试。第一天计划了 9 件任务，只完成 3 件，其余 6 件都卡在 Mori 的决定、手动复制提示词和本地图形界面的交接上。第四天，Dot 把活交给 ChatGPT 或 Codex 的途中停在一次批准上，界面只写着“等待批准”，看不出到底该允许什么，所以 Mori 现在要求 Dot 一并报告要做的操作、需要的权限和已经做完的部分。从第五天起，Mori 主要用语音下指令，让 Dot 每 30 分钟按编号汇报一次（比如“先做 2 号”）；不过做完的项目一拿掉，编号就会重排，所以下指令前还要对一下任务名。第六天又加上网站注册、更新个人资料和做视频素材，几件并行的活停下来时，很难看出哪件在跑、哪件在等。第七天，Dot 把优先级换到一份急着要交的申请材料上，其中一项成果是给 Mattermost 一个已有的 PR 写了验证评论。一周下来，Mori 留下了这几条做法：交代任务时写清目标、范围、不做的部分、运行环境、验收条件和汇报内容；写代码和审阅交给不同的代理；把“写好了”“模拟测试通过”“真实环境能跑”“我验收了”当成不同的状态；每天收工前用语音聊 10 分钟。Zenn
ishizakahiroshi。这位自由职业工程师从两个地方通过 Slack 私信给 Dot 派活：装了 Slack 插件的 ChatGPT，以及装了 Slack 官方 MCP 插件的 Claude Code。每件活先从自己的台账里领一个编号，再在仓库里建一个文件夹，放三份文件：README.md 写目标、范围、不能碰的地方、交到哪里和完成标准，REVIEW.md 写另一位审阅者要检查的点，PROGRESS.md 记录阶段、负责人、状态、证据和下一步。Slack 消息里给的是固定在某个 commit 上的说明链接，这样 Dot 读到的就是发出时的版本；Dot 的第一条回复必须写明它读的是哪个 commit、需要的工具能不能用、成果会交到哪个分支。回复出现在这件活的线程里，不在最外层。另有一个只读脚本，哪个仓库 60 分钟没有变化就标出来，这个时长是 ishizakahiroshi 自己定的。有一次 Dot 的环境装不上依赖包，那一步只好在本机补上；还有一个大 issue 过了两个多小时都没出 PR，所以现在每件活都切成 30 到 60 分钟能做完的大小。合并、发布和检查上线后的页面都由 ishizakahiroshi 自己来做；这篇记录的正文和 5 张配图则是 Dot 写的。Zenn
Ryo Tsukuda（Zenn）。他在家里网络中的一台 Linux 电脑上跑 Claude Code。以前每做完一个小任务，他都得盯着屏幕手动输入 /clear，免得旧的上下文一直消耗 token。现在他把大的开发目标写进 Dot，由 Dot 通过他那台 Windows 电脑（已经用 ChatGPT 应用连上）操作，用 SSH 登录那台 Linux 电脑，一次只给 Claude Code 一个小任务，做完就执行 /clear。什么时候清空，是 Dot 看进度判断的，不是按时间或次数机械执行。目标和进度都留在 Dot 那里，所以 Claude Code 的会话清空后照样能拿到下一个任务。这样他晚上交出目标，早上看结果就行，token 用量也降了下来。需要付出的代价是：两台电脑都得 24 小时开着；Dot 自己的对话要由他自己清理；SSH 这条路是他自己的环境，不是 Dots 自带的功能。他没写任何脚本，全靠自然语言交代。他也说明了，这篇文章是 AI 根据他的体验和笔记写成的。Zenn，2026 年 10 月 9 日，日文
ぞう（zou_aidouga，note）。发布当天，ぞう只连了一台 Mac，没有连任何应用，每样都只试了一次。Dot 把任务交给 Codex，并确认了结果，这一步成功了。Claude Code 能启动，但一交活就要求登录；ぞう推测是 Mac 上的登录信息没有传到 Dot 的运行环境，这次也没有输入认证信息。问 Dot 能不能操作屏幕，它回答找不到用鼠标和键盘操作的功能；对 Premiere 的两项检查（是否在运行、打开的是哪个项目）也都失败了。连接时的确认窗口写着：Dot 可以访问这台 Mac 的文件并在上面干活，其他桌面会被断开，而且这个权限在所有能给 Dot 发消息的地方都有效，包括 Slack。所以ぞう只在一个空的测试文件夹里试，并让 Dot 遇到需要批准的操作先来问。note，2026 年 9 月 30 日，日文
ヤッテミストひで（Hide，note），Dot 名叫“ポッケ”。他不是工程师。他让 Dot 在自己的云端浏览器里登录他的 ChatGPT 账号，打开他指定的一个对话，替他和那个对话继续聊下去，也用同样的办法把活交给 Work。出门吃饭前，他交代一句“和这个对话聊着，把事情往下推”，Dot 就自己读每一条回复、发出下一个请求，不用他一条条去发；回来以后，他再问 Dot 推进到哪一步，方向偏了就纠正。后来他才发现，不用操作浏览器，Dot 也能直接从对话里另开一个干活的对话。他的 Codex 工作跑在家里的电脑上，两边靠一个共享的 Space 页面衔接，具体做法见 ChatGPT Space 页面。note，2026 年 10 月 2 日，日文
Lethabo Lee Ntshudisane（@DistinctLee），Dot 名叫"V."。Lee 大部分正经工作都在 Codex 里完成，同时也让 Dot 去指挥 Claude 做工程上的活（X，10 月 10 日）。V. 会通过 Claude Projects 干活（X，10 月 11 日）；10 月 13 日，Lee 看到 V. 把自己的不耐烦原样转告给 Claude："Lee 说这事拖得太久了……"（X）。Lee 也提醒自己，要注意别让 V. 害得他们被 Claude 封号。短板在语音上：Lee 在 iOS 应用里给 Dot 打电话，Dot 根本不接（X，10 月 10 日）。
NoBrakes（@NoBrakeMode）。10 月 13 日，NoBrakes 在回复 @thsottiaux 的帖子时说，Dots 最近“变得很笨”，会把任务弄丢，写代码也让人不放心。他眼下的办法是让 Dot 把所有写代码的活都交给 Claude，Dot 自己只负责测试。X 帖子
tangentstorm（@tangentstorm）。10 月 13 日，tangentstorm 在 X 帖子里说，是 DaveShapi 的帖子让自己决定试试 Dot。现在 Dot 在一套多代理编程流程里当「国王之手」（原话 hand of the king，也就是左右手）：Claude 负责干活，Grok 仍然管「行政流程」，交代事情时 tangentstorm 通过 Dot 开口说，每个 PR 再交给 Codex 审查。和 Grok 的语音模式比，OpenAI 的语音说话慢，思考时停顿也更长，但不会在人话说到一半时抢着动手。Dot 还有一项任务：把整套流程写成文档，打包成一个技能仓库加一个 MCP 服务器，让别人也能照搬，并给每个角色接上自己喜欢的代理。写这条帖子时，tangentstorm 还在消化改用这套代理编程后涌来的一大批 PR。
Pyuyi（@Pyuyi2333），DotControl。10 月 14 日，Pyuyi 讲了这样一件事：在 Mac 上做视觉小说时，忽然有个想法需要做实验验证。讨论都在 Mac 的 Codex 对话里，可只有那台 Windows 电脑连着实验室的 VPN，能访问服务器。为此 Pyuyi 做了开源工具 DotControl：你可以让一台电脑上的 Dot 把任务交给另一台电脑上的 Codex，读取你选择共享的对话，并执行受控的桌面操作。它支持 Windows 和 macOS，不需要自建云服务。

需要人帮一把的地方

Deependra Solanky。Ubuntu 把 Codex 应用杀掉之后，他让 Dot 找出所有被打断的并行线程，并逐个恢复。X 帖子
u/dry_towelette99（r/OpenAI）。Dot 尝试启动一个 Codex/Work 任务，提示没有可用的执行环境；等 Dot 自己手上的活做完，还是启动不了，因为 Dot 自己的云电脑并不是这个任务启动器能用的目标。他通过桌面应用接入一台闲置的 Linux 电脑，Dot 把任务派到那台机器上，之后两台机器同时在跑。Reddit
John Aspinall，Dot 名叫 Dolly。按常规方式让 Dolly 运行一个技能，任务可能会被转到单独的 Codex 会话里。他把技能本身交给 Dolly，并讲清楚活要在哪里跑，这样他的亚马逊商品图组任务就留在 Dolly 的对话里完成。YouTube
かみもと（Kamimoto，@sep_is_heim）。原本的设想是：在 Dot 里做调研，让 Windows 电脑上的 Codex 去测试 ComfyUI 的自定义节点，再把结果交回 Dot。结果光是建一个文件夹就花了大约 10 分钟；之后又等了 20 分钟没有任何进度，直到 Kamimoto 问了一句“现在什么情况？”，Dot 才去查，发现 Codex 早就卡在节点安装和模型下载上了。在一整天的测试里，读一个 md 文件要 10 分钟，视频任务中途失败两次，Dot 放着不管过了 30 分钟，最后一个视频也没做出来；删一个文件夹也要 7 分钟。同样的指令直接交给 Codex，却能跑通。几项长期盯梢（二手平台上的商品、X 和 Reddit 上某个加速话题、一个基准测试网站）帮助不大，不过 Dot 确实主动指出了那个基准网站上的空白格。到 10 月 8 日，从手机让 Dot 查 Windows 上 Codex 的进度，多数时候还是不成功，Kamimoto 于是退回了 Plus。note，2026 年 10 月 2 日发布，更新到 10 月 8 日，日文
soloist 和 polaris（linux.do）。soloist 的 Dot 告诉他，自己连不上他电脑上的 Codex，只能在云电脑上开发。polaris 回复说，在本机登录 Codex 并授权远程连接，就能连上。他也提醒了一点：Dot 交给本机 Codex 的活是在 Codex 里跑的，用的是你的 Codex 额度，Dot 只负责统筹。想让这些活不占 Codex 额度，就让 Dot 在云电脑上做，或者通过 MCP 联动来开发。linux.do，2026 年 10 月 1 日，中文
どりゃー（@doryaaa3）。10 月 12 日，doryaaa3 在回复另一位用户时提醒说：通过 Dot 让 Codex 干活，Dots 的用量和 Codex 的用量会一起被扣，反而更不划算。doryaaa3 的建议是，与其从头给 Dot 交代任务，不如让它直接去读 GitHub 上的 PR，自己接着往下做；不过进度还是要时不时看一眼。X 帖子，2026 年 10 月 12 日，日文
fistre（linux.do）。他把 Dot 连到 Mac mini 上的 Codex 应用，本想用它代替手机 ChatGPT 客户端里卡得厉害的远程功能。结果 Dot 和 Mac mini 上 Codex 的连接每隔几个小时就断一次，断了也不会自己连回来，每次都得手动重启 Codex。linux.do，2026 年 9 月 30 日，中文
Dwain Browne（多伦多，做了 20 多年软件开发）。Dwain Browne 说，自己已经一周没写过一行代码：编程、调研、营销和日常经营都交给 Dot 和 Codex，在几个项目里同时推进，很多安排是用语音交代的。让 Dot 在几台电脑上管理大约 20 个任务之后，Dwain Browne 列出了拖慢进度的几件事：记忆和上下文不够用，任务会丢，交接不可靠，工作一跨多台电脑就处处受限。YouTube，10 月 8 日
habibi（@habibislop）。用了一天之后，habibi 交给 Dot 一个隔夜的总结任务，当时 Codex 额度只剩大约 20%，也没想到这个任务会用到 Codex。第二天醒来，额度已经用光，Dot 新开了 6 个 Codex 任务，工作却在一开始就卡在某个授权环节、没有做成，Dot 为什么要反复开新任务也说不清楚。在这之前，让 Dot 去翻自己的 Codex 对话，也耗掉了不少 Codex 额度。X 帖子，2026 年 10 月 1 日
k_visual_studio。10 月 13 日，k_visual_studio 用日语发帖说，这几天搭配 Codex 用的 Dot 明显变弱了：跟不上对话的来龙去脉；同时跑几项任务时，回头一看，总有一项已经停了。帖子最后说，靠 Dot 来管任务恐怕已经行不通了。X 帖子，2026 年 10 月 13 日
Andric（@astralwave）。10 月 14 日，他让 Dot 代开一条 ChatGPT 线程，结果会话对不上：只好在云端浏览器里再打开一次 ChatGPT 并重新登录。他还写到，Dot 已经没法再开 Codex 线程，只好改走 Paseo CLI。X 原帖，2026 年 10 月 14 日
AdamWang（@AdamWangPa）。10 月 14 日用中文写道：Dot 在开启 Codex Cloud 云端执行对话框时，常常复用同一类已经跑了很久的对话框，任务状态会失真，并冒出各种 bug。他的办法很简单：让 Dot 重新开一个对话框，不要接着用旧的那一个。X 原帖，2026 年 10 月 14 日，中文
Vicente（@VicenteDoes）。10 月 14 日，Vicente 对 @thsottiaux 说，Dot 还是没法和他电脑上的 Codex 互通消息，连 Dot 能访问的那台电脑也不行。Vicente 喜欢 Dot 这个思路，可在他看来，一个负责统筹却跟 Codex 说不上话的 Dot，还不如直接开一个 Codex 对话好用。
Dave（@LLdavedave）。有人说这两天 Codex 一直出问题，10 月 14 日 Dave 回复说自己这几个小时也一样，而他的 Dot 查到了原因：OpenAI 那边正有一起影响桌面应用里 Codex 的故障，在布里斯班时间下午 5:05 被发现，目前正在修复，所以报错很可能出在服务端。Dot 还附上了实时故障页面的链接。在花时间排查自己的配置之前，可以先让 Dot 查一下有没有这类故障。

另外两个相关案例在别的页面：Teeming（@teemingchew）用手机追查 CI 失败（见 AI 秘书一页）；Ali Abouelatta 跟 Dot 打了 90 分钟电话，同时由它调度 10 个 Codex 线程（见 First 1000）。

委派的任务卡住时，大家是怎么解决的

下面这些都来自公开的 openai/codex 问题列表。下面的办法是用户自己摸索出来的，不是官方修复。

在 Dot 对话里批准了，任务却还是拒绝执行。COOLak 在 Mac 上通过 Dot 主对话批准了一次范围明确的 NotebookLM 更新，Dot 把批准转给了任务，任务的自动审查还是拒绝了。他在任务自己的对话里把同样范围的授权再说一遍，事情就办成了，两份资料都更新好并读回核对过（#51349）。unrespect 在 Windows 上想扩大一次只读检查的范围，也遇到了同样的问题，把批准直接发在委派任务里以后才放行（#51304 下的评论）。Jasmine210220 发现，在中文版 Windows 应用的任务里输入 /approve，只会显示“无命令”（#51304）。所以遇到这种情况，要从 Dot 的「活动」（Activity）里打开那个任务，在任务里给出批准。
批准弹窗一直反复出现。cmoiccool 在 Mac 上让 Dot 开的线程使用 Brave 浏览器，结果卡在批准循环里，选了“本对话内允许”也没用。他改让 Dot 写一段提示词，由自己手动开线程，这样就跑通了。后来他重启了 Dot，又在自己开的线程里批准了 Brave，之后 Dot 再用 Brave 就不用再问了（#51720）。
Dot 读不了以前的 Codex 对话。lonestarsigns（Windows 11，Pro 200）看到的报错是“unsupported placement format version 3”（#51731）；williamsdigitalservices-sys 也是同样的报错，Dot 想往里发消息时还会出现“CloudThreadNotFoundError”。OliviaDevil 打开一条更早的对话时，看到的是“unsupported placement region 10”。omarpinarecords 在 Mac 上一个任务报“version 2”，另一个报“region 14”（#51722）。chaidexi138-netizen 把 macOS 应用更新到 26.1002.52244 以后，新建 Work 对话恢复正常，旧对话还是读不出来（#51880）。后来的报告显示，刚手动新建的线程也会读取失败，详见下文“让 Dot 接手你自己开的 Codex 线程”。Frade718 在 Windows 上委派的 CAD 任务加载不出历史记录，他最后把交接内容写成磁盘上的文件，让工作能接着做下去（#50796）。
追加指令时报“AbsolutePathBuf deserialized without a base path”（Windows）。lingzilei 每次直接在 Dot 创建的任务里输入后续指令都会报这个错，但通过 Dot 去继续同一个任务是可以的（#51049）。ceoamarion 强制退出应用以后仍然报错（#51469）；lonestarsigns 有三个对话都没法回复，DanielGladyshev 用 10 月 7 日的新版本时，连停止对话都失败了（#51679）。jeonghakhui-art 最后只能通过侧边对话把后续指令发进去。在修好之前，可以把后续指令发给 Dot，由它转给任务。
任务跑不了命令，或者工具不见了。10 月 7 日的 Windows 更新之后，Whanzo 的 Dot 开的每个任务都会报“setup refresh had errors”，连 Get-Location 都跑不起来，而同一条命令在普通的 Codex 对话里能正常运行。他重启了电脑、重开了应用、重新连接了电脑，都没有用，由 Dot 统筹的 Blender 和 Unity 工作也因此停了下来（#51882）；ashjo42 和 staxe177 也遇到了同样的情况（#51735）。Song2012 在 Windows 上委派的任务完全没有浏览器控制工具（#51578）。在 Mac 上，n42mhdjyrk-lang 的任务跑了几个小时以后，读取其他 Codex 线程的工具不见了（#50800）。ngderf 发现重启应用也找不回这些工具，但让 Dot 新建一个任务，就能顺利读取同一条对话（#50800 下的评论）。所以任务坏掉时，与其恢复旧任务，不如让 Dot 新开一个。
笔记本换了网络。kendonB 的电脑从公司 Wi-Fi 换到手机热点，再换回家里的 Wi-Fi。恢复任务时报“exec-server transport disconnected”，电脑却仍然显示已连接；大约七分钟后重试同一个任务，就成功了。这期间他在手机上跟 Dot 的语音通话一直没有断（#51273）。
中间多出一个任务。pigfyy 的 Dot 即使有已连接的插件可以直接完成工作，也坚持先建一个 Codex 任务；他明确要求不要这样做，情况也没有稳定改善（#51797）。

有时候问题不在你的设置上：10 月 7 日 OpenAI 的状态页写着“Dot in Codex may fail to create new threads”，时间是 UTC 16:31 到 18:06。更多关于 Dot 突然用不了的报告，整理在 Dots 用不了怎么办这一页。

在 Dot 对话里给的同意，为什么传不到任务里

这是委派任务时被提得最多的问题。你在 Dot 对话里同意了某个操作，Dot 也把你的回答转给了正在干活的 Codex 任务，可任务还是拒绝执行。下面的报告来自公开的 openai/codex 问题追踪里的 issue 和评论，还有两个 OpenAI 社区帖子：cedar_circuit 的帖子和 nickcaracappa 的帖子。报告者用的有 Mac、Windows，也有网页版。下面写的是用户遇到的情况和他们自己找到的办法，不是官方修复。

拒绝时说的是什么

拒绝理由几乎都一样：任务的自动审核把你的同意当成委派对话里的一段文字，而不是你本人发的消息，所以不会照着执行。

gro83j（Windows，#50794）。他们在主对话里同意了一次指定的文件传输，Dot 把原问题和回答一字不改地转了过去。审核在任何操作开始前就拒绝了，理由是“所谓的同意只出现在不受信任的委派对话内容里”。后来一次只在本机运行的小检查也被同样拒绝，这一次审核搬出了任务最初的只读范围（#50794）。
progressorZ（Mac，#50887）。Dot 的任务给一个现有的本地 Codex 线程发一条无害的测试消息，连续失败两次。他们要求再试一次，审核却把这次重试当成绕过上一次拒绝的尝试（#50887）。
EvolveStone（Mac）。任务先调出原来的 Dot 对话，引用了原话再重试，结果还是被拒绝，理由是这份同意“只出现在不受信任的检索结果里”（#50887 下的评论）。
103654716-ux（Mac）。一条已经同意过的状态询问要发给另一个任务，被拒绝的理由是唯一的同意“在明确标为不受信任的对话记录里”。这次拒绝没有附带请求编号，也没有可以点的同意按钮（评论）。
moruku36（Windows）。Dot 问要不要提交、推送并开一个草稿 PR，他们回了一句“うんよろしく”（“好，麻烦了”）。任务说审核没法把这么短的回复认定为明确同意，所以什么都没有推送（评论）。
pagliazi 和 Stan91111。pagliazi 这边，有些转达因为任务一开始的只读范围被拒绝，类似的另一些却顺利通过（评论）。Stan91111 在 Mac 上遇到的情况更绕：任务先确认收到了转来的同意，随后审核又把它驳回了（#51834 下的评论）。

这几种同意看起来应该算数，其实不算

在目标任务里同意，再让 Dot 接着推进。jflamb 在 Mac 上直接在目标会话里给了同意。Dot 读回来时确认那是用户本人发的消息，可它继续推进这个任务的尝试还是被拒绝；另外几次尝试的结果是“user cancelled MCP tool call”，而当时根本没人取消。最后 jflamb 只好自己在那个任务里发下一条消息（#51783）。
菜单里选了完全访问。Azad-Zhang 在 Mac 上给 Dot 创建的任务选了“完全访问”，菜单也显示已选中。可 Dot 在这个任务里的下一轮，仍然只能写工作区，并且要走自动审核；同一台 Mac 上手动创建的任务就能拿到完全访问（#50671）。grtninja 在 Windows 上也遇到同样的情况，执行任务的环境只能写 /workspace 目录（评论）。The25maze 则发现，每个新的 Dot 任务都会重新受限，审批请求也到不了 Dot 对话和 iPhone，结果每次都得回到 Mac 前面处理（评论）。
在任务里输入 /approve。rjaus2026-coder 在 Windows 上同意过的一次诊断，开始前就被拒绝了两次。他们在任务里输入 /approve，它只被当成一条普通聊天消息发出去，也没有出现被拒操作的列表（#51558）。
一个并不存在的审批提示。anotb 的 Dot 让他们去协调任务里点同意。可他们找不到任何提示，因为那个任务里只显示一条正常完成的回复和“完全访问”。后来 Dot 自己更正了这个说法（#50887 下的评论）。

最后是怎么通过的

到任务里再同意一次。10 月 9 日，cedar_circuit 在主对话里同意让任务用浏览器只读查看一个仪表盘，结果被拒。他们打开那个任务，在大约 UTC 03:07 直接点了同意，03:10 前检查就跑完了。当天早上同样的事又发生了一次，他们再到任务里直接同意，要求的两个合并请求才建了出来（OpenAI 社区）。
让完整草稿和同意一起送过去。cedar_circuit 的另一个例子是一封带 PDF 附件的邀请，被当成未经许可分享文件而拦下。等完整草稿连同收件人和附件，跟他们的同意一起转过去以后，邀请才发了出去（同一帖子）。
自己动手输入。“うんよろしく”这句转达被拒以后，moruku36 自己把同样的请求输进了本地 Codex 对话（评论）。
小而明确的操作。gro83j 单独同意过一次测试，把一个 29 字节的文本文件上传到自己的 Library，这次没有弹出额外提示就完成了。10 月 9 日，103654716-ux 看到一条已同意的消息顺利送达，读回来一字不差；可同一任务后来要改一项设置，虽然也同意过，还是又被拒绝了（评论）。
先在任务里同意，再检查任务的应用权限。nickcaracappa 让 Dot 通过一个现有的“General”对话来协调工作。一开始要的是只读审查，后来又明确同意了一项自动化清理，交接却一再被拒：转过去的同意被当成不受信任的内容，最初的只读限制也还在。直接在执行任务里发出同意以后，消息才送到 General；可 General 接着又停在“Tool call requires approval, but approval policy is never”这一步，而 nickcaracappa 原以为 General 开的是完全访问权限。OpenAI 支持团队 10 月 7 日回复说，Dots 的访问权限和已连接应用的权限是分开管理的，开了完全访问，也不代表每个应用操作都能免批准执行，建议检查这个任务的已连接应用权限和批准设置（OpenAI 社区，10 月 2 日）。

Dot 能读任务，却建不了也续不上

这是另一种报错，结果却差不多：工作停在半路。

robjshore（Windows 和 iOS）。Dot 能列出保存好的 Codex 云端环境，也能读任务结果，可它每次创建任务都报 UNKNOWN。在同一个环境里手动启动同样的任务，却能正常运行。Dot 想接着推进手动创建的任务时，得到的是 CloudThreadNotFoundError（#52135）。
b0ggs（Mac 和 iOS 上的网页版）。10 月 8 日，给现有云端任务发后续消息还很正常，后来开始返回 UNKNOWN。重置环境、手动新建对话都没用：Dot 能读到新任务的指令，可给它发消息就返回 NOT_FOUND（#52374）。
crystal-xiaoxiao。10 月 8 日，一个定时 Dot 任务创建的云端任务还能完成提交、推送和 Pages 部署。从 10 月 9 日起，不管是定时触发还是手动要求，创建任务都返回 UNKNOWN（#52374 下的评论）。
n572770（Windows，10 月 12 日）。在同一个 issue 里，n572770 的 Dot 能读到一个已有的任务，往里发消息却报 UNKNOWN。把 Windows 桌面应用从 26.1002.7124.0 升级到 26.1007.2314.0 之后，后续消息又能在同一个任务里开出新的一轮，任务也不用重建。至于到底是升级起了作用，还是 OpenAI 那边恰好同时恢复了，n572770 也说不清（#52374）。
TDove（10 月 15 日）。多个 Dot 能列出已保存的 Codex Cloud 环境，也能读任务结果，但通过 Dot 创建或继续任务时返回 AppServerBackendRequestError，error_code: UNKNOWN。在 Codex 直接界面里创建并下载同一个任务是成功的（约 15:58 UTC，SHA256 一致）。另一次通过 Dot 继续用手建好的任务，返回的是 CloudThreadNotFoundError / NOT_FOUND——TDove 认为这可能是访问边界，不宜直接当成和创建失败同一原因（OpenAI 社区）。

Codex 以外也有同样的规律：可以看 Dot 是什么里讲审批的部分、Dots + GitHub 里卡住的 GitHub 写入，以及 Dots + Gmail 里报“user cancelled”的发送失败。

Dot 建的任务会落在哪里，以及找回任务的办法

审批通过以后，接着出现的问题是找不到活。Dot 开对话、建任务的速度比你点开的速度快。不少用户报告：任务没进原本想放的项目、从侧边栏消失、钉不住，或者之后发的消息找不到它。这些报告都在公开的 openai/codex 问题列表里。其中没有一例是活本身丢了，但有好几位只能通过 Dot 才找得到它。

对话没进你想放的项目

houmark（Mac，10 月 9 日）。Dot 会开出多余的替代对话，有时把新活接在一个不相干的旧对话里，明明知道是哪个项目，也没把对话放进去。事后想把这些对话移进项目，会报错"The task's source project could not be safely determined"，拖拽也拖不进去。新建任务时直接指定项目是可以的，但他在补充说明里写到，这样建的几个任务里，还是有两个显示为不属于任何项目（#52489）。
meotimdihia（Mac，10 月 8 日）。Mac 显示已连接、已授权，Dot 却列不出侧边栏里的项目（"DesktopProjectsUnavailableError"），也没法在项目里建对话（"local_project_unavailable"）。它之前没指定项目建的对话，即使工作目录设成了项目文件夹，也没有出现在项目下面（#51922）。Windows 上的 yixiiiiiii（评论）和 Kamber88（评论）、Mac 上的 zromio（评论）情况一样：在电脑本机上能列出项目，从 Dot 那边就不行，重新连接、重启应用或重启电脑都没用。
一个平台修好了，另一个还没有。10 月 9 日，imyhxy 说 Linux 上的 26.1007.21434 版已经修好。同一天，0923yukimi 在 Windows 上还是 26.1002.52244，检查更新却显示已是最新版。10 月 10 日，songimony 的 Windows Dot 列项目和建任务都超时，家里 Wi-Fi 和手机热点都试过，但读取已有的云端任务、给它发消息都正常（#52793）。

任务从侧边栏消失，再通过 Dot 找回来

easyvibecoding（Mac，10 月 7 日）。重启以后，云端任务从侧边栏里没了，Dot 那边的列表却是完整的。让它重新读其中一个，也只回来了那一个（#51675）。退回到旧版 26.930.61225 后任务都回来了，Colin-Bao 在另一台 Mac 上降级、再升级，也看到了同样的结果。
AbraxasSH56（Windows）。前一天用「打开对话」（Open chat）找回来的对话，第二天重新打开应用又不见了（评论）。
rizlah。让 Dot 给出任务链接，点开以后，任务才会出现在侧边栏里（评论）。
najibninaba（Mac，10 月 10 日）。换到更新的 26.1007.21159 版以后，Dot 建的任务在它的"最近活动"里都在，历史也能看，但侧边栏"最近"里只剩一个（评论）。
RFinal3（Windows，10 月 8 日）。Dot 建的一个本地任务顺利完成了，却不在侧边栏里。它在 Dot 资料页的"已完成"里，从那里打开以后就出现在侧边栏了（#52231）。NaturalMatchaKing 的一个云端任务也是这样，从 Dot 对话里打开后就回来了（#52733）。
Nver-theless（Windows，10 月 8 日到 9 日）。断网恢复以后，自建的侧边栏分组里，六个已知的云端对话只显示出两个。有的打开就报"thread access denied"，Dot 自己去读，却还能读出其中三个旧对话的原始消息。过了一天，这个分组又空了（#52129，补充）。

置顶和状态跟实际情况对不上

RowboTony（Mac，10 月 8 日）。刚开始几天，他的做法一直好用：Dot 开一个会话，进行中就置顶，做完再取消置顶。后来，Dot 开的对话点「置顶对话」（Pin chat）没有任何反应，用鼠标点和用快捷键都一样，已经置顶的 Dot 对话也取消不了置顶（#52305）。
SlopSurfer4444（Windows，10 月 8 日）。在 Dot 启动的任务里，新建的子代理还在干活，就直接出现在"已完成"下面，委派出去的活从一开始看起来就像已经做完了（#52282）。

对话明明还在，消息却找不到它

chemamiranda（Mac，10 月 7 日到 8 日）。一个本地 Codex 任务 10 月 7 日还成功给 Dot 发过消息，之后再发就提示"thread not found"，而这个 Dot 在应用里照样看得见、用得了（#52197）。
Kamber88（Windows，10 月 8 日）。这位用户的 Dot Lexi 没法给一个空闲的本地 Codex 对话发一条只读的测试消息（"CloudThreadNotFoundError"）。Lexi 检查了自己的工具，发现手里只有处理云端任务的工具，读取和联系本地对话的工具根本不在（#52222）。
paul-berthelot（10 月 9 日）。Dot 建云端任务，不论从手机还是电脑都报 UNKNOWN，哪怕只是读一下 README。同一个已保存环境里的同一个只读任务，直接在网页版 Codex 里启动就能跑（#52449）。
Mechanus-IQ（Windows，10 月 3 日）。应用版本 26.930.3930.0，刚启动时连接一切正常，别的对话也能打开，但有几条较早的 Dot 线程还是打不开。大多数返回「thread not loaded」，有一条返回「The caller does not have permission to execute the specified operation: thread placement belongs to a different actor」，而登录令牌刚刚刷新过。他们查看应用保存的本地状态，发现同一个账号和工作区下缓存着两个不同的用户标识：普通对话对应其中一个，Dot 的活动记录大多对应另一个。按他们的理解，有些 Dot 建的线程是从远端历史里列出来的，却被线程服务拒绝了，这更像身份对不上，而不是网络问题。为了不影响排查，他们没有改动任何东西（#50561 下的评论）。
Jeremy Devz（YouTube，10 月 5 日和 8 日）。Jeremy Devz 是一名软件工程师，用名叫 Fro 的 Dot 做开发。Dot 直接读取已有的本地 Codex 任务、给它们发消息时，一直报访问错误。在这套环境里管用的绕法是：让 Dot 新建一个叫“Dot Bridge”的任务，把本地任务的深层链接交给它，由这个桥接任务去读取那个本地任务、发一条测试消息，再确认消息已经送到；桥接任务最后把结果报告给 Dot。这个办法能用，只是每来回一次，都要多等一个任务。
Christopher Comparán（@ccomparanv，10 月 13 日）。他在回复 @reach_vb 介绍 10 月 5 日到 9 日更新的帖子时写道：即使给了准确的线程 ID，他的 Dot 还是没法直接给一个已有的本地 Codex 线程发消息，发送时报错“CloudThreadNotFoundError: The cloud thread was not found.”，和 Kamber88 在 10 月 8 日报告的错误一样。

OpenAI 10 月 5 日到 9 日更新里的改动

OpenAI 在 10 月 5 日到 9 日的更新里说，Dot 现在"更会判断什么时候接着已有的 Codex 线程做、什么时候新开一个"；它管理的线程会随工作进展自己改名，多余的"已创建任务"消息也少了；侧边栏加载更快，加载失败的活动可以重试。上面 10 月 9 日和 10 日的 Windows 和 Mac 报告，都是在这份更新之后提交的。

让 Dot 接手你自己开的 Codex 线程

OpenAI 在 10 月 5 日到 9 日的更新里说，Dot“可以在 Codex 里开始工作，也能接着已有的线程继续”。试过的用户提交的报告，说明了这句话在哪些情况下成立、哪些情况下还不成立。所有报告里的分界线都一样：线程是谁开的，在哪里运行。

能正常读取的：

Dot 自己建的任务。Takanashi-Rikka1（Windows，10 月 10 日）对一个 Dot 建的任务和四个自己手动开的线程做了同样的读取：Dot 建的那个能读出消息，Dot 也能列出这台电脑上的本地项目（#52873）。
云端对话。Jacob11701 在 iPhone 上使用 Dot，同一次对话里其他已有的云端对话都能读到（#50698 下的评论）。
部分以前手动开的线程。Mills713（Mac）和 OKhan99（Windows）都各有一个旧对话能正常读取，旁边的其他对话却读不了（#52331，#52873 下的评论）。

仍然读不了的：

你在 Codex 应用里自己开的本地线程，不管新旧。Takanashi-Rikka1 的四个线程分别报“unsupported placement format version 2”“version 3”“placement region 10”，不属于任何项目的那个对话则报“thread not found”。报 region 10 的线程是更新之后专门为测试新开的。marekfindlay 早在 10 月 4 日就遇到过同样的情况，读的也是刚建的本地任务（#50698 下的评论），所以问题并不只出在旧对话上。
两个平台、各种设备上都是同一个报错：BSMuse 用的是 Windows 26.1002.52244（评论），whalemans-club 用的是 Mac（评论），Jacob11701 则是从 iOS 读 Windows 电脑上的对话。
给本地任务指定 ChatGPT Work。Worrybaf 的 Dot 能看到这台 Windows 电脑已连接并已授权，但它创建本地任务的唯一途径里没有选择 Work 还是 Codex 的选项。用户要求“只用 Work”时，Dot 选择不建任务，而没有悄悄改用 Codex（#52863）。
又一例 Mac 上的本地对话。liuzhihang（macOS，10 月 11 日）发现，Dot 能读它自己建的 Codex 任务，却读不了已有的本地 Codex 对话，报错是"unsupported placement format version 1"，而原生的 read_thread 工具本身是能用的（X）。
Windows 上，Work 任务读得到，Dot 自己却读不到。iAmBoosted（@letsgetboosted，10 月 13 日）把一台 Windows 电脑连到了 Dot 上。在那台电脑上开的 Work 任务能打开一个已有的本地 Codex 对话，Dot 自己去读时却报错「unsupported placement format version 2」。请 Dot 查一查之后，它回答说，这个对话里用不了原生的线程工具（list_threads、read_thread 和 send_message_to_thread）；之前那次读取成功，走的是桌面任务的应用权限，而不是 Dot 自己的权限（X）。
自己开的线程，Dot 因为权限被拒。Eloitay（10 月 13 日）发现，如果 Codex 线程是自己开的，Codex 会以权限为由拒绝 Dot。Dot 于是请 Eloitay 到那个线程里发消息，可是在线程里一发，就报错「Error: AbsolutePathBuf deserialized without a base path」（X）。Eloitay 还说，即使给了线程 ID，Dot 有时也打不开那个线程（X）。
仍然读不了本人开的线程，也往 Dot 建的线程里发不了消息（10 月 13 日）。Jenna / Dusklight（@Dusklightapp）回复 @reach_vb 说：Dot 仍然看不了 Jenna 自己开的任何 Codex 线程，也仍然没法在 Dot 建的线程里发出任何内容。
仍然看不到 Codex 会话——「还是肉身中转」（10 月 13 日）。Peter Johann Medina（@PeterJ_Medina）问 @ChatGPT：为什么 Dot 仍然看不到自己的 Codex 会话，并说自己还在当肉身中转。和上面的 Windows、Dusklight 报告同一类：本人看得到会话，Dot 看不到，每一次跟进都还得经过主人。

为什么看起来是读取途径的问题，而不是权限问题：

whalemans-club 从 Mac 这边核对过：Mac 上的 Codex 应用把这个线程标为本地线程，读取完全正常；Dot 手上却只有云端的读取工具，没有 Mac 本机读取线程的那个工具。YouAI-Liu 也发现了同样的差别，Mac 上的本地执行器能读到的对话，Dot 读不到（#52247）。Takanashi-Rikka1 按账号列出的 30 个线程里，恰好没有读取失败的那两个，归档列表也是空的。OpenAI 还没有确认原因，所以这只是报告指向的方向，不是定论。

哪些做法没用，哪些做法让工作继续下去：

对 Takanashi-Rikka1、Mills713 和 nittajun 来说，更新桌面应用、重新连接电脑、撤销后重新授权、新建项目，报错都没有变化（#50698 下的评论）。真正让工作继续下去的有两点。第一，OKhan99 直接在 Codex 桌面应用里输入指令时，原来的线程照常工作，可见线程本身没坏，坏的只是 Dot 进入它的途径；通过语音通话发出的请求则返回“送达情况未确认”，重复发送之前最好先去线程里看一眼（#50698 下的评论）。第二，既然 Dot 自己建的任务都能读取，新工作最稳妥的做法就是从一开始就让 Dot 来建任务，而不是自己先开好线程、过后再把链接交给它。对于旧对话，liuzhihang 的临时办法是让另一个 Codex 代理把线程的历史转述给 Dot，这样能用，但要多花一份额度；liuzhihang 向 OpenAI 提的要求，是让 Dot 能直接以只读方式读取这些对话。iAmBoosted 的报告还指出一条可以试的路：Dot 读不到的对话，连着的那台电脑上的 Work 任务却能读到。所以可以请 Dot 在那台电脑上开一个 Work 任务，读完线程再把内容转告你。

任务停住或者丢了电脑，可以看 Dots 不显示或用不了；在 Dot 自己的电脑上跑长任务，可以看云端电脑。

Dot 在你电脑上开的任务，实际能用哪些工具：Computer Use、实时终端和读线程工具

OpenAI 的指南说，你的 Dot「可以创建本地的 Work 或 Codex 任务，也可以继续已有的本地 Codex 任务」，还说「本地技能需要连接电脑」（Connect computers and apps）。另一页又写明，连接电脑并不等于 Dot 能访问你已有的每一个 ChatGPT 或 Codex 对话（Tasks and memory）。下面的报告从另一个角度说明了同一个缺口：电脑连上了，设置也打开了，可是 Dot 在这台电脑上开的任务，并没有拿到你自己在 Codex 里干活时能用的全部工具。

大家发现少了什么

Windows 上没有 Computer Use。Blizzme（ChatGPT 桌面版 26.930.31730，PowerShell 7.6.6，10 月 3 日）已经打开了 Computer Use，连「Any app」也勾上了，用自己的 Codex 代理时一切正常。通过 Dot 发起的一次无害 PowerShell 测试，在这台电脑上也顺利跑完了。但任务自己的诊断显示，无论是已有的本地任务，还是新开的隔离任务，都没有说明里提到的 Computer Use 接口；去取补充的技能文件时，返回的是「skill environment is not available for this callback」。Blizzme 已经在帖子里问 OpenAI，Dot 发起的任务到底支不支持 Computer Use，OpenAI 目前还没有在帖子里回答。
看不到可以盯着的终端。Blizzme 还希望 Dot 发起的命令能在一个看得见的 Windows 终端里运行，既能看到实时输出，也能自己随时停下来。一次 30 秒的测试跑完了，却始终没有弹出窗口，也没有任何输出，因为这类任务是在后台运行的。
另一台电脑上也一样。gelbuilding（Windows，10 月 9 日）让 Dot 帮忙开发自己的软件时，两个问题都遇到了。把 Codex 的沙盒改成「unelevated」以后，命令又能跑起来了，这个开关在 Dots 不显示页面里也有介绍；不过 Computer Use 并没有因此回来，gelbuilding 也提醒，这样改会削弱隔离保护。
Mac 上缺了读你自己线程的工具。pimenov（Codex 应用 26.1007.21159，10 月 10 日 UTC 14:09）在让 Dot 管理的一个读取任务去读一段已授权的 Codex 对话之前，先查看了这个任务的工具清单，结果发现原生的列出线程和读取线程两个工具都不在里面。其他功能都正常：Mac 已经连接并授权，Dot 能在上面创建任务、读取任务、发送后续指令，任务也能读取允许访问的文件。上一次成功读取已有对话，是在 10 月 6 日 UTC 21:20。pimenov 还没有试过重启桌面应用。
Dot 跟不上一个已有的线程。sudeepcm（10 月 9 日）在一个已有的 Codex 线程里开始了新一轮工作，请 Dot 帮忙跟进。每次读取都返回「unsupported placement region 4」，跟上文「让 Dot 接手你自己开的 Codex 线程」里说的是同一类错误。
沙盒和 Windows 之间复制文件。otsune（10 月 13 日，日文）发现，之前虚拟环境和 Windows 之间没法复制文件的 bug，已经在没有任何通知的情况下修好了；同时也说，现在常常得出手拦住 Dot，免得它去试一些笨办法。
Windows 上，Dot 自己开的线程找不到。Austin Miller（10 月 13 日）说，Dot 开的 Codex 线程他很难找到、也打不开，用他自己已有的本地线程也不顺。Computer Use 在他自己开的 Codex 对话里能用，经过 Dot 就时灵时不灵。他希望自己管理本地项目时，不必再在中间来回传话。
笔记本显示已连接，读线程的工具却不在。Eduardo Vidal（10 月 13 日）说，他收到最多的回复是“Your laptop shows connected, but the thread tools aren't available”（笔记本显示已连接，但线程工具不可用），并问怎样设置才不用在 Dot 和 Codex 之间来回切换。

用一台权限受限的家用电脑，接手从手机发来的开发任务（desktopgame）

不是每个人都把日常用的电脑直接交给 Dot。desktopgame（Zenn，2026 年 10 月 12 日，日语）想在外面用手机给 Dot 下指令，让家里的电脑接着做开发；可那台电脑上有代码仓库、配置文件和各种凭据，直接交出去不放心。于是 desktopgame 另外准备了一台 24 小时开着的跳板机：上面运行 ChatGPT 桌面版，作为 Dot 的电脑连接，用的是一个没有管理员权限、名叫 dot 的本地账号，设成不会自动休眠，并一直接着电源。Dot 再从这台机器用一把权限受限的 SSH 密钥，登录主力电脑上另一个没有管理员权限的账号 dotdev，这个账号只能在 AgentShare 文件夹里工作。权限有没有划对，可以用 net localgroup Administrators（看 dotdev 有没有被加进管理员组）和 icacls C:\AgentShare 检查。代码通过放在 AgentShare 里的裸仓库（hub）来回传递：做到一半的项目克隆进去，Dot 从零写的项目也克隆进去，之后双方照常推送和拉取。只归 Dot 使用的「纯净」仓库里，从来不放 .env 之类的文件。desktopgame 说，人在家时这套做法已经顺手很多；人在外面时，有些操作还是只有带管理员权限的账号才能做。在 iPad 上搭远程桌面用起来不舒服，Rundeck 和 OliveTin 也不太合心意，现在正在自己写一个工具。

只在网页上出现的线程、慢吞吞的交接、Windows 浏览器报错和登录不了时的退路

下面这些一手报告都发在 10 月 5 日到 9 日那次更新之后。它们说明了从 Dot 把活交给 Codex 时，哪些地方还会出错，以及每个人是怎么处理的。

73. Eliot Gevers：线程、批准和状态对不上

Eliot Gevers（@EliotGevers）从早期就开始用 Codex，这次一口气发了 8 条反馈。跟 Codex 协作关系最大的是这几条：Dot 建的线程在 ChatGPT 网页上能看到，在桌面版和手机 App 里却找不到；给 Dot 的批准常常传不到它开的任务里，Eliot 只好逐个打开线程再批准一次；「Cloud」也让人糊涂，有的线程用的是自己的 Mac，Mac 离线也能接着跑，有的线程却完全在远端运行。Eliot 还觉得状态更新说得含糊，很难分清哪些在跑、哪些做完了、哪些验证过、哪些卡住了；正在进行的工作也常常要反复催，才会接着做下去（X 帖子）。同一天早些时候，Eliot 写道，用 Dot 在 Chat、Work 和 Codex 三处之间统筹工作「一团乱」，Mac 上和手机上显示的线程都不一样（X 帖子）。

74. Stefan：接手本地 Codex 线程时报 CloudThreadNotFoundError

Stefan（@stefan_rem）发现，自己的 Dot 没法接着做一条已有的本地 Codex 线程，一接手就报 CloudThreadNotFoundError；全程留在本地的协调倒是正常。Stefan 想要的链条是：Dot → 本地协调器 → 各个专项会话 → 子代理，并且进度能在桌面版里看到（带截图的 X 帖子）。在这一环打通之前，按他的报告，比较稳的分工是让本地协调器负责电脑上的 Codex 线程，Dot 只在上面统筹。

OpenAI 社区里有人把同一个问题一步步复现了出来。10 月 14 日，stefan.remberg 先在本地 Codex 对话里、在一个已有的桌面项目下新建了一条本地线程，确认它显示 hostId: local，也完成了一条固定回复；然后把完整的线程 ID 交给 Dot，请它往这条线程里再发一个最简单的任务，并明确说不许新建线程。Dot 返回 CloudThreadNotFoundError，说消息没有送达，也没有另建替代任务；再读一遍原线程，确实什么都没收到。Greasy 回复说，自己的 Dot 从第一天起就看不到、启动不了、也接不上任何本地的东西。一周前，stefan.remberg 就提出过这种交接需求：Dot 理需求、改提示词都做得很好，可任务最后都变成了云端会话，跑在项目的一份副本上，依赖、链接的包、本地配置、正在运行的服务和仓库以外的文件都不在，有些构建和预览链接也打不开。他让 Dot 在原来的文件夹里建一个本地任务，Dot 说 Mac 已连接，接着就报了 DesktopProjectsUnavailableError。Daareek 的回复可以当成一份检查清单：交接时要把三样东西说清楚，一是具体是哪个项目或工作树，二是任务实际看到的环境，三是它被允许做什么；对不上时应该明确报出原因停下来，而不是悄悄退回到云端副本。所以在任务动手改任何东西之前，先让它报出这三样。

75. まー：直接交给 Codex 几十分钟，经过 Dot 要好几个小时

まー（@Mv4n2WUMDj97918）用日语写道，同样的活，以前直接交给 Codex 几十分钟就能做完，现在经过 Dot 转交，几个小时都没有进展。帖子里列了几个可能的原因：指令写法、GitHub 连接，或者任务运行的环境，最后还自嘲了一句「不是说睡一觉起来就做好了吗」（X 帖子）。如果委派的任务比直接用 Codex 慢很多，先看看它是不是在等批准，或者跑在了你没想到的地方（参考上面 Eliot 的反馈，以及前面讲批准为什么传不到任务里的那一节）。

76. BUILD LOCAL LAB：只有让 Dot 开浏览器时，Windows 才报错

BUILD LOCAL LAB（@BuildLocalLab）在 Windows 上让 Dot 打开电脑里的 Chrome，结果报错 MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003，有时后面还会跟一句「trusted Node process exited unexpectedly; kernel reset, rerun your request」。他们跟 OpenAI 支持一起排查后发现：同一台电脑、同一个 Chrome，从另开的本地 Work 会话（@Chrome 和 @Computer）去用就一切正常；支持要求跑的 7 项只读 PowerShell 检查（SystemDrive、SystemRoot、windir、ProgramData、USERPROFILE、LOCALAPPDATA、APPDATA）也全部通过。支持团队交代不要改沙盒、环境变量和安全设置；重装和修改 approval_policy 都没有用。他们眼下的办法是：浏览器相关的活改交给 Work 会话，同时关注仍未关闭的 openai/codex #52407，以及 #53255 等同类报告（X 帖子 · 详细说明）。

77. はまち：Dot 电脑上的 Codex 登录不了，就改用 Dot 的浏览器

はまち（@hamachi_ttr）想每小时查一次 ChatGPT 用量的重置日期。Dot 自己电脑上的 Codex 一直通不过认证，はまち就先在 Dot 的浏览器里登录 ChatGPT，再让 Dot 排一个日程：每小时在那个浏览器里查看重置日期和重置次数，然后把结果写进日历，有变化就更新（X 帖子）。这件事不大，却说明了一个好用的退路：Dot 电脑上的 Codex 登录不上时，只读的检查往往可以改在 Dot 的浏览器里完成。

用进度 Site 当前台、让 AI 在 Slack 里互相审计划，以及一个把额度用光的模型设置

前 4 个是作者自己跑通的做法，后 2 个是提醒，适合在把大任务交给 Dot 之前先看一看。

78. 月花凪：用进度 Site 当前台，后面接 Codex CLI

月花凪（@TukikaNagi）用日语写道：只要做到「人只需要和 Dot 对话」，事情就会轻松很多。做法分两步：先给 Dot 建一个管理进度的 Site，通过 MCP 接上；再把路打通，让这个 Site 能启动本地电脑上的 Codex CLI。这样 Dot 就成了前台窗口，活被分到本地的多个 CLI 会话里去做，进度也会在 Site 上跟着更新。视用途不同，月花凪还会再加上 MCP Events（X 帖子）。在后一条帖子里，月花凪说对很多人来说，这大概是把熟悉的 ChatGPT 当成私人助理来用的最省事的办法（X 帖子）。MCP Events 能让 ChatGPT 根据 MCP 服务器上的更新采取行动，是 DevDay 发布的功能之一（What's new）。

79. もちもちもっち〜：让两个 AI 在 Slack 频道里互相审计划

もちもちもっち〜（@sr_motcii）先让另一个 AI（作者称它为 fable）写好实现计划，然后建了一个 AI 之间可以互相商量的 Slack 频道，在频道里把计划交给 Dot。双方一起检查计划里有没有遗漏、实现之后的测试还缺什么，一轮一轮把计划改得更准确。按作者的说法，这套流程现在不需要もちもちもっち〜插手，就能自己跑起来（X 帖子）。

80. たかっかMk.3：让 Dot 收拢散在各个 Codex 项目里的信息

たかっかMk.3（@takakka_mk3）总结了自己最后的分工：Dot 用来整理、汇总散落在多个 Codex 项目和对话里的信息，也用来办一些交代得很随意的杂事；认真的调研仍然交给普通的 ChatGPT 对话（X 帖子）。如果你的 Codex 工作分散在很多线程里，这种分工很实用：收集的活交给 Dot，需要仔细核对的调研放在你看得见过程的地方。

81. Parker Lapeyre：用模拟会议告诉代理该修哪里

Parker Lapeyre（@parkerlapeyre）让 Dot 开出一批子代理，用 Parker 正在开发的一款策略应用来模拟开会，标出设计碍事的地方，改完再来一轮。按 Parker 的说法，这几乎成了一个「自我改进的循环」：每一场模拟会议都会给代理找出一处具体要修的地方（X 帖子）。

82. Alp Z：只提过一次模型，额度就用光了

Alp Z（@az372184）有一次告诉 Dot 可以用 Astra UltraCode。从那以后，Dot 不管做什么都用 Astra UltraCode，把 Alp Z 的全部用量和 OpenAI 赠送的 20,000 点额度都用完了。Alp Z 是在查看重置前的用量时才发现的。现在 Alp Z 已经让 Dot 默认使用 6.1 Sol，并且认为 Dot 给 Codex 任务挑模型时应该更聪明一些（X 帖子）。如果你跟 Dot 提到某个模型，最好说清楚是只用于这一个任务，还是以后都这样用。

83. Kevin Kaiser：语音通话交不出 Codex 任务

Kevin Kaiser（@kyza____）在 10 月 14 日写道，过去两天里，和 Dot 语音通话时，任务总是交不到 Codex 那边，于是去问 OpenAI 的 @reach_vb 这是不是已知问题（X 帖子）。帖子没有说打字下达的任务是否正常。在语音通话页里，6 位语音请求卡住的用户中，有 3 位改用文字发出同样的请求后都顺利送达，所以可以先试试这个办法。

本地 MCP 工具缺失、Windows 浏览器初始化失败，以及要等好几分钟的权限卡

下面这些来自公开的 openai/codex 议题，都是 Dot 把活交给 Codex，只是失败点分别落在 Mac 上的本地 MCP、Windows 上的浏览器初始化，以及权限卡的等待时间。

84. Stuart Hughes：Dot 发起的任务拿不到本地 MCP 工具

Stuart Hughes 在 macOS 桌面端 26.1007.30912 上，把 Apple-MCPs（apple-tools-mcp v1.1.0）注册成了全局 Codex MCP 服务器，又做成了本地插件。同一台 Mac 上的普通本地 Codex 对话可以调用这些工具——聚合健康检查、Reminders 列表、Mail 邮箱、Notes 账户——用 MCP 客户端对着同一个可执行文件还能列出 184 个工具。但当 Dot 在已连接的 Mac 上发起本地任务、要求列出 Reminders 时，任务回报服务器在本地已注册，却不在可调用工具里；它能看到的命名空间是 mcp__codex_app、mcp__codex_apps 和 mcp__computer_history，外加电脑操控和自动化工具，没有 Apple Reminders 工具。把同一可执行文件再打成名为 Apple Tools Local 的纯 MCP 本地插件后再试，结果一样（openai/codex#53136，10 月 11 日）。

85. yvesgagnongesys：Windows 上 Dot 委派的浏览器初始化失败，直接会话却能用

10 月 14 日，yvesgagnongesys 在同一台 Windows 电脑上看到三件事。经 Dot 创建的本地任务在浏览器清单之前就失败了，报错是 trusted Node process exited unexpectedly; kernel reset, rerun your request——有限重试和完整重启 Codex 之后依旧如此，因此拿不到标签页或 LinkedIn 页面内容。用户另开了一个直接的本地 Codex 会话、明确请求本地 Browser 插件后，已登录的 LinkedIn 公司后台可以打开，分析也在推进。用户把该直接会话的 codex://threads 链接交给 Dot 后，用 cloud_threads.read 读同一个线程 ID，返回 AppServerBackendRequestError: thread not found，而会话在用户这边仍然可见。委派任务本身存在、可以打开，也会把结果回给 Dot；失败的是浏览器工作和在不手工复制的前提下读取直接会话的结果（openai/codex#53998）。

86. COOLak：自定义规则的权限卡最长要等约 26 分钟

COOLak 在 macOS 上的 ChatGPT Dot 项目会话里，统计了 10 月 12 日到 14 日自定义规则权限卡的等待时间。从房间记录里找到 31 条创建/更新自定义规则卡的条目，并列出所有不少于 30 秒的「请求到出卡」间隔。这些等待里包括约 7 分钟、8 分钟、5–7 分钟的几次，以及测到的最长一次 26 分 12.557 秒（10 月 14 日项目工作者协调）。在那次最坏情况里，后续续跑时真正的建卡工具调用大约 4.1 秒就返回了，所以端到端的 26 分钟并不能算成校验器跑了 26 分钟。好几次等待期间，用户的追问没有回应；10 月 14 日父代理也承认，权限讨论卡住了下一轮开发交接，子任务处于空闲。卡出现到可见结果的间隔（含人工决定时间）同样偏长，有的「未保存」结果要等 10–23 分钟才报出来（openai/codex#54068）。

全局 AGENTS.md 缺失、托管任务 MCP 要求登录、交接时批准丢失，以及 Codex Cloud 上的 UNKNOWN

和上一节一样，这里也都是 Dot 把活交给 Codex（或本机任务），只是失败点分别落在指令加载、托管任务上的 OAuth MCP、「给 Dot 的同意」在执行任务里算不算数，以及通过 Dot 创建或继续任务时报 UNKNOWN，直接用 Codex 界面却一切正常。

87. SmithLabsLLC：Dot 发起的任务拿不到全局 AGENTS.md

在 Linux 桌面端 26.1007.71326 上，SmithLabsLLC 把 Dot 新建的本地任务，和同一台电脑上的全新 Codex CLI 会话（0.162.1）做了对比，两边都不在平时的工作区里。在任何工具调用或读文件之前，Dot 创建的任务就报告：全局 ~/.codex/AGENTS.md 策略以及其中两个具名小节，都不在它收到的启动上下文里。随后明确要求它去读这个文件，读取成功，并按文档里已有的认证路径核对了 GitHub 身份。CLI 会话不用工具就能直接引用那两个小节，本地启动记录也确认用户指令消息里已经带上了这两段。更早一次 Dot 任务曾走了另一条 CLI 认证路径，碰到无效会话，还要求重新登录——其实文档里的现有路径是通的；读完策略后诊断就纠正了，凭证并没有改。他们用的变通办法是：要求每个委派任务在做实质工作前，先读全局策略和相关操作手册（openai/codex#53873，10 月 14 日）。

88. ElkhornPacific：本地对话里 OAuth MCP 能用，Dot 托管任务却报 Auth required

10 月 13 日（Windows 10.0.26200，Codex 包 26.1007.2314.0），ElkhornPacific 在「设置 > 插件 > MCP」（Settings > Plugins > MCPs）里完成了 OAuth MCP 服务器的认证。本地 Codex 对话（日志里 hostId=local）可以调用这些工具——包括对自定义 Open Brain 的只读 list_projects(limit=1)，以及对 nates-library 的 list_guides(limit=1)。同一批连接，在 Dot 创建带本机权限的托管/委派任务时（hostId=durable）却初始化失败：MCP 启动在 initialize 握手阶段报 Auth required, when send initialize request。新建委派任务、退出并重启桌面应用、再到共享设置里重新认证，托管路径仍然失败，本地路径却一直是 ready。托管启动日志里，supabase-personal-readonly 和 nates-library 也有失败记录。自定义服务器的访问令牌还没到一小时过期（约 UTC 15:10 登录后，15:15 左右第一次托管失败）时，托管路径就已经挂了（openai/codex#53726）。

89. ptown16801-lang：给人的批准在 Dot → 本机任务交接里丢失

10 月 12 日，ptown16801-lang 用托管 Dot 协调已连接的 Ubuntu Linux 上现有的 Codex 任务。人在主 Dot 对话里（含语音）给出了指令和有范围的批准。Dot 经支持的任务消息接口，把指令转发给一个已经存在的本机 Codex 任务；接收方看到的是委派内容，而不是原生的直接用户消息。在一次不完整的审阅之后，人明确授权发送更正后的审阅载荷（含原始提示词和平台报错上下文）。自动批准审阅在执行前就拒绝了这次更正后的发送。同任务再试一次仍被拒，理由是所谓的批准只出现在不可信的委派内容里，而不是可信的用户消息。任务表示批准必须在执行任务里由用户直接输入。之后的恢复检查发现，协调对话里没有任何待处理的批准标识，也没有可用的批准/恢复控件。更正后的外部代理审阅最终没有确认完成。同一次跟进里还有单独的投递确认症状：返回 UNAVAILABLE / voice_parent_unconfirmed，结果不确定；它和批准被拒是不是同一原因，目前不清楚（openai/codex#53481）。

90. TDove：Codex Cloud 上创建或继续任务报 UNKNOWN，直接界面却能用

10 月 15 日，TDove 报告：多个 Dot 能列出 Codex Cloud 环境、也能读结果，但只要通过 Dot 去创建或继续任务，就会返回 AppServerBackendRequestError / UNKNOWN。同一条创建并下载的路径，在 Codex 直接界面里是成功的（约 15:58 UTC，SHA256 一致；请求 ID a0779ca2… / a7143718…）。另一次通过 Dot 接手用手建好的任务，返回的是 CloudThreadNotFoundError / NOT_FOUND。这和上面的 robjshore、b0ggs 属于同一类：再多批准几次也解不开 UNKNOWN，在 Dot 路径恢复之前，直接界面是可用的退路。

天天用 Dot 跑 Codex：一直开着的电话、一张任务表、一位重度用户遇到的摩擦和一个家庭实验室

这几位每天都把 Dot 当成 Codex 和 Work 会话的总台来用。Senple 和あやみ用日文写了长时间开着电话时会遇到什么，以及几件活同时进行时怎样掌握进度；Mete Polat 列出了重度用户用 Dot 搭配 Codex 时仍然会卡住的地方；ketoru 则把 Dot 接进了自己的家庭实验室。

91. Senple：电话一直开着，让 Dot 同时跑 3 到 5 个 Codex 会话

Senple 用 100 美元的 Pro 套餐大约三个月，在工作中用 Codex 和 Claude Code 已经一年多。10 月 12 日，他在 Qiita 上写了用电话而不是聊天、通过 Dot 跑 Codex 的经验（Qiita，日文）。他让电话一直开着，只要开口 Dot 就会回应，这样一边做家务也能用手机继续干活，而且语音回答比聊天里的回复精简得多。他碰到的限制是：电话大约要 20 秒才接通，一次通话到两小时就会断，放在后台也一样；马上再打过去，有时会像占线一样被挂断。每次问进度，Dot 都要先说一句「我去确认一下」。

通过 Dot 用 Codex 时，Codex 是以子会话的形式运行的。他给 Codex 设的输出规则没有生效，harness 也不像直接用 Codex 时那样工作，规则的传递并不稳定。Dot 同时跑 3 到 5 个 Codex 会话时，不会自己去取这些会话的回复；并行派活以后，任务也开始出现遗漏。它还有过说自己查过资料、其实并没有查的情况。他发现有用的做法是：每个调查任务都设一个期限，让它到点把已经找到的内容报上来；要求定期汇报；不同的目标分别交给不同的会话。他把两个请求放进同一个会话时，第一个做完，整个会话就被标成了完成。

92. 名古屋彩美（あやみ）：让 Dot 当派活的总台，再配一张人看得懂的任务表

10 月 15 日，名古屋彩美（あやみ）把一期播客整理成 NewsPicks 上的文章，讲她怎样把 Dot 当成「任务管理 AI」来用（NewsPicks，日文 · 节目视频）。她请 Dot 帮忙把电子报自动化时，Dot 新开了一个 Work 会话，把背景和要做的事写进指令，做完后回到她和 Dot 的对话里，简短报告做了什么、有没有出错，细节则留在那个会话里。需要用到她本机文件夹、工具和技能的本地项目，以及要操作她电脑上应用的活，她都交给 Codex。Dot 还会注意到她没交代的事：她在健身房网站上取消了预约，Gmail 收到了取消邮件，Google 日历里的日程却还在；Dot 把邮件和日历对照后提醒了她，并先问她能不能删掉这条日程。

问题出在后面。一个对话里同时进行五件事时，Dot 清楚每件事的进度，她自己却跟不上了。于是她让 Dot 用「ChatGPT 网站」做了一张任务表：每接一件活，Dot 就登记成任务，开始时改状态，做完标成完成，例行工作也放在里面。她看着这张表跟 Dot 说话，比如「这件为什么停了？」「还没开始的话就开始吧」。她也会在 Slack 里 @ Dot 派活、在同一个线程里收到回复，或者直接打电话交代。

93. Mete Polat：批准传不出去、本机只能绑一台，以及 Dot 看不见的 Codex 浏览器页面

Mete Polat 从上线起就天天用名叫「Satori」的 Dot，并写了 Dot 搭配 Codex 时仍然容易出问题的地方（Substack）。同一篇文章里讲通话的部分，见通话案例页；下面只讲和 Codex 有关的摩擦。

他在 Codex 自带的浏览器里打开了一个页面，旁边就是和 Dot 的对话，然后让 Dot 在那个页面上做事。Dot 看不见那个页面。同样的页面放到另一个独立的 Codex 线程里，那个线程里的代理就能正常操作。

Dot 自己拉起的另一个 Codex 线程需要批准时，他在 Dot 对话里说了「Approved!」。Dot 没办法把这次批准转进那个线程，他只能自己去侧边的一堆对话里找到那条，再手动点同意。

Dot 这边对本机好像只有一个「槽位」，而且要明确配对。想把 Mac mini 当成 Dot 的本机时，得先解除 MacBook 的配对。人不在家时，他就只能让 MacBook 一直开着，没法直接用家里的 mini。

他们正在聊一件事时，他又交代了一件无关的活。Dot 把这件活塞进了当时正在讨论的同一个 Codex 线程，把不相关的上下文混在了一起。

他曾经让 Dot 把社交帖子的链接记进每日笔记。后来这件事在没打招呼的情况下停了。他问起原因时，得到的解释也说不通。

他还经常看不清 Dot 到底在不在干活、在干什么。名字下面偶尔闪过的状态很短、很糊，也不会一直留着；为他开的那些侧边线程，侧边栏也并不都能看见。他拿 Muse 作对照：Muse 名字下的状态更稳定、更好懂，点一下头像还能看到完整的活动与状态记录。

94. ketoru：手机里的想法 → Issue → Mac mini 上的 MCP → Linux 上的 Codex

10 月 5 日，ketoru 在 Qiita 上用日文写了自己怎么把 Dot 接进家庭实验室、当作前台调度。他可以在手机上说「我想要这样的 Web 应用，先写成 Issue」、问「接下来适合做哪个未完成的 Issue」，再让 Dot「把这个 Issue 往下推进」。Dot 负责整理需求、该查什么、在哪台机器上做、哪些要他点头；代码的调查、实现和审阅交给 Codex，有时在 MacBook 上跑，有时在 Linux 机器上跑。

他几乎把一台 Mac mini 交给智能体当作业环境，而不是自己的日常电脑。mini 上跑着 MCP 服务，Dot 和本地 Codex 通过隧道共用同一套资料检索和管理工具。轻量和需要 macOS 界面的确认留在 mini；吃 GPU 的重活交给会休眠的 Linux 主机。两台树莓派分别做入口（AdGuard、Tailscale、Caddy）和资料／监控／NFS 节点，这样即使 Linux 服务器关掉，他还能继续商量需求和翻实验室文档。Dot 自带的云电脑仍可用，但实验室资料放在 mini 上，为了速度和稳定他主要在那边做。

目标与有风险的步骤仍由他本人选定和批准；日常交接由 Dot 和 Codex 往下推。这篇是一手搭建记录，不是带计时的对比评测。

复制这份任务说明

怎么让 ChatGPT Dot 指挥 Codex？先看结论：Dot 已经能当好 Codex 的协调人，但批准、你自己开的线程和本地工具都还不够稳。这里有 6 步设置方法、批准传不到任务等常见卡点的解决办法、一条可直接复制的指令，以及 94 个真实案例。

下载 Markdown ↓