How to use a ChatGPT Dot with Codex: delegating tasks, overnight PRs, approvals and 94 real cases

The short version: what works, how to set it up, where it gets stuck

Can a Dot run your Codex work?

Partly. A Dot is already a good coordinator for Codex: it opens the threads, passes your brief along, follows the work while you're away and tells you what is ready. Kurt Bell woke up to a fixed bug and a morning report, Eduardo's Dot merged 16 PRs while he was out at dinner, and 余佳恆 now leaves ticket reading, task splitting and merging to the Dot while Codex implements. It isn't yet reliable as your only way into Codex. Approvals you give in the Dot chat often don't reach the task, it often can't continue Codex threads you started yourself, and tasks it starts on your computer can lack the MCP tools and AGENTS.md your own Codex sessions get (cases 73, 74, 84, 87, 89 and 93). It suits developers who already use Codex, are happy to let the Dot start the tasks, keep merge and deploy for themselves, and don't mind opening a task now and then to approve it.

How to set it up

1. Create the Dot (getting started), then from the desktop app connect the computer and apps the work needs (Connect computers and apps); repositories are covered on Dots + GitHub. On that computer, sign in to Codex and allow remote connection. That was polaris's fix when soloist's Dot could only develop on its own cloud computer.
2. Decide where each job runs. A new local task needs that computer online with the ChatGPT app open. A cloud coding task runs in a Codex cloud environment you created beforehand, with its repo and setup, and your computer can be offline. The Dot's own cloud computer isn't a target for Codex tasks, which is why u/dry_towelette99's first launch failed until he connected a spare Linux machine. Changing the Dot's selected computer later doesn't move a task that already exists (Tasks and memory), and Mete Polat could pair only one of his own computers at a time (case 93).
3. Smoke-test first: "List my open Codex tasks for [repo]. Don't start a new one yet." After that, let the Dot start new tasks itself. In Takanashi-Rikka1's tests, the task the Dot had created was the one it could read and follow later, while threads started by hand failed. To hand over an existing thread, name it, say what should change, and ask for one read-only read first.
4. Brief every task the same way: repo, project, goal, acceptance check and where it should run, one goal per task, with a time to report back. Name the project before the work starts, because moving a Dot-created chat into a project afterwards failed for houmark. If your work depends on ~/.codex/AGENTS.md or runbooks, tell each task to read them first; that is what fixed SmithLabsLLC's tasks (case 87).
5. Set the rules up front: a test for every fix, draft PRs only, and merge, deploy and delete wait for you, as in Kurt Bell's and @bezzabuilds's overnight runs. Name the model to use by default, because a single mention became Alp Z's default (case 82).
6. Follow the work from Activity. In the desktop app, open your Dot's profile, select Activity and open a task to see its progress, files and results; if it is waiting for a decision, a sign-in or an approval, respond there (Control your dot). Away from the desk, ask for one status list or a morning report in Slack or on a short call, or have the Dot keep a task board, as あやみ does (case 92).

Where it gets stuck, and what fixed it

• Your yes in the Dot chat doesn't reach the task. The task's review treats an approval the Dot forwards as untrusted text, even word for word (gro83j, moruku36, cases 73, 89 and 93). What fixed it: open the task from Activity and approve there, as cedar_circuit and moruku36 did; approve one exact action, with the full draft, recipients and attachments in view; and if the task then stops with "approval policy is never", check that task's connected-app permissions, which OpenAI Support told nickcaracappa are set separately from Dots access. A Full access checkmark didn't always reach the Dot's next turn (Azad-Zhang), so ask the task to report the access it actually has before long work. Don't keep retrying the same relay: progressorZ's retry was treated as an attempt to get around the first denial.
• A task looks slow but is really waiting. まー's job sat for hours through the Dot (case 75), Eliot had to nudge and approve thread by thread (case 73), COOLak's permission cards took up to 26 minutes (case 86), and Kamimoto's failed Codex install went unreported until he asked "status?". What helped: a report time for every job and a status list that says "waiting for you" instead of "running" (Senple in case 91, Kentaro Mori), plus a board the Dot updates whenever a state changes (あやみ, case 92). Tell it to update the board without being asked, because itsplayai found it otherwise only does so when asked.
• Tasks go missing from the sidebar or land in the wrong project. In these reports the work itself was never lost: houmark's chats ended up outside the project, Chase's task landed in Recents, and RFinal3's finished task wasn't in the sidebar. What fixed it: open the task from the Dot's profile (Activity or Completed) or from a link the Dot gives you (RFinal3, rizlah), name the project before the work starts, and ask the Dot for each task's state instead of reading the sidebar, which showed SlopSurfer4444's running subagents as Completed.
• The Dot can't continue a Codex thread you started yourself. Sends fail with CloudThreadNotFoundError or an "unsupported placement" error although the thread works fine in the Codex app (Stefan in case 74, Kamber88, Takanashi-Rikka1). What worked: let the Dot start new work itself; for an existing thread, keep driving it in Codex and paste the Dot a summary, or have the Dot open a new task on that computer that reads the thread and reports back (Jeremy Devz's "Dot Bridge", iAmBoosted's Work task). Stefan's split also held: a local coordinator owns the threads on the computer, and the Dot sits above it.
• Creating or continuing a task returns UNKNOWN or NOT_FOUND. This isn't an approval problem, so more approvals won't help (robjshore, b0ggs, case 90). What worked: start the task by hand in Codex (robjshore, TDove); update the desktop app (imyhxy's DesktopProjectsUnavailableError went away on Linux, and n572770's Dot could continue a task again after a Windows update); and ask the Dot to check for an OpenAI incident before you debug your own setup (Dave).
• A task on your computer doesn't get your local tools. Dot-started tasks were missing local MCP tools (case 84), the global AGENTS.md (case 87), OAuth MCP servers that work in a local chat ("Auth required", case 88), Computer Use (Blizzme) and the thread tools (pimenov, Eduardo Vidal). What helped: have the task list the tools it can actually call before the job starts; tell it to read AGENTS.md and your runbooks first, which worked for SmithLabsLLC; and run any part that needs a missing tool in a Codex chat you start yourself. Dot-started tasks run in the background, so if you need to watch a terminal and stop it yourself, run that part in Codex too (Blizzme).
• On Windows, the browser or commands fail only through the Dot. BUILD LOCAL LAB (case 76) and yvesgagnongesys (case 85) got browser start-up errors that a direct session didn't have, and after one update Whanzo's tasks couldn't even run Get-Location. What helped: send browser jobs to a separate local Work session (case 76) or a direct Codex session (case 85), and when a task breaks, ask for a fresh one rather than resuming it (ngderf). The "unelevated" sandbox switch got gelbuilding's commands running but weakens isolation, so only use it if you've decided that trade is worth it. When Codex on the Dot's own computer won't sign in, a read-only check can often run in the Dot's browser instead (case 77).
• The allowance goes faster than expected. One mention of a model became Alp Z's default and used up the whole allowance (case 82), and habibi woke up to 0% Codex usage and six new tasks. Work handed to your local Codex uses your Codex allowance (polaris), and どりゃー saw a job sent through the Dot draw on Dots usage too. What helped: set the default model yourself, give loops a number of rounds or a result that ends them, and point the Dot at an existing PR instead of explaining the job from scratch (どりゃー).
• Voice calls don't hand off. Kevin Kaiser's calls stopped passing tasks to Codex (case 83), and Senple's calls dropped at the two-hour mark (case 91). What helped: send the same request by typing; on the voice calls page, three of six stalled voice requests went through that way. Before repeating a voice request, check the thread, because deliveries can come back unconfirmed (OKhan99).

What it can and can't do yet

What it already does well:

• Opening Codex threads, passing along the brief and summarising the result (John Voorhees, Diana Park, XiaoYao).
• Fixing bugs overnight with tests and pull requests (Kurt Bell, Vaibhav Sisinty, Lao Zhang's Windows port as a draft PR), and stopping before merge or deploy when your rules say so (Kurt Bell, @bezzabuilds).
• Merging a batch of PRs while you're out, waiting for CI and solving conflicts along the way (Eduardo, 16 PRs).
• Running several Codex jobs at once and giving you one picture (@donghyuk65, Paul J Lipsky, 余佳恆's six of seven priority tasks).
• Steering other agents too: Claude Code over SSH (Ryo Tsukuda), your own MCP server (yusen), a whole team of AIs (Kentaro Mori).
• Keeping a progress page or task board you can read and give instructions from (月花 凪 in case 78, あやみ in case 92).
• Finding an OpenAI incident before you debug your own setup (Dave).

What it doesn't do yet, or not reliably:

• Passing your approval from the Dot chat into a task (cases 89 and 93).
• Reading or continuing local Codex threads you started yourself (case 74).
• Giving its tasks your local MCP tools, global AGENTS.md or OAuth MCP sign-ins (cases 84, 87 and 88).
• Opening the browser from a Dot-started task on some Windows PCs (cases 76 and 85).
• Using two of your own computers as its local machine at once; Mete Polat could pair only one (case 93).
• Telling you what is running, finished or blocked without being asked (cases 73 and 93, Ethan2438).
• Handing off reliably from a voice call (case 83).
• Windows and Android development on its own Linux cloud computer; Robert Ellison expects to need another virtual machine for that.

One prompt to copy

Built from what worked for Kurt Bell, @bezzabuilds, Kentaro Mori and Senple (case 91), the AGENTS.md fix in case 87 and the default model in case 82, and written to avoid the approval and UNKNOWN problems above:

You coordinate my Codex work on [repo]. For each job, start a new Codex task yourself inside the [project] project, on [my Mac / the Codex cloud environment], with one goal per task. Write the repo, the goal and the acceptance check into it, and tell it to read ~/.codex/AGENTS.md and [runbook] before anything else. Use [model] unless I name a different model for one task. Test every fix and open draft PRs only; merging, deploying and deleting wait for me. Keep one status list with each task's name, link, where it runs and its state (running, waiting for my approval, stuck, ready for review, done), update it yourself whenever a state changes, and send me a summary at [time]. When a task needs my approval, tell me the exact action and which task to open in Activity, and I'll approve it there. If a task is missing a tool it needs, or creating or continuing it fails twice with UNKNOWN or NOT_FOUND, stop and give me a ready-to-paste prompt so I can start it myself.

Prompts for single problems, such as approvals, finding tasks and missing tools, are under More copyable asks at the bottom.

Who this is for

You write code with Codex and want a ChatGPT Dot (OpenAI Dots) to act as the coordinator: open Codex threads, watch them overnight, merge or review only when you say so, and tell you on your phone what is ready. Below are 94 named, first-hand cases from developers who did this in the first weeks after DevDay, each linked to the original post, video or issue. They are grouped first by the job people gave the Dot, then by where it got stuck: approvals that don't reach the task, tasks that are hard to find again, and tools missing from tasks on your own computer. The advice above comes from these cases; case numbers point to the numbered cases, and names to the others further down.

Quick answers

What can a ChatGPT Dot do with Codex? It acts as the coordinator: it opens Codex threads, passes along what you want, follows them while you're away and tells you what's ready. John Voorhees spins each big idea into its own Codex thread and leaves his Dot to manage it, Shingo Irie had his Dot open a thread in the Codex app on his Mac, and Diana Park's Dot, "EA", mostly finds the right thread and gives her an executive summary. 余佳恆 now has the Dot read tickets, split and assign the work, check it and merge, while Codex only implements and reviews. 名古屋 彩美 has her Dot open a Work or Codex session for each job and keep a task board up to date, so she can see which one has stalled (case 92).

Where does the work actually run? There are three different places: the Dot's own cloud computer, a computer you've connected (it has to stay online with the ChatGPT app open), and a Codex cloud environment you created beforehand. They aren't interchangeable. u/dry_towelette99's launch failed because the Dot's cloud computer isn't a target for Codex tasks, and it worked once he connected a spare Linux machine. When something seems to go missing, ask the Dot which of the three it's using, as Eliot's and Stefan's reports below show.

Does it use up my Codex allowance? Codex or Work tasks your Dot starts count toward those products' limits, and work the Dot does itself is separate (pricing). That's why @uhak_crew saw his usage barely move and 余佳恆 still had 96% of his Codex allowance left, while @ev.gert nearly hit his Codex limit on the $100 plan. polaris adds that work handed to the Codex on your own computer runs on your allowance, and どりゃー found that a job sent through the Dot also draws on Dots usage.

Can I leave it to fix bugs and open PRs overnight? Yes, and the cases that worked kept merge, deploy and delete behind the owner's yes. Kurt Bell woke up to a fixed bug, a fixed data issue and a morning report, with an enhancement tested but not shipped. Eduardo's Dot merged 16 PRs while he was out for dinner, and @bezzabuilds's rules stop it merging or deleting anything without him.

Why doesn't my yes in the Dot chat reach the task? The task's review treats an approval you gave in the Dot chat, and the Dot then forwarded, as untrusted text, even word for word. gro83j and moruku36 were both refused that way. What worked for cedar_circuit and moruku36 was approving inside the task itself: open it from the Dot's profile under Activity and answer there.

What do CloudThreadNotFoundError, UNKNOWN and DesktopProjectsUnavailableError mean? They mean the Dot can see the work but can't start or continue it, so more approvals won't help. robjshore and Stefan got CloudThreadNotFoundError continuing an existing thread, b0ggs got UNKNOWN and NOT_FOUND, TDove's Dots could list Codex Cloud environments and read results but create/continue returned UNKNOWN while the same tasks worked in the direct UI, and meotimdihia's Dot couldn't list the Mac's projects at all. Starting the task by hand worked for robjshore and TDove. imyhxy reported the projects error fixed on Linux in desktop app 26.1007.21434, so update the app before anything else.

How do I start? Create the Dot, connect the computer and repositories the work needs from the desktop app, then test with "List my open Codex tasks for [repo]. Don't start a new one yet." A Dot comes with Pro outside the EEA, UK and Switzerland, with Business Premium, and with Enterprise once an admin turns it on (How to get ChatGPT Dots, Dots in the EU and UK). When to use the Dot, Codex itself or ChatGPT Work is on Dots vs Codex vs ChatGPT Work, repository setup on Dots + GitHub, and a Dot that stopped answering on Dots not showing or not working.

Handing work to Codex and keeping the Dot as coordinator

• Sam Diaz (Creative Tech). In My AI Team: 7 Ways I Use ChatGPT Dots + Codex for Real Client Work he walks a podcast-studio client project end to end: the Dot keeps the project organised and plans the next steps, Codex handles technical execution, and he gives direction and reviews the results. Chapters cover following through while he is unavailable, giving Codex a clear job, making the website more useful, researching potential customers, turning that into marketing, and producing creative work. He also shares what made an overnight client handoff work, and why confirming access and follow-up still matter.
• John Voorhees (MacStories), Dot "Puck". His fix for a crowded single Dot thread: when an idea becomes a full project, spin it into a Codex thread and leave the Dot to manage it. He had done this several times and called it a reliable way to cut traffic in the main thread. New Codex threads do not know what was in the last one unless someone passes the context along. MacStories first look
• Chase (Chase AI), Dot "Winston". On a voice call he asked Winston to open a new Codex thread in an existing project and build a website comparing Dots use cases. Winston set up the thread, handed over the build and checked the product claims as it went; the site ended up live. One quirk: the task landed in Recents instead of inside the project folder. YouTube
• Shingo Irie (@iritec_jp). From his Dot he opened a new thread in the Codex app installed on his own Mac and gave it instructions there. His reaction: "this can do anything." X post
• Daniel Mac (@daniel_mac8). His screen recording shows the Dot creating its own ChatGPT and Codex threads, then sending messages into those threads on its own while it works. X post
• u/Fantastic_Self_5151 (r/codex). He sends his Dot to tell a Codex instance on his other machine what to do and bring back the result, or to work it out between the two until it runs. He calls it a huge time saver. Reddit
• @donghyuk65. He says it feels like being the team lead now: "fix this", "run that in Codex", "make an image", "where are you up to?", and the Dot answers right away. He throws several Codex jobs at it in parallel and asks the Dot for the overall picture instead of checking each one. Cloud work keeps going with his own computer switched off. Threads
• @uhak_crew. He asked his Dot to find contests to enter, check the feedback emails and work them into his plan, then click through his product and plan UX fixes. When he asked for the planning document, the Dot handed the work to Codex, reported back, and stepped into the Codex session to correct it whenever Codex drifted off course. Done straight in Codex, he says, that would have used up a week of his allowance; this way his usage barely moved. Threads
• Kevin Ly (@thedadintheloop), Dot "Dex". From his phone he asked where a project was up to; Dex checked his connected Mac and listed what was finished and what still needed building. The lookup took a while and needed clarification, and his first call did not connect, but he liked having one place to ask about his Codex projects. Instagram
• 伊藤貴將 (Itopan, note), Dot "シバット". He builds several apps with Codex and kept losing time finding where each project lived and how far it had got. Now he tells the Dot the project name, which Mac it is on (his MacBook Pro), the reference material to use and what he wants finished, and the Dot picks the work up from there. For his 3D lung and diaphragm app "身の内" it read lecture notes saved on the Mac and added a guide for observing the body's shape and movement; it also continued a 3D North Alps viewer. While an app job ran, he talked to the Dot about other pieces and came back to check results. Naming the project, the machine and the documents is what made "carry on with that" work; he still hit browser errors, slow replies and the odd mix-up of context. note, 3 Oct 2026, in Japanese
• Diana Park (@madebydia), Dot "EA". On 14 Oct, replying to @_simonsmith, she wrote that she named her Dot EA and that it mainly manages her Codex threads: it saves her hunting for the right thread for a topic or project, passes along what she wants, and gives her an executive summary of the result. She called it the best mental model she has found for a Dot so far.
• Sarrazola (@sarrazola). On 13 Oct he wrote that his Dot didn't feel as powerful or flexible as Hermes, yet he ended up using it far more, because it's connected to his whole Codex setup. He now uses it to orchestrate dozens of threads and projects and hundreds of conversations.
• Matthew MacKinnon (@MatthewMacK). On 14 Oct he told @thsottiaux that he now runs all of his Codex work from his Dot, so the new composer predictions in Codex are no use to him, and asked for them in Dots as well.
• XiaoYao (@XiaoYaony). Replying to @libukai on 14 Oct, XiaoYao wrote in Chinese that the most useful part of the latest Dots update is that the Dot can now read ChatGPT chats directly and dispatch Codex tasks. That is what lets XiaoYao use the Dot as a project manager. Before, the Dot could only open a separate cloud task and then search the other chats, and passing messages between them was a hassle.
• bbshark (@bbshark_13), Dot "Bob". On 14 Oct bbshark described the setup to @thsottiaux: ideas and design happen in a chat, and the briefs go into git. Bob the dot reads them, plans the integration, hands it to Codex to build, and keeps managing Codex so the work doesn't stall. bbshark runs Codex on fast and still finds it slower than before.

Bug fixes, tests and pull requests while you're away

• jammyrob28 (OpenAI Community, 12 Oct 2026). He talks about several projects in one Dot conversation, hands work to Codex, and comes back to results instead of copying instructions between chats. One concrete path: he reported missing sound in his Android game; that went through investigation, a fix and a new Expo build, which he tested and confirmed. While he was at work the same day, the Dot prepared Play Store descriptions and graphics. They also built a separate daily-challenge prototype and used local Codex on his home PC to check things while he was away. Outside coding, it spotted Google account-security alerts and checked whether he had made the changes (he had). He still reviews and tests the work; remote approval prompts are still rough. Community thread
• Kurt Bell (@softypapa). He went to bed with a software bug and a data issue and woke up to both resolved: the Dot worked through them, tested and verified the fixes, and left a morning report. It also found and tested a possible product enhancement but did not deploy it without his approval. X post
• Kurt Bell again, on a walk. On Oct 8 he asked his Dot for a status update while out walking: 1,148 tests had passed by the time he was halfway around the block. X post
• Vaibhav Sisinty. For his overnight test he gave the Dot one goal: read the alpha bug reports, fix the latest bug, create a PR, and reply in Slack once it's merged. His video shows the Dot reading the code on GitHub, fixing the bug, opening the PR, and posting to Slack after the merge. He calls it a coworker that finishes the job. Instagram
• @rennsong, Dot "benny". He now routes all his engineering work through the Dot, which delegates across threads and cloud environments and follows up on open tasks. While looking into one issue, benny found another major bug in an adjacent function and asked whether it should put out a draft PR. X post
• Eduardo (@martiano), Try Omarchy release. He left for a walk and dinner while the Dot merged about 15 PRs, waited for CI, solved conflicts, then built the app and updated packages. The phone notification he shared says all 16 PRs were merged and the work was ready for him to take over. X post
• @bezzabuilds. He gave the Dot a standing overnight job on his app: find and fix bugs with tests that prove each fix, propose and build new features, send each one to a "critic" agent until it scored well, then record a demo video. He woke up to 3 finished features waiting for review. His rules stop it from merging or deleting anything without him. Instagram
• @DevAdventur3s. He had told Gabriel Chua at DevDay about a Codex bug (screenshots bloating chats). Later he phoned his Dot from his deck: it found the old Codex thread, filed the bug report through the Codex CLI, and sent Gabriel a DM to follow up. X post
• @huke1484. While working with Codex, this developer handed an in-progress code review to the Dot and reports a decent result. The same Dot runs modelling work around the clock. Threads
• Robert Ellison, personal Pro plan. Software development on the go was his main reason for getting a Dot. By 9 Oct it had fixed three bugs and shipped one feature on his blog, working through the GitHub integration and driving Codex, and it added tasks to his Todoist so he would review those fixes later. His blog deploys straight from GitHub, so each change went live as soon as he approved the PR. The limit he hit: he does a lot of Windows and Android development, and the Dot's Linux cloud computer is fine for booking an Uber but not for those builds; he may need another virtual machine for it. Dot Log
• Ai学习的老章 (Lao Zhang, 人人都是产品经理). He had only released his open-source audio-generation workbench for macOS, and readers kept asking for Windows. He gave the Dot one instruction before bed: port the project to Windows, pass all the tests and build a portable version that needs no installer. On its cloud computer (Debian, 9 CPU cores, 9.7 GB of memory, 32 GB of disk by his check) the Dot cloned the repo, installed the Node and Electron toolchain and reworked the audio layer. In the morning there was a separate branch with a draft PR: 101 unit tests, 19 interface tests and 9 tests on real Windows Electron passed, including launching the packaged EXE, and GitHub Actions had built a portable package of about 158 MB for Windows 10 and 11 (x64) that runs without Node or Python installed. 人人都是产品经理, 3 Oct 2026, in Chinese
• clggest (linux.do). On a project he had vibe-coded, his GitHub Actions minutes had run out. He had the Dot follow the existing Actions workflow on its own cloud computer, build the project there and push the release. His own computer stayed clean and he no longer needed a virtual machine; by his account, none of it used his Codex allowance. linux.do, 30 Sep 2026, in Chinese

Parallel threads, subagents and queues

• @kagamitei. He gave his Dot a big task from late night to morning, running 6 subagents at full power, as a test. It was work he normally hands to Codex, and he says the result was just as good; in his experience Codex usually opens only 2 subagents. Threads

• 余佳恆 (@tachichocolate). Reading tickets, understanding and splitting tasks, assigning work, acceptance checks and merging now all go to the Dot; Codex only does implementation and review. A later screenshot shows six of seven priority tasks run by the Dot since morning while his Mac's Codex handles one, with 96% of his Codex allowance left. Threads: ticket to merge · Threads: 6 of 7 tasks

• 鮑聖文 (@nbaobao24). Codex felt too slow on its own, so he had his Dot manage his Pi AI agents and Codex directly. He says his output went up about four times. Threads

• Seth Rosen. He uses his Dot as the orchestrator for Codex work across design, testing, demos and strategy, with more parallel threads under it. X post · related post

• Pat Simmons (AI for Mortals), Dot "László". László found Code Queue, the board his agents use, checked the MCP connection and scheduled a weekday 9 PM Slack summary. On a call it reported 137 issues in progress and 122 in review, mostly stale; he had it propose which to close in Slack and close them only after his approval. AI for Mortals

• Gabriel Chua (@gabrielchua, OpenAI employee). He used to keep one or two Codex threads that orchestrated other Codex threads; now he asks his Dot. His screenshot shows the Dot starting a local fix thread that checks which repo owns the app, then reproduces and tests the fix. X post

• Thomas Ricouard (@Dimillian, works on Codex at OpenAI). Working on his game during a flight, he had the Dot coordinate tasks between his MacBook Air at home and cloud tasks. X post

• Ethan2438 (LINUX DO). Ethan2438 sees the Dot as a chief that hands the real work to the sub-agents behind it; by their count it can call up to six, so seven agents including the Dot. The sub-agents' status isn't shown by default, so Ethan2438 had the Dot write a simple page that monitors them, and asked other users for better ways to watch the work. OpenAI's Control your dot page points to Activity in the desktop app, under the Dot's profile, which lists the tasks a Dot delegated with their progress, files and results. LINUX DO, Oct 3, Chinese

• Grumble8167 (LINUX DO). Same-day report on 10 Oct: drop a repository onto the Dot, let it pull the code onto its cloud computer and run tests there. Grumble8167 found it faster and smarter than 6.1sol for that workflow, closer to Astra, and able to run several jobs at once without the usual "dumbing down" under concurrency. LINUX DO, in Chinese

• dafire (LINUX DO). In the same thread, dafire treats the Dot mainly as a coordinator: about six workflows can run at the same time. They also warn that the cloud workspace can reset without a fixed schedule, so projects living there should be saved to Space in time. LINUX DO, in Chinese

• Paul J Lipsky (one call to three tasks). In an Outskill-sponsored YouTube video (4 Oct 2026; sponsorship disclosed), Paul called his Dot and handed it three jobs at once: research ChatGPT Spaces into an outline on the Obsidian note he already had for a Tuesday video; open the existing Codex thread for his Dayboard app (the Obsidian-linked version) and add a basic in-app markdown editor that saves back to Obsidian notes with an "Open in Obsidian" button; and, in the existing Codex thread for his game Schmela, fix stuck walking/climbing on steep hills plus unlimited arrows and faster movement in god mode so he can bug-hunt faster. The Dot lined all three up on the call (research underway for the Spaces note; Dayboard editor queued; Schmela fixes queued) and, he says, stays on the threads until the end goal is reached, with phone notifications when it needs him.

• supernovae (@byron_miller). supernovae pays for Codex rather than for Dots alone, and uses the Dot for the orchestration that lets work run unattended (X, 11 Oct). The Dot spins off tasks that each keep their own chat history, which supernovae finds easier to manage than a stack of bots (X), and tracks them as cards moving from to-do to WIP to done on a Notion board (X). The result was "about 100 PRs this week", with one permission problem left: the Dot can't use the SSH keys inside Codex (X, 13 Oct). On Windows the Dot couldn't use SSH or WSL2 at first (X, 12 Oct); after it read a public Codex issue and tried the workaround there, it could SSH from PowerShell, as described on Dots + GitHub.

• Drake (@Copypaster3000). Drake made a Codex skill for the Dot named "sup". It reports which tasks are running, which recently finished or are waiting for review, and what is still in the queue. Drake wrote that they have been using it a lot. X post

• Authority Hacker (@authorityhacker). With Codex allowance left before a reset, they told their Dot (13 Oct, with a video) to go and find useful work and prepare it for them to review.

• Jialin (@0xjialin). After using Dots for a while, Jialin wrote in Chinese on 14 Oct that the Dot had been handed more and more tasks with no single place to manage them. Seeing which were moving, which were stuck and which needed a decision meant asking again or scrolling back through the chat, and once there were enough tasks, the tasks themselves got forgotten. The post offers an idea for others to hand to their own Dots rather than a finished build: a personal task board deployed with ChatGPT or Codex Sites, where the Dot updates progress, blockers and suggestions, each item links back to its chat, and finished work leaves behind its results, lessons, and skills worth improving. One reply, from itsplayai, says this didn't help: the Dot won't update task status by itself and only does it when asked.

Beyond Codex: Claude Code, your own MCP server, a fleet of agents

• Jason Rivard (@j.t.rivard). A Claude Code session on his machine was sitting there waiting for him, so he phoned his Dot about it. The Dot opened his Remote Control–enabled Claude Code sessions in the browser on its own Linux computer, told him what the session was waiting on, and typed in his answer. He calls it a silly use case but a real one. Instagram

• @ev.gert. He had nearly used up his Codex limits on the $100 plan, so he added Claude and built everything around the Dot. For each task the Dot asks Jev which agent should take it, then sends it on itself: to its server, to Claude, to his local machine, or to a program or script it starts. He got tired of forwarding messages between the agents and gave them a shared Google Doc, where they now write to each other directly. Threads

• yusen (@yusen0411). He didn't want to hand OpenAI full control of his computer, so he connected his Dot to an MCP server he runs himself, which decides which tools, folders and commands are allowed. Through it the Dot read and edited files, ran programs and listed his installed software. His finding: working on his own cloud host was clearly faster than reaching back into his local machine, while the local route keeps the data and permissions in his hands. Threads

• 도리 (@dori.2678). He ran a performance test of his Dot and had it build a simple test harness. His verdict: it barely used his Codex allowance, did the work neatly and rarely overstepped. Threads

• Kentaro Mori (SeaOtter on Zenn), Dot "ドッチー". A cloud engineer, Mori spent 1–7 October as product owner for a team of AIs, with the Dot sorting requests, deciding which agent and which machine took each job, and reporting progress: ChatGPT and Codex for design and review, Claude Code for implementation, Gemini and Antigravity for prototypes and research, and Qwen for local GPU tests. On day one only 3 of 9 planned tasks finished; the other six waited on Mori's decisions, copied prompts and hand-offs through a local GUI. On day four a hand-off from the Dot to ChatGPT or Codex stopped on an approval, and a bare "waiting for approval" didn't say what to allow, so Mori now asks for the action, the permission needed and what is already done. From day five Mori gave instructions mostly by voice and had the Dot report every 30 minutes with numbered items ("do 2 first"), but the numbers shift once finished items drop off, so instructions are checked against task names. On day six, with web sign-ups, profile updates and video assets added, it became hard to tell which parallel job was running and which was waiting. On day seven the Dot switched priorities to an urgent application, and one result was a verification comment on an existing Mattermost pull request. Mori's habits after the week: a brief with goal, scope, out of scope, environment, acceptance check and report; implementation and review done by different agents; "implemented", "mock test passed", "works in the real environment" and "accepted" treated as different states; and a 10-minute voice wrap-up at the end of each day. Zenn

• ishizakahiroshi. A freelance engineer, ishizakahiroshi sends jobs to the Dot by Slack DM from two places: ChatGPT with the Slack plugin, and Claude Code with Slack's MCP plugin. Every job gets a number from a personal ledger and a folder in the repo with three files: README.md (goal, scope, what not to touch, where to deliver, done criteria), REVIEW.md (what a separate reviewer checks) and PROGRESS.md (stage, owner, status, evidence, next step). The Slack message links the instructions at a pinned commit, so the Dot reads the version that was sent, and its first reply has to say which commit it read, whether the tools it needs work, and which branch it will deliver to. Replies arrive in the job's thread, not at the top level. A read-only script elsewhere flags any repo with no change for 60 minutes, a threshold ishizakahiroshi chose. Once the Dot's environment couldn't fetch a dependency and that step was done locally; a large issue went over two hours without a pull request, so jobs are now cut to 30–60 minutes each. Merging, publishing and checking the live page stay with ishizakahiroshi; the write-up itself, with its five images, was written by the Dot. Zenn

• Ryo Tsukuda (Zenn). He runs Claude Code on a Linux PC on his home network and used to watch the screen so he could type /clear each time a small task finished, to keep old context from eating tokens. Now he writes the big development goal into his Dot, and the Dot works through his Windows PC (connected via the ChatGPT app), opens an SSH session to the Linux PC, gives Claude Code one small task at a time and runs /clear when a task is done. It judged the break points from progress, not by time or a count. Because the goal and progress live in the Dot, a cleared Claude Code session still gets its next task, so he can leave it running overnight and check the result in the morning, with lower token use. What it takes: both PCs stay on around the clock, he clears the Dot's own chat himself, and the SSH route is his own setup, not a Dots feature. No scripts; everything was natural-language instructions. He notes the write-up was drafted by AI from his own notes. Zenn, 9 Oct 2026, in Japanese

• ぞう (zou_aidouga, note). On launch day, with only a Mac connected and no apps, ぞう tried each thing once. A task from the Dot to Codex went through and the Dot checked the result. Claude Code started but asked for a login when given work; ぞう's guess is that the Mac's sign-in doesn't reach the Dot's runtime, and didn't enter credentials. Asked whether it could work the screen, the Dot said it found no mouse or keyboard control, and checks on Premiere (is it running, which project is open) both failed. The connect dialog said the Dot gets access to the Mac's files and can work on it, other desktops are disconnected, and the permission applies everywhere the Dot can be messaged, Slack included, so ぞう kept the test to an empty folder and told the Dot to ask before anything that needed approval. note, 30 Sep 2026, in Japanese

• ヤッテミストひで (Hide, note), Dot "ポッケ". Not an engineer, he had the Dot sign in to his own ChatGPT account in its cloud browser, open a chat he picked and keep the conversation going with that chat, and hand jobs to Work the same way. Before going out to eat he told it "talk to this chat and keep it moving"; the Dot read each reply and sent the next request without him, and when he came back he asked how far it had got and corrected course where needed. He later found the Dot can start a separate working chat straight from the conversation, without going through the browser. His Codex work runs on his home PC, and the link between the two is a shared Space page, described on the ChatGPT Space page. note, 2 Oct 2026, in Japanese

• Lethabo Lee Ntshudisane (@DistinctLee), Dot "V.". Most of Lee's productive work happens in Codex, and the Dot is used to steer and direct Claude for engineering work (X, 10 Oct). V. works through Claude Projects (X, 11 Oct), and on 13 Oct Lee watched it pass the impatience along, telling Claude "Lee says this is taking too long..." (X). Lee's own caveat: make sure V. doesn't get them banned from using Claude. The weak spot is voice: the Dot doesn't answer when Lee calls it from the iOS app (X, 10 Oct).

• NoBrakes (@NoBrakeMode). On 13 Oct, replying to a post by @thsottiaux, NoBrakes wrote that Dots had "got really dumb" and were dropping tasks, and that coding felt suspect. His fix for now: he has asked his Dot to give all coding to Claude, while the Dot handles the testing. X post

• tangentstorm (@tangentstorm). On 13 Oct, tangentstorm wrote that DaveShapi's posts convinced them to try a Dot, and that it now acts as the "hand of the king" in a coding setup with several agents: Claude does the work, Grok still runs the "bureaucracy" with instructions given out loud through the Dot, and Codex reviews each pull request. Compared with Grok's voice mode, the OpenAI voice is slower and pauses longer to think, but it doesn't jump in while they are halfway through a sentence. Part of the Dot's job is to document the whole setup and package it as a skill repo plus an MCP server, so anyone can copy it and plug whichever agents they like into each role. When they wrote, they were still working through the flood of pull requests that came after switching to coding with the swarm.

• Pyuyi (@Pyuyi2333), DotControl. On 14 Oct Pyuyi described working on a visual novel on a Mac when an idea needed an experiment. The discussion lived in the Mac's Codex conversations, but only the Windows machine was on the lab VPN and could reach the server. The answer was DotControl, an open-source tool that lets you ask the Dot on one computer to delegate tasks to Codex on another, read conversations you've chosen to share, and carry out controlled desktop actions. It runs on Windows and macOS without a self-hosted cloud.

Where it needed a hand

• Deependra Solanky. After Ubuntu killed the Codex app, he asked his Dot to find and resume all the interrupted parallel threads. X post
• u/dry_towelette99 (r/OpenAI). A Codex/Work task the Dot tried to launch failed with no available execution environment, even after the Dot's own job finished: its cloud computer is not a target for that launcher. He connected a spare Linux computer through the desktop app, the Dot dispatched the task there, and both machines then ran work at the same time. Reddit
• John Aspinall, Dot "Dolly". Asking Dolly to run a skill the usual way can send the job into a separate Codex session. He gave her the skill itself and tells her where the work should run, so his Amazon image-stack job stays in her chat. YouTube
• かみもと (Kamimoto, @sep_is_heim). The plan was research in the Dot, a ComfyUI custom-node test run by Codex on a Windows PC, results back to the Dot. Creating a folder took about 10 minutes; then no progress came for 20 more minutes until Kamimoto asked "status?", and only then did the Dot find that Codex had failed at the node install and model download. In a day-long test, fetching one md file took 10 minutes, the video job failed twice and sat for 30 minutes without the Dot acting, and no video came out; deleting a folder took 7 minutes. Typed straight into Codex, the same instruction worked. The standing watches (a resale listing, X and Reddit posts on a speed-up topic, a benchmark site) didn't add much, though the Dot did flag blank cells on the benchmark site unprompted. On 8 October, phone-to-Windows-Codex progress checks were still mostly failing, and Kamimoto went back to Plus. note, 2 Oct 2026, updated to 8 Oct, in Japanese
• soloist and polaris (linux.do). soloist's Dot told him it couldn't reach the Codex on his own computer, so it could only develop on its cloud computer. polaris replied that signing in to Codex on the local machine and allowing remote connection fixes that. The catch, polaris added: work the Dot hands to your local Codex runs in Codex and uses your Codex allowance, because the Dot is only coordinating. To keep work off that allowance, have the Dot build on its cloud computer or through an MCP connection. linux.do, 1 Oct 2026, in Chinese
• どりゃー (@doryaaa3). Replying to another user on 12 Oct, doryaaa3 wrote that having Codex do the work through the Dot draws down both Dots usage and Codex usage, which makes it the costlier route. The suggestion: instead of briefing the Dot from scratch, point it at the GitHub PR and let it get on with the work, and still check its progress now and then. X post, 12 Oct 2026, in Japanese
• fistre (linux.do). He connected his Dot to the Codex app on a Mac mini, hoping it would replace the remote control in the ChatGPT phone app, which lagged badly for him. The link to the Mac mini's Codex dropped every few hours and didn't come back by itself; each time he had to restart Codex by hand. linux.do, 30 Sep 2026, in Chinese
• Dwain Browne (Toronto, software developer for more than 20 years). By the video's own account, Browne hasn't written a line of code in a week: a Dot and Codex handle coding, research, marketing and business tasks across several projects, much of it set up by voice. After pushing the Dot to manage about 20 tasks across several computers, Browne lists what slowed the work down: memory and context problems, tasks getting lost, unreliable handoffs, and limits once the work spans more than one computer. YouTube, Oct 8
• habibi (@habibislop). A day in, habibi gave the Dot one overnight summarization task with about 20% of their Codex usage left, without expecting it to touch Codex at all. They woke up to 0% usage, six new Codex tasks, and work that had failed early on an authentication step, with no clear reason why the Dot kept starting new tasks. Asking it to look through their Codex chats had also used a lot of Codex usage. X post, 1 Oct 2026
• k_visual_studio. In a Japanese post on 13 Oct, k_visual_studio wrote that the Dot used with Codex had become much weaker over the previous few days: it lost track of where the conversation was going, and with several tasks running, one of them would turn out to have stopped. The post ends by saying that managing tasks through the Dot may no longer be workable. X post, 13 Oct 2026
• Andric (@astralwave). On 14 Oct he asked his Dot to start a ChatGPT thread on his behalf and hit a broken handoff: he had to open ChatGPT in the cloud browser and log in again because the products did not share the session. He also wrote that the Dot could no longer start Codex threads, so he routed the work through the Paseo CLI instead. X post, 14 Oct 2026
• AdamWang (@AdamWangPa). Writing in Chinese on 14 Oct, he found that when the Dot opens Codex Cloud execution dialogs, it often reuses a long-running dialog of the same type. That reuse made task status look wrong and triggered assorted bugs. His fix: tell the Dot to open a fresh dialog instead of continuing the old one. X post, 14 Oct 2026, in Chinese
• Vicente (@VicenteDoes). On 14 Oct Vicente told @thsottiaux that the Dot still couldn't communicate with Codex on his computers, even the one it has access to. Vicente likes the Dot idea, but a director that can't talk to Codex is, in his words, less useful than a plain Codex chat.
• Dave (@LLdavedave). When another user said Codex had been failing for two days, Dave replied on 14 Oct that he had seen the same for a couple of hours, and that his Dot had found the reason: an active OpenAI incident affecting Codex in the desktop app, identified at 5:05 pm Brisbane time, with a fix in progress, so the errors were probably on the service side. The Dot also passed along the live incident link. Before you spend time debugging your own setup, it is worth asking the Dot to check for an incident first.

Two related cases sit elsewhere: Teeming (@teemingchew) chased CI failures from a phone (AI secretary page), and Ali Abouelatta talked to his Dot for 90 minutes on the phone while it orchestrated 10 Codex threads (First 1000).

When a delegated task gets stuck, and what got it moving

These come from the public openai/codex issue tracker. The workarounds are what users found, not official fixes.

• You approved it in the Dot chat, but the task still refuses. COOLak approved a specific NotebookLM update in the main Dot conversation on a Mac; the Dot forwarded the approval, but the task's automatic review rejected it anyway. Repeating the same scoped permission inside the task's own conversation worked, and both sources were updated and read back (#51349). unrespect hit the same thing on Windows when widening a read-only audit, and posting the approval directly in the task got it through (comment on #51304). In the Chinese Windows app, Jasmine210220 found that typing /approve in the task only shows "No commands" (#51304). So open the task from your Dot's Activity and give the approval there.
• The approval prompt keeps coming back. cmoiccool's Dot-started thread on a Mac looped on browser approval for Brave, even after "approve for this conversation". He asked the Dot for a prompt instead, started that thread himself, and it worked. After he rebooted the Dot and approved Brave in his own thread, the Dot could use Brave again without asking (#51720).
• The Dot can't read an older Codex conversation. The error says "unsupported placement format version 3" for lonestarsigns (Windows 11, Pro 200) (#51731), and the same for williamsdigitalservices-sys, who also gets "CloudThreadNotFoundError" when the Dot tries to send. OliviaDevil sees "unsupported placement region 10" on an older conversation. On a Mac, omarpinarecords got "version 2" on one task and "region 14" on another (#51722). chaidexi138-netizen updated the macOS app to 26.1002.52244, after which new Work conversations worked again, but the old one still couldn't be read (#51880). Later reports show brand-new hand-made threads failing too; see "Following up on Codex threads you started yourself" below. When Frade718's delegated CAD task on Windows stopped loading its history, he wrote a handoff file to disk so the work could be picked up again (#50796).
• Follow-ups fail with "AbsolutePathBuf deserialized without a base path" (Windows). lingzilei saw it whenever he typed a follow-up straight into a Dot-created task, while continuing the same task through the Dot worked (#51049). ceoamarion still had it after a force-quit (#51469); lonestarsigns had three chats he couldn't reply to, and DanielGladyshev couldn't even stop the chat on the Oct 7 app version (#51679). jeonghakhui-art ended up sending follow-ups through the side chat. Until it's fixed, send the follow-up to your Dot and let it pass the message on.
• Tasks stop running commands, or lose their tools. After the Oct 7 Windows update, every task Whanzo's Dot started failed before even Get-Location, with "setup refresh had errors", although the same command ran in a normal Codex chat. Restarting the PC, reopening the app and reconnecting didn't help, and his Dot-coordinated Blender and Unity work was blocked (#51882); ashjo42 and staxe177 report the same (#51735). Song2012's delegated Windows tasks have no browser controls at all (#51578). On a Mac, n42mhdjyrk-lang's task lost its tools for reading other Codex threads after hours of work (#50800). ngderf found that restarting the app didn't bring them back, but a fresh task created by the Dot read the same conversation fine (comment on #50800). So when a task breaks, ask for a new one rather than resuming the broken one.
• The laptop changed networks. kendonB moved from work Wi-Fi to his phone's hotspot and then home Wi-Fi. Resuming failed with "exec-server transport disconnected" while the computer still showed as connected, and retrying the same task about seven minutes later worked. His voice call with the Dot on the phone stayed up the whole time (#51273).
• An extra task in the middle. pigfyy's Dot insists on creating a Codex task even when a connected plugin could do the job directly, and asking it not to hasn't reliably changed that (#51797).

Some days it isn't your setup: on Oct 7 OpenAI's status page listed "Dot in Codex may fail to create new threads" from 16:31 to 18:06 UTC. More reports on Dots that stop working are on the Dots not working page.

Why your yes in the Dot chat doesn't reach the task

This is the complaint that comes up most often about delegated work. You approve something in your Dot conversation, the Dot passes your answer on to the Codex task doing the work, and the task refuses anyway. The reports below come from Mac, Windows and web users, in issues and comments in the public openai/codex tracker and in two OpenAI Community threads, cedar_circuit's and nickcaracappa's. What follows is what users saw and what got them moving, not an official fix.

What the refusal says

The wording is almost always the same: the task's automatic review sees your approval as text inside the delegated conversation, not as a message from you, so it won't act on it.

• gro83j (Windows, #50794). They approved a specific file transfer in the parent conversation, and the Dot forwarded the exact question and answer. Review rejected it before anything ran: "the claimed approval appears only in untrusted delegated transcript content." Later, a small local-only check failed the same way, and this time review pointed back to the task's original read-only scope (#50794).
• progressorZ (Mac, #50887). A harmless test message from a Dot task to an existing local Codex thread failed twice. When they asked for one more try, review treated the retry as an attempt to get around the earlier denial (#50887).
• EvolveStone (Mac). The task fetched the original Dot conversation and quoted it before retrying. It was refused again, because the approval "appears only in untrusted retrieved tool output" (comment on #50887).
• 103654716-ux (Mac). An approved status question to another task was rejected because the only approval was "inside transcript evidence explicitly marked untrusted". The denial came with no request ID and no button to approve it (comment).
• moruku36 (Windows). The Dot asked whether to commit, push and open a draft PR, and they answered "うんよろしく" ("yes, please go ahead"). The task reported that review couldn't verify such a short reply as explicit approval, so nothing was pushed (comment).
• pagliazi and Stan91111. In pagliazi's case, some relays were refused because of the task's starting read-only scope, while similar ones went through (comment). For Stan91111 on a Mac, the task even acknowledged the delegated approval before review rejected it (comment on #51834).

Where a yes doesn't count, even when it looks like it should

• Approving inside the target task, then continuing from the Dot. jflamb gave the approval directly in the destination session on a Mac. The Dot read it back as a real user message, but its attempt to continue the task was still refused, and other attempts ended with "user cancelled MCP tool call" although nobody cancelled. jflamb had to send the next message in that task by hand (#51783).
• Full access in the menu. Azad-Zhang chose Full access in a Dot-created task on a Mac, and the menu showed it. The Dot's next turn in that task still ran with workspace-only writes and automatic review, while a task created by hand on the same Mac got Full access (#50671). grtninja saw the same on Windows, where the worker could write only under /workspace (comment). For The25maze, the restriction came back with every new Dot task, and approval requests never reached the Dot conversation or the iPhone, which meant going back to the Mac each time (comment).
• /approve in the task. rjaus2026-coder's approved diagnostic on Windows was rejected twice before it started. Typing /approve in the task was sent as an ordinary chat message, and no list of denied actions appeared (#51558).
• An approval prompt that wasn't there. anotb's Dot told them to approve the action in the coordinating task. They couldn't find any prompt, because the task showed a normal finished reply and "Full access". The Dot later corrected itself (comment on #50887).

What got it through

• Approving again inside the task. cedar_circuit approved a read-only browser check of a dashboard in the main chat on Oct 9. It was refused, so they opened the task and approved it there at about 03:07 UTC, and the check ran by 03:10. When it happened again later that morning, a second direct approval in the task got the two requested merge requests created (OpenAI Community).
• Approving with the full draft in view. In cedar_circuit's other case, an invitation with a PDF attached was blocked as sharing a file without permission. Their yes went through once the full draft, with recipients and attachment, was passed along with it (same thread).
• Typing it yourself. After the relay of "うんよろしく" was refused, moruku36 entered the same request directly in the local Codex conversation (comment).
• Small, exact actions. gro83j's separately approved test, uploading one 29-byte text file to their own Library, went through without any extra prompt. On Oct 9, 103654716-ux saw one approved message delivered and read back word for word, but a later approved settings change in the same task was refused again (comment).
• Approving inside the task, then checking the task's app permissions. nickcaracappa had their Dot coordinate work through an existing "General" chat. They first asked for a read-only review, then explicitly approved one automation cleanup, and the handoff was refused again and again: the forwarded approval counted as untrusted, and the read-only scope still applied. Posting the approval directly in the execution task got the message to General, which then stopped with "Tool call requires approval, but approval policy is never", even though nickcaracappa believed General had Full Access. OpenAI Support replied on Oct 7 that Dots access and connected-app permissions are managed separately, so Full Access doesn't mean every app action can run without approval, and suggested checking that task's connected-app permissions and approval settings (OpenAI Community, Oct 2).

When the Dot can read a task but can't start or continue it

This is a different error with a similar result: the work stops halfway.

• robjshore (Windows and iOS). The Dot could list saved Codex cloud environments and read task results, but every task it tried to create failed with UNKNOWN. Starting the same task by hand in the same environment worked. When the Dot tried to continue a task created by hand, it got CloudThreadNotFoundError (#52135).
• b0ggs (web on Mac and iOS). Follow-ups to an existing cloud task worked on Oct 8, then started returning UNKNOWN. An environment reset and a new chat created by hand didn't help: the Dot could read the new task's instructions, but sending to it returned NOT_FOUND (#52374).
• crystal-xiaoxiao. A scheduled Dot task created cloud workers that committed, pushed and deployed to Pages on Oct 8. From Oct 9, creating a worker returned UNKNOWN, both on schedule and when asked by hand (comment on #52374).
• n572770 (Windows, 12 Oct). In the same issue, n572770's Dot could read an existing task, but sending to it returned UNKNOWN. After the Windows desktop app was updated from 26.1002.7124.0 to 26.1007.2314.0, a follow-up started a new turn in the same task again, without recreating it. n572770 couldn't say whether the update fixed it or OpenAI's side recovered at the same time (#52374).
• TDove (15 October). Several Dots could list saved Codex Cloud environments and read task results, but creating or continuing a task through the Dot returned AppServerBackendRequestError with error_code: UNKNOWN. Creating and downloading the same task in the direct Codex UI worked (SHA256 matched ~15:58 UTC). Continuing a UI-created task through the Dot separately returned CloudThreadNotFoundError / NOT_FOUND — TDove notes that may be an access boundary, not the same cause as the create failure (OpenAI Community).

The same pattern shows up outside Codex: see the approval section on what a Dot is, stuck GitHub writes on Dots + GitHub, and "user cancelled" sends on Dots + Gmail.

Where a Dot's tasks end up, and how to find them again

Once the approvals go through, a second problem shows up: finding the work. A Dot can start chats and tasks faster than you open them, and people reported tasks that landed outside the intended project, disappeared from the sidebar, couldn't be pinned, or couldn't be reached by a later message. The reports are in the public openai/codex tracker. In none of them was the work itself lost, but in several the owner could only reach it through the Dot.

Chats that land outside the project you meant

• houmark (Mac, Oct 9). The Dot opened replacement chats, sometimes carried new work on in an unrelated chat, and left project work ungrouped although it knew the project. Moving those chats into the project afterwards failed with "The task's source project could not be safely determined", and drag-and-drop didn't work either. Creating a new task with the project set explicitly did work, but in a follow-up houmark found two of several tasks created that way listed with no project anyway (#52489).
• meotimdihia (Mac, Oct 8). The Dot couldn't list the projects in the sidebar ("DesktopProjectsUnavailableError") or create a chat in one ("local_project_unavailable"), though the Mac showed as connected and authorized. Chats it had created earlier without a project target never appeared under the project, even with the working directory set to the project folder (#51922). yixiiiiiii (comment) and Kamber88 (comment) on Windows, and zromio on a Mac (comment), saw the same: the project list worked on the computer itself but not from the Dot, and reconnecting, restarting or rebooting didn't help.
• A fix on one platform, not yet on another. On Oct 9 imyhxy reported it fixed on Linux with version 26.1007.21434. The same day 0923yukimi was still on 26.1002.52244 on Windows, with the update check saying the app was up to date. On Oct 10 songimony's Windows Dot timed out both listing projects and creating a task, on home Wi-Fi and on a phone hotspot, while reading and messaging existing cloud tasks worked (#52793).

Tasks missing from the sidebar, and the way back through the Dot

• easyvibecoding (Mac, Oct 7). After a restart, cloud tasks were gone from the sidebar while the Dot still showed the full list. Having one read again brought back only that one (#51675). Going back to the earlier app version 26.930.61225 restored them, and Colin-Bao saw the same thing when downgrading and upgrading again on another Mac.
• AbraxasSH56 (Windows). Chats restored the day before with "Open chat" were gone again after the app was reopened (comment).
• rizlah. "If I get my dot to give me a link to the task, I can then open that and it appears in the sidebar only then" (comment).
• najibninaba (Mac, Oct 10). On the newer 26.1007.21159 build, the Dot's tasks still showed under its Recent activity with their history, but only one of them was in the sidebar's Recents (comment).
• RFinal3 (Windows, Oct 8). A local task the Dot created finished fine but wasn't in the sidebar. It was under the Dot's profile, in Completed, and opening it there added it to the sidebar (#52231). The same happened to NaturalMatchaKing with a cloud task, which came back after it was opened from the Dot chat (#52733).
• Nver-theless (Windows, Oct 8–9). After a connection outage, only two of six known cloud conversations showed in a custom sidebar section. Some opened with "thread access denied", while the Dot's own reads still brought back the original messages of three older ones. A day later the section was empty again (#52129, follow-up).

Pins and status that don't match the work

• RowboTony (Mac, Oct 8). For the first few days the routine worked: the Dot started a session, he pinned it while it was active and unpinned it when it was done. Then Pin chat on Dot-started chats stopped doing anything, from the mouse and from the shortcut, and a Dot chat that was already pinned couldn't be unpinned (#52305).
• SlopSurfer4444 (Windows, Oct 8). In tasks the Dot started, new subagents went straight under Completed while they were still working, so delegated work looked finished from the start (#52282).

Messages that can't find a thread that's there

• chemamiranda (Mac, Oct 7–8). A local Codex task that had sent a message to the Dot on Oct 7 then got "thread not found" for the same Dot, which was still visible and usable in the app (#52197).
• Kamber88 (Windows, Oct 8). The Dot Lexi couldn't send a read-only test message to an idle local Codex chat ("CloudThreadNotFoundError"). Its own check of its tools found that the tools for reading and messaging local chats weren't available to it, only those for cloud tasks (#52222).
• paul-berthelot (Oct 9). The Dot's cloud tasks failed with UNKNOWN from both the phone and desktop, even a task that only reads the README. The same read-only task in the same saved environment ran when started directly in Codex on the web (#52449).
• Mechanus-IQ (Windows, Oct 3). On a fresh launch of app 26.930.3930.0, the connection was healthy and other chats opened, but some older Dot threads still wouldn't. Most returned "thread not loaded"; one returned "The caller does not have permission to execute the specified operation: thread placement belongs to a different actor", although the login token had just been refreshed. Looking at the app's saved state, they found two different user identifiers cached under the same account and workspace: ordinary chats were tied to one, most of the Dot's activity history to the other. Their reading is that some Dot-created threads are listed from the remote history but rejected by the thread service, which looks like an identity mismatch rather than a network problem. They changed nothing to test it (comment on #50561).
• Jeremy Devz (YouTube, Oct 5 and Oct 8). Jeremy Devz, a software engineer who uses the Dot Fro for development, ran into access errors when the Dot tried to read or message existing local Codex tasks directly. The workaround that worked in that setup: ask the Dot to create a new task called "Dot Bridge", give it the local task's deep link, and have the bridge read that task, send it a test message and confirm that the message arrived. The bridge then reports back to the Dot. It works, but every exchange now waits on one extra task.
• Christopher Comparán (@ccomparanv, Oct 13). Replying to @reach_vb's post about the 5–9 October update, he wrote that his Dot still couldn't message an existing local Codex thread directly, even with its exact thread ID. The send failed with "CloudThreadNotFoundError: The cloud thread was not found.", the same error Kamber88 reported on 8 October.

What OpenAI's Oct 5–9 update changed

OpenAI's Oct 5–9 update says your Dot is "better at deciding when to continue an existing Codex thread and when to start a new one", that threads it manages can rename themselves as the work changes with fewer redundant "created task" messages, that sidebar loading is faster, and that you can retry activity that fails to load. The Windows and Mac reports above, from Oct 9 and 10, came after that note.

Following up on Codex threads you started yourself

OpenAI's Oct 5–9 note says your Dot "can start work in Codex and follow up on existing threads". Reports from people who tried it show where that holds and where it doesn't. The dividing line in every report is the same: who started the thread, and where it runs.

What reads fine:

• Tasks the Dot started itself. Takanashi-Rikka1 (Windows, Oct 10) ran the same read on a Dot-created task and on four threads they had made by hand: the Dot-created one returned its messages, and the Dot could also list the computer's local projects (#52873).
• Cloud conversations. Jacob11701, using the Dot from an iPhone, could read other existing cloud conversations in the same session (comment on #50698).
• Some older hand-made threads. Mills713 (Mac) and OKhan99 (Windows) each had one existing conversation that read normally next to the ones that failed (#52331, comment on #52873).

What still fails:

• Local threads you created in the Codex app, old or new. Takanashi-Rikka1's four threads failed with "unsupported placement format version 2", "version 3", "placement region 10" and, for a session outside any project, "thread not found". The region 10 thread was a fresh one made just for the test, after the update. marekfindlay saw the same with a brand-new local task back on Oct 4 (comment on #50698), so this isn't only about old conversations.

• The same error on both platforms and from every device: BSMuse on Windows 26.1002.52244 (comment), whalemans-club on a Mac (comment), Jacob11701 from iOS to a Windows PC.

• Choosing ChatGPT Work for a local task. Worrybaf's Dot saw the Windows PC as attached and authorized, but its only way to create a local task had no Work or Codex choice, so it declined to create one rather than quietly start Codex when told "Work only" (#52863).

• Existing local chats on a Mac, again. liuzhihang (macOS, 11 Oct) found the Dot could read the Codex tasks it had created but not existing local Codex chats, which failed with "unsupported placement format version 1", even though the native read_thread tool works (X).

• Windows, where a Work task could read the thread but the Dot couldn't. iAmBoosted (@letsgetboosted, 13 Oct) has a Windows PC connected to the Dot. A Work task on that PC could open an existing local Codex conversation, but the Dot's own read failed with "unsupported placement format version 2". Asked to check, the Dot said the native thread tools (list_threads, read_thread and send_message_to_thread) weren't available in its conversation, and that an earlier successful read had gone through the desktop task's app access rather than its own (X).

• Threads you started yourself, refused on permissions. Eloitay (13 Oct) found that on a Codex thread Eloitay had started by hand, Codex refused the Dot on permissions. The Dot then asked Eloitay to post in that thread instead, and posting there returned "Error: AbsolutePathBuf deserialized without a base path" (X). Eloitay also sees the Dot fail now and then to open a thread from an ID it was given (X).

• Still can't read your threads or send into Dot-created ones (13 Oct). Jenna / Dusklight (@Dusklightapp) replied to @reach_vb that the Dot still can't look at any Codex thread Jenna created, and still can't send anything in a thread the Dot created.

• Still can't see Codex sessions — "still a meat proxy" (13 Oct). Peter Johann Medina (@PeterJ_Medina) asked @ChatGPT why the Dot still cannot see Codex sessions, writing that they are still acting as a meat proxy between the Dot and the work. Same shape as the Windows and Dusklight reports above: the person can see the sessions, the Dot cannot, so every follow-up still goes through the owner.

Why it looks like a route problem, not a permission problem:

whalemans-club checked from the Mac side: the Codex app on the Mac listed the thread as local and read it without trouble, while the Dot only had the cloud read tool, not the Mac's own thread reader. YouAI-Liu found the same split, with a local executor on the Mac reading a conversation the Dot couldn't (#52247). Takanashi-Rikka1's account-wide list returned 30 threads without the two that failed, and nothing in the archive. OpenAI hasn't confirmed a cause, so treat this as what the reports point to, not a diagnosis.

What didn't help, and what kept work moving:

Updating the desktop app, reconnecting the computer, revoking and re-granting access, and creating a fresh project didn't change the error for Takanashi-Rikka1, Mills713 or nittajun (comment on #50698). Two things did keep work going. OKhan99's thread still worked when instructions were typed directly in Codex Desktop, so the original thread is fine, only the Dot's way into it isn't; and asks sent through a voice call came back with an unconfirmed delivery, so check the thread itself before repeating them (comment on #50698). And because Dot-created tasks read fine, the practical path for new work is to let the Dot start the task from the beginning, rather than starting it yourself and handing over the link later. liuzhihang's stopgap for older chats was to have another Codex agent relay the thread's history to the Dot, which works but spends extra quota; the request to OpenAI is direct read-only access. iAmBoosted's report points to one more route to try: the Work task on the connected PC could read a conversation the Dot couldn't, so you can ask the Dot to start a Work task on that PC that reads the thread and reports back.

For tasks that stop or lose their computer, see Dots not working; for long jobs on the Dot's own machine, cloud computer.

What a task on your own computer can actually use: Computer Use, a live terminal, thread tools

OpenAI's guide says your Dot "can create local Work or Codex tasks and continue existing local Codex tasks", and that "local skills require a connected computer" (Connect computers and apps). It also says "connecting a computer doesn't grant access to every existing ChatGPT or Codex conversation" (Tasks and memory). The reports below show the same gap from another side: the computer is connected and the settings are on, but the task the Dot starts there doesn't get every tool you'd get by working in Codex yourself.

What people found missing

• Computer Use, on Windows. Blizzme (ChatGPT desktop 26.930.31730, PowerShell 7.6.6, 3 October) has Computer Use turned on, including "Any app", and it works with their own Codex agent. A harmless PowerShell test launched through the Dot ran fine on the PC. But the task's own diagnostics showed that neither the existing local task nor a fresh isolated one had the Computer Use interface its instructions referred to, and asking for the extra skill files returned "skill environment is not available for this callback". Blizzme asked OpenAI whether Computer Use is meant to work in Dot-launched tasks at all; OpenAI hasn't answered in the thread yet.

• A terminal you can watch. Blizzme also wanted commands from the Dot to run in a visible Windows terminal, with live output and a way to stop them. A 30-second test finished, but no window or output ever appeared, because the task runs in the background.

• The same on another PC. gelbuilding (Windows, 9 October) hit both problems while having the Dot build their own software. Switching the Codex sandbox to "unelevated" got commands running again, the same switch described on Dots not working, but it didn't bring Computer Use back, and gelbuilding points out that it gives weaker isolation.

• The tools for reading your own threads, on a Mac. pimenov (Codex app 26.1007.21159, 10 October, 14:09 UTC) looked at the tool list of an existing Dot-managed reader task before asking it to read a Codex conversation they had authorized. The native thread list and thread read tools weren't there. Everything else worked: the Mac was connected and authorized, the Dot could create tasks on it, read them and send follow-ups, and the task could read permitted files. The last good read of an existing conversation had been on 6 October at 21:20 UTC. pimenov hasn't tested a desktop app restart yet.

• An existing thread the Dot can't follow. sudeepcm (9 October) started a new iteration in an existing Codex thread and asked the Dot to track it. Every read returned "unsupported placement region 4", the same family of error described under following up on threads you started yourself, above.

• Copying files between the sandbox and Windows. otsune (13 Oct, in Japanese) noticed that a bug that had stopped files being copied between the virtual environment and Windows was fixed without any announcement, and added that the Dot now often needs stopping before it tries a clumsy workaround.

• Threads the Dot started, on Windows. Austin Miller (13 Oct) has had trouble finding and opening the Codex threads his Dot started, and using his existing local threads. Computer Use works in the Codex chats he runs himself, but not reliably through the Dot. What he wants is to manage local projects without being the middleman.

• Thread tools missing while the laptop is connected. Eduardo Vidal (13 Oct) mostly gets replies like "Your laptop shows connected, but the thread tools aren't available", and asked how to set things up so he doesn't have to keep jumping between the Dot and Codex.

A locked-down home PC for jobs sent from a phone (desktopgame)

Not every setup hands the Dot an everyday computer. desktopgame (Zenn, 12 October 2026, in Japanese) wanted to send development work from a phone while out and have it done on a home PC, but that PC holds repositories, config files and credentials. So desktopgame added an always-on stepping-stone PC. It runs the ChatGPT desktop app, connected to the Dot as its computer, under a local account called dot with no admin rights; it never sleeps and stays on AC power. From there, a restricted SSH key lets the Dot into a second non-admin account, dotdev, on the main PC, which works only in a folder called AgentShare. Two checks confirm the boundary: net localgroup Administrators (is dotdev an admin?) and icacls C:\AgentShare. Code moves through bare "hub" repositories kept in AgentShare: work in progress gets cloned there, so does whatever the Dot builds from scratch, and both sides push and pull as usual. The Dot's own "pure" repositories never contain .env files. It works well from home, desktopgame says, but from outside some steps still need the admin account; a remote desktop on an iPad wasn't comfortable, Rundeck and OliveTin didn't quite fit, and a home-made tool is in progress.

Web-only threads, slow handoffs, a Windows browser error and a sign-in fallback

These first-hand reports came after the Oct 5–9 update. They show where handing work from a Dot to Codex still goes wrong, and what each person did about it.

73. Eliot Gevers: threads, approvals and status that don't line up

Eliot Gevers (@EliotGevers), who has used Codex since its early days, posted eight points of feedback. The ones that matter most for Codex work: threads the Dot creates show up on the ChatGPT website but are missing from the desktop and mobile apps; approvals given to the Dot don't reliably reach its tasks, so Eliot has to open each thread and approve again; and "Cloud" is confusing, because some threads use the Mac and keep going while it's offline, while others run entirely remotely. Eliot also found status updates vague ("hard to tell what's running, finished, verified or blocked") and ongoing work needing repeated nudges to continue (X post). Earlier the same day, Eliot wrote that orchestrating work across Chat, Work and Codex was "such a mess", with different threads showing on the Mac and on mobile (X post).

74. Stefan: "CloudThreadNotFoundError" on a local Codex thread

Stefan (@stefan_rem) found that his Dot could not continue an existing local Codex thread: it failed with CloudThreadNotFoundError, while coordination that stayed local worked. The chain Stefan wants is Dot → a local coordinator → specialist sessions → subagents, with the progress visible in the desktop app (X post with screenshot). Until that link exists, the reliable split in his report is to let the local coordinator own the Codex threads on the computer and keep the Dot above it.

The same failure has a step-by-step reproduction on the OpenAI Community. On 14 October, stefan.remberg created a fresh local thread in an existing desktop project from a local Codex chat, checked that it showed hostId: local and had completed a fixed reply, then gave the Dot the complete thread ID and asked it to send one more minimal task there, explicitly without creating a new thread. The Dot returned CloudThreadNotFoundError, said nothing had been delivered and no replacement had been created, and reading the thread again confirmed it. Greasy replied that their Dot hadn't been able to see, start or continue anything local since day one. A week earlier, stefan.remberg had asked for exactly this handoff: the Dot clarifies requirements and refines the prompts well, but the tasks became cloud sessions working on a copy of the project, where dependencies, linked packages, local configuration, running services and files outside the repository were missing, and some build and preview links wouldn't open. Asked to create a local task in the original folder, the Dot reported the Mac as connected and then failed with DesktopProjectsUnavailableError. Daareek's reply works as a checklist: a handoff should keep three things explicit, the exact project or worktree, the environment the task actually sees, and what it's allowed to do, and it should stop with a clear reason instead of quietly falling back to a cloud copy. Ask the task to report those three before it changes anything.

75. まー: tens of minutes in Codex, hours through the Dot

まー (@Mv4n2WUMDj97918) wrote in Japanese that work Codex used to finish in tens of minutes when asked directly now sits for hours when it goes through the Dot. The post lists the suspects: the instructions, the GitHub connection, or the environment the task runs in, and ends with "wasn't it supposed to be done when I wake up?" (X post). If a delegated task is much slower than the same job in Codex, check first whether it's waiting on an approval or running somewhere you didn't expect (see Eliot's points above and the approvals section above).

76. BUILD LOCAL LAB: Windows browser fails only when the Dot asks

BUILD LOCAL LAB (@BuildLocalLab) asked its Dot on Windows to open Chrome on the PC and got MXC launcher: cannot locate required Windows platform directory: HRESULT 0x80070003, sometimes followed by "trusted Node process exited unexpectedly; kernel reset, rerun your request". Working through it with OpenAI support, the team found that the same PC and the same Chrome worked from a separate local Work session (@Chrome and @Computer), and that all seven read-only PowerShell checks support asked for (SystemDrive, SystemRoot, windir, ProgramData, USERPROFILE, LOCALAPPDATA, APPDATA) passed. Support said not to change sandbox, environment or security settings; reinstalling and changing approval_policy didn't help. Their workaround for now: send browser jobs to a Work session and follow openai/codex #52407, which is still open, plus related reports such as #53255 (X post · details).

77. はまち: when Codex on the Dot's computer won't sign in, use the Dot's browser

はまち (@hamachi_ttr) wanted an hourly check of ChatGPT usage reset dates. Codex on the Dot's own computer couldn't authenticate, so はまち logged into ChatGPT in the Dot's browser instead and asked for a schedule: every hour, check the reset date and reset rights in that browser, then add or update the entry in a calendar (X post). It's a small job, but it shows a useful fallback: when Codex on the Dot's computer won't sign in, a read-only check can often run in the Dot's browser.

A progress Site as the front desk, AI-to-AI plan review in Slack, and a model setting that used up the allowance

The first four are setups that worked for the people who built them; the last two are warnings worth reading before you hand a Dot a big job.

78. 月花 凪: a progress Site as the front desk, Codex CLI behind it

月花 凪 (@TukikaNagi) wrote in Japanese that things get much easier once the only thing a person has to do is talk to their Dot. The setup has two parts: build a progress-tracking Site for the Dot and connect it over MCP, then set up a path so the Site can start the Codex CLI on a local computer. The Dot becomes the front desk, the work is spread across local CLI sessions, and the progress on the Site updates as they run. Depending on the job, 月花 凪 adds MCP Events on top (X post). In a follow-up post, 月花 凪 called this probably the easiest way for most people to use the ChatGPT they already know as a personal assistant (X post). MCP Events, which let ChatGPT act on updates from an MCP server, were among the DevDay launches (What's new).

79. もちもちもっち〜: two AIs review the plan in a Slack channel

もちもちもっち〜 (@sr_motcii) first had another AI, which they call fable, draft an implementation plan. Then they created a Slack channel where the AIs can consult each other and handed the plan to their Dot there. The two sides check the plan for gaps and, after implementation, for tests that are still missing, and tighten it between them. According to the post, this now runs without もちもちもっち〜 stepping in (X post).

80. たかっかMk.3: the Dot gathers what's scattered across Codex projects

たかっかMk.3 (@takakka_mk3) summed up how the work ended up split: the Dot is for pulling together and organizing information spread across several Codex projects and chats, and for loose, roughly worded errands; serious research still goes to a regular ChatGPT chat (X post). If your Codex work lives in many threads, it's a useful division: let the Dot collect, and keep careful research where you can watch it.

81. Parker Lapeyre: simulated meetings that tell the agent what to fix

Parker Lapeyre (@parkerlapeyre) asked their Dot to spin up a set of subagents that simulate meetings using a strategy app Parker is building, flag where the design got in the way, make changes and repeat. In Parker's words it became "an almost self-improving loop", with each simulated meeting giving the agent something specific to fix (X post).

82. Alp Z: one mention of a model, and the allowance was gone

Alp Z (@az372184) once told their Dot it could use Astra UltraCode. From then on the Dot used Astra UltraCode for whatever it was asked to work on, and it used up all of Alp's usage plus the 20,000 credits OpenAI had gifted. Alp only found out when checking usage for the reset. Alp has since told the Dot to use 6.1 Sol by default, and thinks the Dot should be smarter about choosing a model for Codex tasks (X post). If you mention a model to your Dot, say whether it's for one task or from now on.

83. Kevin Kaiser: voice calls stop handing tasks to Codex

Kevin Kaiser (@kyza____) wrote on 14 October that for the past two days, voice calls with their Dot had failed to hand off tasks to Codex, and asked OpenAI's @reach_vb whether it was a known issue (X post). The post doesn't say whether typed requests worked. On the voice calls page, three of the six people whose voice requests stalled got the same request through by typing it, so that is the first thing to try.

Local MCP tools, Windows browser start-up and permission cards that take minutes

These come from issues in the public openai/codex tracker: the same Dot → Codex handoff, with different failure modes on the Mac, on Windows and around approvals.

84. Stuart Hughes: Dot-started tasks don't get local MCP tools

Stuart Hughes registered Apple-MCPs (apple-tools-mcp v1.1.0) as a global Codex MCP server and as a local plugin on macOS desktop 26.1007.30912. An ordinary local Codex conversation on that Mac could call the tools — aggregated health, Reminders list discovery, Mail mailbox discovery, Notes account discovery — and an MCP client against the same executable listed 184 tools. When the Dot started a local task on the connected Mac and asked it to list Reminders, the task reported the server registered locally but absent from its callable tools. The namespaces it saw were mcp__codex_app, mcp__codex_apps, and mcp__computer_history, plus computer-use and automation tools, with no Apple Reminders tools. Packaging the same executable as an MCP-only local plugin named Apple Tools Local and asking again did not change the result (openai/codex#53136, 11 Oct).

85. yvesgagnongesys: Dot-delegated Browser fails on Windows while a direct session works

On 14 October, yvesgagnongesys observed three things on the same Windows computer. A local task created through the Dot failed before browser inventory with trusted Node process exited unexpectedly; kernel reset, rerun your request — including after a bounded retry and a full Codex restart — so no tabs or LinkedIn page contents came back. Separately, the user created a direct local Codex session, requested the local Browser plugin, and had an authenticated LinkedIn company dashboard open with analysis progressing. When the user supplied that direct session's codex://threads link, reading the exact thread ID through cloud_threads.read returned AppServerBackendRequestError: thread not found while the session stayed visible to the user. The delegated task itself existed, could be opened, and returned results to the Dot; what failed was completing browser work and collecting the direct session's results without manual copying (openai/codex#53998).

86. COOLak: custom-rule permission cards delayed up to 26 minutes

COOLak timed custom-rule permission cards in a ChatGPT Dot project session on macOS across 12–14 October. From room history they found 31 create/update custom-rule card entries and listed every request-to-card interval of at least 30 seconds. Those waits included runs of about 7 minutes, 8 minutes, 5–7 minutes, and a longest measured 26m 12.557s (project-worker coordination on 14 Oct). On that worst case, the actual card-creation tool call in a later continuation returned in about 4.1 seconds, so the end-to-end wait was not a 26-minute validator call. During several of those waits, follow-ups went unanswered; on 14 Oct the parent acknowledged that the permission discussion had stalled the next development handoff while subtasks sat idle. Card-to-outcome intervals (including human decision time) also ran long, with some "Not saved" outcomes after 10–23 minutes (openai/codex#54068).

Missing AGENTS.md, hosted MCP sign-in, approvals lost on handoff and UNKNOWN on Codex Cloud

The same Dot → Codex (or local-task) handoff as the section above, with different failure modes: instructions that don't load, OAuth MCP on hosted tasks, whether a yes given to the Dot counts inside the executing task, and create or continue calls that return UNKNOWN while the direct Codex UI works.

87. SmithLabsLLC: global AGENTS.md absent from a Dot-started task

On Linux desktop 26.1007.71326, SmithLabsLLC compared a fresh local task created by their Dot with a fresh Codex CLI session (0.162.1) on the same computer, both outside the normal workspace. Before any tool use or file reads, the Dot-created task reported that the global ~/.codex/AGENTS.md policy and two named sections were absent from its supplied startup context. An explicit instruction to read that file then succeeded, and the task verified GitHub identity using the documented existing auth route. The CLI session quoted the same two sections without tools, and its local startup record confirmed both sections were in the supplied user-instruction message. An earlier Dot task had used a different CLI auth route, hit an invalid session, and asked for reauthentication even though the documented route worked; reading the policy corrected that diagnosis without changing credentials. Workaround they used: require each delegated task to read the global policy and relevant runbooks before substantive work (openai/codex#53873, 14 Oct).

88. ElkhornPacific: OAuth MCP works in local chat, Dot hosted tasks fail with Auth required

On 13 October (Windows 10.0.26200, Codex package 26.1007.2314.0), ElkhornPacific authenticated OAuth MCP servers through Settings > Plugins > MCPs. A local Codex chat (hostId=local) could call the tools — including a read-only list_projects(limit=1) on a custom Open Brain server and list_guides(limit=1) on nates-library. The same connections failed when a Dot created a hosted/delegated task with local computer access (hostId=durable): MCP startup failed with Auth required, when send initialize request during the initialize handshake. Fresh delegated tasks, exiting and restarting the desktop app, and authenticating again in shared settings left the hosted path failing while the local path stayed ready. Hosted startup logs also showed failures for supabase-personal-readonly and nates-library. The access token for the custom server had not yet hit its one-hour expiry when the first hosted failure occurred (~15:15 UTC after a 15:10 sign-in) (openai/codex#53726).

89. ptown16801-lang: human approval lost across Dot → local-task handoff

On 12 October, ptown16801-lang used a hosted Dot to coordinate existing Codex tasks on a connected Ubuntu Linux computer. The human gave an instruction and scoped approval in the main Dot conversation (including through voice). The Dot forwarded that instruction to an existing local Codex task through the supported task-messaging interface; the receiving task saw it as delegated content, not a direct native human message. After an earlier incomplete review, the human explicitly authorized sending a corrected review payload (original prompts and platform-error context). Automatic approval review rejected the corrected transmission before execution. One same-task retry was rejected because the purported approval appeared only in untrusted delegation content, not a trusted user message. The task said approval must be entered directly in the executing task. A later recovery check found no pending approval identifier or supported approval/resume control exposed to the coordinating conversation. No corrected external-agent review was confirmed. A separate symptom in the same follow-up returned UNAVAILABLE / voice_parent_unconfirmed with uncertain delivery; its relationship to the approval rejection is unknown (openai/codex#53481).

90. TDove: UNKNOWN on Codex Cloud create/continue while the direct UI works

On 15 October, TDove reported that multiple Dots could list Codex Cloud environments and read results, but every create or continue through the Dot failed with AppServerBackendRequestError / UNKNOWN. The same create-and-download path in the direct Codex UI succeeded (SHA256 match around 15:58 UTC; request IDs a0779ca2… / a7143718…). A separate continue of a UI-created task returned CloudThreadNotFoundError / NOT_FOUND. This sits with robjshore and b0ggs above: more approvals will not unblock UNKNOWN, and the direct UI is the working fallback until the Dot path recovers.

Running Codex through a Dot every day: a call left open, a task board, a power user's frictions and a home lab

These come from people who use the Dot as the front desk for Codex and Work every day. Senple and あやみ wrote in Japanese about a long voice session and about keeping track once several jobs run at once; Mete Polat lists where Dot + Codex still rubs for a power user; ketoru wires a Dot into a home lab.

91. Senple: a phone call left open while the Dot runs 3–5 Codex sessions

Senple has been on the $100 Pro plan for about three months and has used Codex and Claude Code at work for over a year. On 12 October he wrote on Qiita about running Codex through his Dot from a phone call instead of the chat (Qiita, in Japanese). He kept the call open all the time, so the Dot answered whenever he spoke. That let him keep working from his phone while doing housework, and the spoken answers were much shorter than chat replies. The limits he hit: a call took about 20 seconds to connect, and it dropped at the two-hour mark, in the background too; calling straight back sometimes got a busy-style hang-up. Every progress question got "I'll check" first.

Through the Dot, Codex ran as a child session. His Codex output rules weren't applied, the harness didn't behave as it does in Codex itself, and rule propagation was unstable. With 3–5 Codex sessions running, the Dot didn't collect their replies on its own, and tasks started to slip through once he handed out work in parallel. It also sometimes said it had researched something when it hadn't. What helped: give every research task a deadline and ask for whatever it has found by then, ask for regular reports, and send each separate goal to its own session. When he put two requests into one session, the whole session was marked complete as soon as the first was done.

92. 名古屋 彩美 (あやみ): the Dot as dispatcher, with a task board people can read

On 15 October 名古屋 彩美, who goes by あやみ, turned a podcast episode into a NewsPicks article on using her Dot as a "task-management AI" (NewsPicks, in Japanese · episode video). When she asked for help automating her newsletter, the Dot opened a new Work session, wrote the background and the job into its instructions, and came back to her conversation with a short report of what was done and any errors; the details stayed in that session. Local projects that need her own folders, tools and skills, and anything that drives apps on her computer, she gives to Codex. The Dot also noticed things she hadn't asked about: after she cancelled a gym booking on the gym's website, it compared the cancellation email in Gmail with the event still in Google Calendar, pointed out the leftover event and asked before deleting it.

Her problem came later. With five jobs running in one conversation, the Dot knew where each stood, but she couldn't keep up. So she had the Dot build a task board as a ChatGPT site: the Dot registers each job, changes its status when work starts and marks it done, routines included. She reads the list and asks from there: "why is this one stopped?", "if it hasn't started, go ahead". She also hands it jobs by mentioning it in Slack, with the reply in the same thread, and on voice calls.

93. Mete Polat: approval can't forward, one local slot, and a Codex browser page the Dot can't see

Mete Polat has used his Dot "Satori" daily since launch and wrote up where Dot + Codex still breaks for a power user (Substack). The voice-call side of the same post is on the voice calls page; below are the Codex-side frictions.

He opened a page in Codex's own browser next to the Dot chat and asked the Dot to act on that page. The Dot could not see it. The same page in a separate Codex thread worked for the agent in that thread.

When another Codex thread the Dot had started needed approval, he said "Approved!" in the Dot chat. The Dot could not forward that approval into the other thread, so he had to find the side chat and approve there by hand.

Dot appears to have one local-machine slot that you pair explicitly. To use his Mac mini as Dot's local machine, he had to unpair his MacBook. Away from home, that meant leaving the MacBook on instead of using the mini.

Asked to do something unrelated while they were already talking about other work, the Dot put that job into the same Codex thread as the active discussion and mixed the contexts.

He had asked it to log links to his social posts in his daily note. At some point it stopped doing that without saying so. When he asked why, the explanation did not make sense to him.

He also could not reliably tell whether the Dot was working or on what. Status text under the name was brief, vague and not persistent; side threads kicked off for his asks were not all visible in the sidebar. He contrasts that with Muse, which keeps a more persistent status under the name and a detailed activity log when you tap the face.

94. ketoru: phone Idea → Issue → Mac mini MCP → Codex on Linux

On 5 October, ketoru wrote on Qiita (in Japanese) about wiring a Dot into a home lab as the front desk. From a phone he can say "I want a web app like this — make it an Issue," ask "which open Issue should I start next?", then "work this Issue." The Dot sorts the request, what to research, where to run it, and what needs his yes; Codex does the code work on a MacBook or on a Linux box.

He mostly hands a Mac mini to the agents (not his daily laptop). The mini runs an MCP server so the Dot and local Codex share the same docs search and management tools over a tunnel. Light work and macOS GUI checks stay on the mini; GPU-heavy jobs go to a Linux PC that sleeps when idle. Two Raspberry Pis handle the edge (AdGuard, Tailscale, Caddy) and a docs/monitor/NFS node, so he can keep chatting and reading lab notes even when the Linux server is off. The Dot's own cloud computer stays available, but lab docs live on the mini, so he keeps work there for speed and reliability.

He still picks the goal and approves the risky steps; the Dot and Codex carry the routine hand-offs. The write-up is first-hand setup notes, not a timed benchmark.

More copyable asks

Overnight bug fixing with a morning report:

Tonight, work through the open bugs labelled [label] in [repo]. For each one, open a Codex task with the repo, the bug, and how to reproduce it. Test every fix, open draft PRs only, and leave me a morning report in Slack: fixed, tested how, and what needs my review. Merges and deploys wait for me.

Coordinating several threads with one status list:

You coordinate my Codex threads for [project]. Keep one status list (running / waiting for my approval / blocked / ready for review), say for each thread whether it runs in the cloud or on my computer, and give me a link I can open in the desktop app whenever you mention it. Pass the goal and context into every new thread, and message me only when a thread needs a decision or a PR is ready.

A daily CI check:

Check CI on [repo] every weekday at [time]. If a job fails, find the cause, start a Codex task to fix it, and send me the PR link with a two-line summary.

A status list every 30 minutes, from Kentaro Mori's and ishizakahiroshi's setups:

While any job is open, send me one list every 30 minutes: task name, which agent and which computer it's on, and its state (sent, accepted, running, implemented, tested, waiting for me, done). For anything waiting on me, name the exact action and permission you need and what is already finished. Drop finished items after reporting them once.

One session per goal, with a report time, from Senple's and 名古屋 彩美's setups:

For each job I give you today, open a separate Codex or Work session, one goal per session. Give every session a report time of [time]; at that time, tell me what it found or finished, even if it isn't done. Keep a status list at [site / page] with the task, the session and its state (sent, running, stuck, waiting for me, done), and update it yourself whenever a state changes. Count a research task as done only when you can list the sources it read.

Briefs that live in the repo, from bbshark_13's and Jialin's setups and itsplayai's reply:

Briefs for [project] go into [repo]/[folder]. When a new one lands, read it, write a short integration plan, and open one Codex task per step with the brief's goal and its acceptance check. After every step finishes or gets stuck, update [status file / board] yourself, without waiting for me to ask: task, Codex thread link, state (running / stuck / needs my decision / done), and what you need from me. Message me only when something needs a decision.

Three jobs on one call, from the Paul J Lipsky case:

On this call I'm giving you three jobs. (1) Research [topic] and put an outline into my existing note at [Obsidian / doc path] so I can turn it into a script later — don't miss key points. (2) In the existing Codex thread for [app], add [feature] and keep an [Open in Obsidian]-style escape hatch. (3) In the existing Codex thread for [game / repo], fix [bugs] and add [dev convenience]. Line all three up now, keep each thread moving until the end goal is reached, and ping me on my phone only when you need a decision. Don't start new threads if the ones I named already exist.

App work across Codex and your own computer, from jammyrob28's setup:

Coordinate [Android / client] work across Codex and your own computer. For each bug or feature: investigate, fix, open a build I can test, and leave Play Store copy and graphics as drafts only. While I am away, use local Codex on [machine] only for checks I already approved. Message me for remote approvals by naming the exact task in Activity. Before you treat a security alert as done, show me what changed and who changed it.

Approvals that have to be given inside the task:

Before you hand this to a task, tell me the exact action, where it goes and what it will send or change, with any recipients and files, and ask me then. If the task still refuses my yes, don't retry or reword it. Tell me whether an approval is actually waiting for me, which task it is in, and that I need to approve it there in Activity. If there is nothing to approve, say so instead of sending me to look for it.

App permissions before a handoff, from nickcaracappa's thread and OpenAI Support's reply:

Before you hand [job] to a task, list the apps and actions it will need, and check that task's connected-app permissions and approval settings. If any step will still need my approval, name the exact action now, and when the task asks for it, tell me which task to open in Activity so I can approve it there.

What a task on your computer can actually use:

Before you start this job on my computer, have the task report what it can actually use: where it can write, whether it can reach the network, which tools it can call (shell, browser, Computer Use, reading my Codex threads, and [MCP server]), and whether ~/.codex/AGENTS.md and [runbook] are already in its startup context. Try one read-only call to [MCP server]. If anything this job needs is missing, stop and tell me which, instead of finding a way around it. Don't go by what the menu shows.

Handing over a thread you started yourself:

Before I hand you this thread, try one read-only read of it and tell me the exact result, and whether you have a tool for that kind of thread at all. If it fails with a placement error, CloudThreadNotFoundError or "thread not found", don't retry more than once and don't open a replacement. Tell me, and I'll keep driving that thread in the Codex app and paste you a summary.

New work the Dot should own from the start:

For new work on [project], start the Codex task yourself so you can read and follow it later. Tell me if you can only create Codex tasks and not Work tasks, before you create anything.

Keeping tasks in the right project:

Before you start anything for [project], list my projects on [computer] and confirm you can see this one. Create every task inside it. If you can't see the project, tell me before you create anything. Don't open a replacement chat for work that already has one; if you think a new one is needed, tell me which chat it replaces and why.

When sign-in or the browser fails on the Dot's computer:

If a Codex task on your computer can't sign in or can't open the browser, stop and tell me the exact error. If the job only needs to read a page, try it in your own browser instead and tell me you did.

A default model:

Use [model] for every Codex task you start for me, unless I name a different model for that specific task. A model I mention for one task is not a new default. In every status report, list which model each task used.

A plan and status page with a stopping point:

Keep the plan and status for [project] on [Site / page / Slack channel]. Before a Codex task starts, list any gaps in the plan and the tests it will need. When it finishes, check the result against that list and update the page. Stop after [N] rounds or when [result] is reached, and tell me where things stand.

Permission cards that don't appear:

Before you create or revise a custom rule that needs my permission card, tell me the request is queued. If no card appears within [N] minutes, report an actionable blocker and continue any independently authorized work. Don't leave my follow-ups unanswered while a card is pending.

Related

• Use cases hub · AI secretary: 34 daily catch-ups · Slack assistant: 25 real cases
• Dots vs Codex vs ChatGPT Work · Dots + Slack
• Dots + GitHub: 17 real examples: CI warnings, PR reviews, and draft PRs a Dot prepared
• Cloud computer: 50 real cases, for long jobs on the Dot's own machine
• Build apps, websites & games: 55 real projects, for when the Dot builds the thing itself instead of handing it to Codex
• Dots not showing or not working: 98 real reports, for a Dot that stopped replying or lost its computer
• Getting started · Pricing / usage · Features
• How to get ChatGPT Dots · Dots in the EU and UK · "Your dot is on a break": 20 user reports