Dot cannot create or follow up with local Codex tasks in saved projects

Summary

A dot can start a local Codex task on a connected desktop, but its task-creation tool cannot select an existing saved Codex App project. A local Codex task can create a thread in that project, yet the dot then cannot read or message that project thread by its returned ID. This breaks the natural dot → project task → follow-up orchestration flow.

Reproduction

Connect a Mac running ChatGPT/Codex Desktop to a dot and register an existing local Git repository as a Codex project.
Ask the dot to create a local Codex task inside that saved project.
Observe that the dot's task creation interface accepts a computer and cwd, but exposes no project target. A task it creates directly appears projectless.
From a local Codex task, use the desktop's project-aware create_thread with the saved project ID. The new task is created and verified inside that project.
Give the new thread ID to the dot and ask it to read or send a follow-up message to that task.

Actual behavior

The dot-side read rejected the project thread ID with an error saying post-cutover thread ID ... unsupported placement format version 1. The dot-side send returned CloudThreadNotFoundError. The project task itself was valid and running in the correct repository. The dot could observe an external GitHub issue created by the task, but could not directly inspect or steer the task. This is a task-interface interoperability failure, not a missing local-computer connection.

Expected behavior

A dot should be able to create a local Codex task directly in a selected saved project, receive its thread ID, then read, message, and monitor that task through the same interface. At minimum, a project-aware thread created by a local Codex task should be addressable by the dot when its ID is known.

Why this matters

The project is the user's normal place to manage related coding work. A working-directory-only task may load repository AGENTS.md, but it is displayed outside the project and cannot participate in the expected project task workflow. The workaround requires a projectless launcher that creates a project task, after which the dot loses follow-up access.

Related and duplicate review

[Windows][dot] Local task is not associated with an existing project despite matching working directory #49646 reproduces Dot-created tasks appearing outside an existing project on Windows. That overlaps with the creation/placement half of this report.
[Desktop] Assistant-created tasks do not preserve requested Local Project destination and reasoning effort #49586 reports assistant-created tasks missing a selected local project and reasoning effort. That overlaps with placement but does not establish the Dot follow-up failure.
Codex App cannot create visible project threads for newly initialized local directories #25818: project-scoped thread creation and visibility.
Codex app thread-management tools not exposed despite thread creation being available #30233: inconsistent thread-management tool exposure.

The distinct failure documented here is that, after a valid project-scoped task is created and its ID returned, Dot-side read rejects it with unsupported placement format version 1 and send returns CloudThreadNotFoundError. Neither suggested duplicate reports this known-ID read/message failure. Please track that interoperability defect even if the placement behavior is consolidated elsewhere.

Observed on September 30, 2026 with a connected macOS desktop. I can provide version details and redacted task IDs if maintainers need them.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

[Windows][dot] Local task is not associated with an existing project despite matching working directory #49646
[Desktop] Assistant-created tasks do not preserve requested Local Project destination and reasoning effort #49586

Powered by Codex Action

+1, reproduced the known-ID read/message failure on a connected Windows desktop today (September 30).

The computer was reported as connected, attached, and authorized for tasks. For two existing local Codex tasks:

cloud_threads.read rejected one with “post-cutover thread ID [redacted] has unsupported placement format version 1” and the other with the same error for version 3
cloud_threads.send_message to the first task returned “CloudThreadNotFoundError: The cloud thread was not found.” Error code: NOT_FOUND. No turn ID was returned
Those original tasks were still accessible through the desktop’s native task controls

As a control, Dot created a separate task on that same computer, successfully read its result, and continued the same task across multiple turns. Completion notifications also worked. So local execution and follow-up work for Dot-created tasks, while access to the existing task IDs fails.

I also tested using the Dot-created task as an intermediary, but its exposed tool catalog lacked both desktop task controls and cloud_threads controls, so it couldn’t inspect or message the originals either.

+1, I’m seeing the same issue on macOS. My Mac mini is connected and authorized, but dot can’t access my existing Codex conversations even when I provide their thread IDs. Reading them returns “unsupported placement format version 1” or “version 2”, and sending a message returns CloudThreadNotFoundError.

+1, I can reproduce the read failure for an existing local Codex conversation: “unsupported placement format version 1”.

App: ChatGPT Powered by Codex & OWL 26.928.31416 (October 1, 2026 release).
Feedback ID: 01a0f0af-0fcd-70c2-a889-7e1d9a957016

Additional observation on macOS on October 1, 2026, concerning the existing-thread access failure.

Observed sequence:

The Mac mini was online, connected, and authorized for dot tasks.
Asked dot to read and continue an existing local Codex conversation using its exact thread ID. The available cloud-thread coordination interface returned CloudThreadNotFoundError / NOT_FOUND.
Manually opened the target conversation in the desktop app, waited for its context to finish loading, and retried the same ID. The failure persisted.

Control: a task created by dot on the same computer was readable through that interface.

Reading another existing local conversation returned unsupported placement format version 3. Whether that error and the not-found result share a cause is unknown.

The dot's inspected tool catalog did not expose the native local-thread read/send tools, so native local continuation was not tested. Manual desktop activation, the workaround described in #33138, did not resolve the observed failure here. The exact desktop app build was not captured.

The local-access documentation describes dots controlling existing local Codex threads. Please clarify the supported route and provide an actionable diagnostic when the selected interface cannot address an existing local thread. A routing, compatibility, or access-scope explanation remains unresolved; this observation does not establish a common root cause.

Possible workaround for new dot-created Windows tasks

Successful in my tests with both GPT-6 Sol Light and Luna Light: direct messages worked, and file creation, read-back verification, and moving the test file to the Recycle Bin all passed. The steps below describe what worked in my setup; results elsewhere may vary.

PATH CHECK: Look at the slash direction: \ → /

Broken copied path, with identifier and folder redacted:
/tmp/codex-cloud-agent-######/app_servers/thread_service/workspace/C:\<your-folder>

For the new task, use your real drive/folder with forward slashes, e.g. C:/YourFolder, without the /tmp/.../workspace/ prefix.

I reproduced this on a personal account with local Windows projects, and found a partial workaround for new dot-created tasks. Existing local-thread follow-up is still broken.

What failed

Existing user-created local chats can send a message to my dot, but the dot cannot reply to that same thread: read returns unsupported placement format version 2, and send returns CloudThreadNotFoundError. This persisted after updating the app.
A new dot-created task using C:\AI as its working directory failed when I tried to send a message directly: invalid turn/start params: AbsolutePathBuf deserialized without a base path.
Copy working directory showed a mixed path shaped like /tmp/codex-cloud-agent-######/app_servers/thread_service/workspace/C:\<your-folder>, although the Windows executor reported C:\AI. This looks related to Dot creates Codex tasks with mixed Linux/Windows working paths, causing follow-up turns to fail #49753.

What worked: step-by-step workaround

Use your own existing drive and folder. My test folder was C:\AI; "AI" is not a required folder name.

Have your dot create a local task on your connected Windows computer for the folder you want to use.
In that new chat, right-click the working-directory/folder entry and use Copy working directory. Paste the copied path into Windows File Explorer. In my failing case, it did not open the intended folder: it contained the long mixed path shown above, with ###### replacing the identifier. This is a useful diagnostic check, rather than a claim that every installation will fail.
Give that copied path to your dot and ask it to inspect it. The problem in my example was a Unix-style /tmp/.../workspace/ prefix attached to a Windows drive path.
Ask the dot to create a fresh task, using only your real Windows drive-and-folder path and forward slashes (/) instead of backslashes (\). Do not include the /tmp/.../workspace/ prefix. For example, C:\YourFolder becomes C:/YourFolder; D:\Work\Project becomes D:/Work/Project. Replace these examples with your own folder. Our successful creation call used C:/AI. Specify the model you want as well.
Open the fresh task and check its permissions. Mine showed Custom rather than the preset I expected. I manually selected my intended preset, Approve for me.
Send a message directly, then test creating a uniquely named text file in that folder, reading it back, and moving only that test file to the Recycle Bin.

The important slash change is \ → /. The successful new-task request used the real drive path with forward slashes, without the Unix prefix.

That sequence worked with both GPT-6 Sol Light and Luna Light. Choose a permission preset deliberately; this is not a recommendation to grant broader access than intended. I also saw the preset revert to Custom later.

Limits and Mac comparison

Both the slash form and permission selection were part of the successful sequence. I have not isolated their individual effects.
The copied working-directory display could still be malformed even in a working session.
This did not fix the dot's ability to read or message existing user-created local threads.
The dot's creation interface exposed one working directory, but no saved-project selector or additional-folder list. Multiple-folder access was not established by these tests.
On Mac, a new task with an explicit local folder accepted messages and create/read operations, and the copied path was correct. It appeared under an existing project with that folder. A task created without an explicit folder appeared outside projects. An existing user-created Mac thread still could not receive the dot's reply.

My working hypothesis is that Windows path handling and existing-thread routing are separate problems. These tests demonstrate a partial workaround, not a confirmed root cause.

Additional reproduction on October 1, 2026: the same placement-format rejection occurs when dot is given a deep link to an existing Remote Control Codex thread.

Environment and scope

Client: macOS desktop, in a dot conversation
Target: an existing remote Codex thread
Exact desktop version, macOS build, and subscription were not collected for this observation
One observed read failure; this does not establish that all remote threads are affected

Observed sequence

Provide dot with the existing thread's desktop deep link, shaped like:
codex://threads/<thread-id>?hostId=remote-control%3A<remote-environment-id>
Ask dot to read that conversation.
The read attempt using the thread ID from the link fails before returning any conversation contents:

AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [REDACTED] has unsupported placement format version 1
error_code: UNKNOWN

The result was explicitly reported as an error. Successful remote-host resolution was not independently established by this attempt.

Expected behavior and impact

An existing remote conversation that the user has authorized dot to access should be readable through a supported route. If an access, client-version, or routing requirement prevents that, the app should provide an actionable explanation or supported handoff. In this case, the fallback is to copy the relevant context manually.

This adds a remote-thread/deep-link case to the known-ID read failure described here. A common root cause is not established. My earlier #42331 concerns an explicit-host wait-route inconsistency, and #36673 concerns missing registered handlers; neither establishes the cause of this placement-format rejection.

All actual thread, remote-environment, server, and conversation identifiers and private project/conversation contents are omitted.

Additional Windows reproduction on October 1, 2026, with a verified desktop package version and a working dot-created-task control.

Environment

Windows x64; desktop package OpenAI.Codex version 26.928.3736.0, Store-signed.
Version independently checked with Get-AppxPackage, the package manifest, and the running ChatGPT.exe package location. This is the app package version, not the Chromium executable version.
Windows Codex CLI: 0.159.2 (separate from the desktop version).
I updated the app around 18:00 local time today and checked again; no further update is currently offered to me. Update availability is my observation, not an independently inspected Store rollout state.
The computer was successfully connected, attached, and authorized for dot tasks before the later continuation attempts.

Reproduction and errors

I asked dot to keep using my existing configured development, Windows acceptance-test, and crawler conversations, and provided their exact codex://threads/... links where available.

The attempts to read existing desktop conversations returned these errors (IDs redacted):

AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [REDACTED] has unsupported placement format version 3

AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [REDACTED] has unsupported placement region 5

A send attempt to the existing coordinator conversation returned:

CloudThreadNotFoundError: The cloud thread was not found.
error_code: NOT_FOUND

The original conversations remain present in the desktop app. The dot and its delegated local task did not expose the desktop-native thread read/wait/send tools when their available tool catalogs were checked. This is an observed capability difference, not an established root cause.

Successful control

On the same connected computer, a task newly created by dot successfully read the local repository, performed Windows-native builds and targeted tests, accepted several follow-up turns, and returned results. This confirms local execution and dot-created-task follow-up worked in this session; it does not solve continuation of the original configured conversations.

Version caveat and requested clarification

The current local-access deployment guide lists desktop version 26.929 or higher, while the tasks documentation explicitly describes continuing existing local Codex tasks. My reproduction is on 26.928.3736.0; I have not tested 26.929 or a later build and am not claiming the problem persists there.

Please clarify whether 26.929 resolves this known-ID continuation failure, how affected Store users should obtain the supported build when no update is offered, or which supported route preserves and continues the existing conversations. An actionable version/access diagnostic would be much more useful than a placement-format error or a not-found result.

Private conversation IDs, local paths, project names, source code, and raw logs are omitted. This adds version/update-availability evidence to the existing report rather than opening a duplicate.

Additional Windows reproduction on October 1, 2026. Reporting only sanitized diagnostic findings; no conversation contents or private files are included.

Running desktop package: OpenAI.Codex 26.928.3736.0. Bundled CLI: 0.159.2.
The in-app update checker displays “ChatGPT is up to date.” Availability of a newer Store build has not been independently established.
The computer is connected, attached and authorized for dot tasks.
Reading one existing local conversation through dot returns: “AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [REDACTED] has unsupported placement format version 1”.
Reading a second existing local conversation returns the same error for placement format version 3.
Control: dot-created tasks on the same computer can execute local read-only diagnostics, return results, and accept follow-up turns through dot.
The original conversation is listed in local history, which continued updating during the investigation. The full original transcript has not been read through dot.
A repair report from the original workspace records successful screenshot and browser control. The delegated diagnostic sessions expose shell tools but lack native desktop/browser and native thread-management tools. This difference is observed; a shared cause with the placement error is not established.

Please clarify the supported route for dot to read existing local desktop conversations, and whether the missing native tool exposure in delegated desktop tasks is expected. If 26.929+ is required, is it available to affected Windows Store users, and is there a verified fix for these exact errors in that version?

No resets, app restarts, permission changes or updates were performed for this reproduction. No claim is made that the version number alone establishes the cause.

Additional macOS reproduction on October 1, 2026, around 13:44–13:46 UTC: dot could not read an existing local Codex conversation using the thread ID from its desktop deep link.

The read returned:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [REDACTED] has unsupported placement format version 2

After refreshing the Mac connection, the environment was confirmed connected, attached, and authorized for tasks. Retrying the read for the same thread returned the same error.

The exact desktop app build was not captured. This observation is limited to the read failure; message sending was not tested. Whether this version 2 error shares the original report's root cause is unknown. Please clarify the supported way to read an existing local conversation or the app version needed to resolve this error.

@shieldsnapreport-maker

Control: dot-created tasks on the same computer can execute local read-only diagnostics, return results, and accept follow-up turns through dot.

Hey @shieldsnapreport-maker, could you give the workaround I posted above a try on a fresh Windows task and let me know how it goes? I used the real folder path with forward slashes (like C:/YourFolder) and manually selected my intended permission preset. I see your new tasks already work, so I’m curious whether you used a similar setup. It hasn’t fixed access to existing local threads for me.

Follow-up to my 06:22 UTC result: a fresh dot-created Mac task successfully read the same original local conversation on October 6, 2026.

At 08:21 UTC, a direct user continuation in the old relay still exposed no native thread tools, so it could not issue a native read.
At 08:23 UTC, a newly created task exposed list_threads, read_thread, send_message_to_thread and wait_threads. Native read_thread returned the original conversation, with its title and ID verified.
At 08:29 UTC, a cloud-originated follow-up to that same new task retained all four tools and successfully repeated the targeted read without truncation.

This provides a reading workaround through an additional helper task while preserving the original target conversation. It did not repair the old relay. The parent dot's latest direct read was the 06:22 failure with “unsupported placement format version 1”; direct access was not retested after creating the new helper.

send_message_to_thread and wait_threads were exposed but not exercised in the new task. This does not establish end-to-end continuation, cold-resume reliability, or durable recovery. The assistant made no configuration, cache, model or process changes to achieve the fresh-task result. The old-versus-new tool-exposure comparison is also being reported in #50800. Private identifiers, paths and conversation content are omitted.

The newer Windows/macOS reproductions narrow the failure boundary further.

A useful distinction now appears to be:

thread existence/validity != addressability from every control surface

Across the recent reports, the same existing local conversation can remain valid and readable through native desktop/CLI routes, and a fresh dot-created helper can sometimes expose native list_threads/read_thread/send_message_to_thread and successfully read that target. At the same time, the parent dot's direct cloud_threads.read / send_message path still rejects or cannot find the same known thread.

That makes thread corruption or a blanket local-computer connectivity failure less likely as the whole explanation. It looks more like a split among:

canonical thread identity / placement metadata;
parent-dot routing through cloud_threads;
delegated-task projection of native desktop thread capabilities.

I would make that split diagnosable rather than infer it from NOT_FOUND / unsupported-placement errors.

A strong contract would be:

a thread creation/lookup result returns one opaque canonical reference carrying whatever placement/version information later routing needs;
every control surface that claims authority over that thread either resolves that reference or returns a typed incompatibility/routing result;
a valid existing thread must not degrade to generic NOT_FOUND solely because one control surface cannot interpret its placement;
delegated native-tool availability should expose a capability generation/state so “fresh helper works, old helper does not” is observable rather than accidental.

A compact conformance matrix would cover:

parent direct read/send of a newly created project-scoped thread;
the same after desktop restart and project reopen;
old delegated helper vs fresh delegated helper capability projection;
Windows and macOS placement variants;
migration/upgrade of a previously valid thread reference;
explicit unsupported-placement handling without misreporting object nonexistence.

The latest helper-task successes are valuable positive controls: they show that the target conversation can remain addressable through another authorized route while the parent route fails. That should make the routing/placement boundary easier to isolate.

I am seeing the same placement problem as part of a larger continuity issue when using Dot-created Work on Windows.

The practical workflow impact is:

Dot creates a Work task.
The task is not cleanly attached to the existing Project workflow.
Follow-up steering is effectively routed through the side-chat/Dot path rather than behaving like an ordinary user-created Work session.
If I decide to return to the normal Project → Chat → Work workflow, I have to create replacement Work and manually transfer accumulated context.

The unexpected cost is not only task placement; it is the migration cost after substantial work has already accumulated under Dot.

A good recovery path would be one of:

create Dot tasks directly inside a selected existing Project;
allow a Dot-created Work task to be moved/attached to an existing Project and continued normally; or
provide an explicit handoff/convert operation that preserves context when moving from Dot orchestration back to ordinary Project/Work usage.

I also added a related continuity note to #51049, where the direct desktop follow-up path for Dot-created tasks is being tracked.

An additional positive control from my macOS case: after the successful reads reported above, the same fresh helper also successfully sent a bounded coordination message to the original local conversation, and the original conversation returned a response.

This extends the observed workaround from reading to sending and receiving a response. It does not establish that the parent dot’s direct routing is repaired, that the old helper’s missing tools have recovered, or that cold-resume reliability is resolved. No new direct-parent or old-helper retest is claimed here.

Your distinction between thread validity, parent routing, and delegated native-tool availability fits these observations, although the root cause remains unconfirmed. Private thread identifiers and conversation contents are omitted.

Adding the user-provided feedback/reference ID for my existing report above: 01a0f2ba-86d9-7581-a39b-e4666f8bd0e4.

Previous report: #49729 (comment)

This identifier is supplied for support correlation; its status as a telemetry feedback ID has not been independently verified.

Additional October 7 confirmation of the existing-Local-task read problem: a connected and authorized Mac and an explicitly identified task did not prevent cloud_threads.read from rejecting placement format version 2. This fresh observation concerns reading; it does not claim an independently tested send failure or a failed Local execution.

I opened #51722 to document the related support-matrix/documentation gap, with official sources and links to these existing reports. Documentation describes continuation of existing Local Codex tasks, subject to permissions/connectivity; a new intermediary task is not equivalent to restoring direct access to the original task. The resolved new-Work-thread-creation incident does not by itself verify this existing-task path.

A sanitized web feedback submission was attempted at approximately 15:23 UTC on October 7. The form closed without exposing a feedback ID or retained success confirmation, so no feedback ID is claimed here. Private task IDs, local paths, logs and project information are omitted.

Fix in

Powered by Codex & OWL
Version 26.1007.21434

Released Oct 9, 2026

@imyhxy

@imyhxy Thanks for the update. I’m on macOS, and Codex currently shows version 26.1007.21159 with no further update available. Is 26.1007.21434 already publicly available, or is it on a different release channel?

@ngderf

@ngderf I'm on Ubuntu 24.04, I updated from the public channel.

Additional read-only observation on macOS, 2026-10-10 around 06:34–06:37 UTC, reported with the affected user's authorization.

The user supplied an existing Codex session's exact codex://threads/<redacted> deep link and asked dot to explain its current activity. The computer discovery result showed the selected Mac as connected, attached: true, and is_authorized_for_tasks: true.

Observed from dot:

An exact-ID cloud_threads.read failed before returning any conversation content:
AppServerBackendRequestError: thread not found: <redacted>
with error_code: UNKNOWN.
Account-wide cloud_threads.list_threads(children_only=false) was fully paginated: 52 active entries, with no matching ID. The separately queried archived list returned 0 entries.
No message was sent to the target to test access, and no replacement/local helper task was created. The requested status inspection remains blocked.

This differs from the original report's placement-format error and from the send failure in #52222: this observation concerns an exact-ID read returning generic not-found, plus absence from the available account-wide list. We have not established a common cause. The target's local placement, project association, current execution state, and account/workspace mapping were not independently inspectable through this failed route; the supplied link alone does not prove those details.

Official documentation says an existing local Codex task can be continued on a connected computer (https://learn.chatgpt.com/docs/dots/tasks-and-memory), and the October 5–9 update describes following existing Codex threads (https://learn.chatgpt.com/docs/whats-new/dots-october-9-2026).

Please clarify the supported lookup/routing path and eligibility requirements for user-supplied existing session links, and return an actionable diagnostic if the selected thread is outside that route. Computer connectivity alone appears insufficient to explain or resolve this observed lookup failure.

Exact app/OS builds were not captured during this check. This is one observed incident, not a deterministic fresh-account reproducer or a claim of a service-wide outage. Public details intentionally omit thread/device/account identifiers, local paths, private conversations and raw logs. No sync reset, permission change, session migration, or other recovery mutation was performed.

Update after installing Codex macOS 26.1007.30912 (October 10 release).

A limited read-only retest at approximately October 10, 2026, 20:22 UTC / October 11, 04:22 HKT succeeded through the existing helper-mediated route: the coordinator could message the implementation task, and both task contexts completed a get_usage_limits({}) call.

This did not retest the failing direct parent-dot access/saved-project placement path, so it does not establish that #49729 is fixed. It also did not retest the old task with the missing native tool namespace in #50800.

We observed a separate telemetry discrepancy on the same connected Mac:

Coordinator: accountId populated, ordinaryUsageAllowed=true, spendControlReached=false, rateLimitResetCredits populated
Implementation task: those fields were present but null
Both returned a successful tool result and reported 79% usage

The null values were present in the returned response, not introduced by caller parsing. We have not established whether this is related to the connection issue, and are not treating null as an explicit permission denial. The same discrepancy was observed before the update and persisted in this retest. No settings changes, credit resets or project execution were performed during the check.

Could you clarify whether the differing field availability is expected across these task contexts, or whether it should be filed as a separate issue? Account identifiers and other private data are omitted.

Confirmed on October 12, 2026, with a connected, authorized Mac:

cloud_threads.read failed for two user-created local threads (one older, one created today): AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [REDACTED] has unsupported placement format version 1.
cloud_threads.send_message to the older thread returned CloudThreadNotFoundError / NOT_FOUND.
Both operations worked for dot-created tasks.

Environment, collected afterward: macOS 27.2 (26B5091g), arm64; installed ChatGPT Desktop 26.1007.30912 (20156); separately installed Codex CLI 0.160.0.

Confirming the previously reported macOS helper workaround: a dot-created local helper with native thread tools read both affected threads and relayed one authorized coordination message to an idle target, which acknowledged receipt without interruption. Direct parent-dot access still failed.

Working route confirmed on Windows (Codex desktop 26.1007.2314.0, CLI 0.162.0-alpha.17.2): dot → existing local thread via a dot-created computer task

Parent dot context still cannot reach existing local threads directly, but a full dispatch → execute → auto read-back loop now works through a dot-created task on the connected computer.

Parent dot (still broken, server-side):

Parent dot has a JS execution entry. typeof tools.mcp__codex_app__list_threads / read_thread / send_message_to_thread all return "undefined", and a prefix match on mcp__codex_app__ returns [].
mcp__codex_apps__cloud_threads_read on an existing local thread ID fails with post-cutover thread ID … has unsupported placement format version 1. Send returns NOT_FOUND. This persists after reconnecting the computer (Allow access) and restarting dot.

Dot-created computer task (works):

Dot creates a new task on the connected Windows computer with cloud_threads create and that computer's environmentId.
That task exposes 57 mcp__codex_app__* tools, including list_threads, read_thread, send_message_to_thread and wait_threads.
read_thread with hostId: "local" reads the existing local thread (status idle).
send_message_to_thread with hostId: "local" delivers a side-effect-free prompt with a unique tag. The existing thread runs a new turn: its input arrives as <codex_delegation> with source_thread_id set to the helper task, it replies with the correct result, and task_complete fires (about 5 s).
The helper reads the result back, and dot reads the helper's final answer automatically, with no manual relay.

I verified the target turn independently in the local rollout JSONL (function_call_output from send_message_to_thread, namespace codex_app, then final_answer and task_complete). The original thread's context is preserved.

Note: an older dot-created "durable" task on the same machine still reports unknown MCP server / 0 tools, while a freshly created one has the full catalog. If your helper task lacks the tools, create a new one rather than reusing an old one.

Not yet tested: persistence after a full desktop cold restart or app update.

This is a workaround, not a fix. The parent dot still lacks the native tools, and the cloud route still rejects local placement IDs.

Another Windows reproduction on October 13. My laptop is connected and authorized for tasks. Reading and following up on Dot-created tasks works, including tasks whose commands execute on that laptop.

However, when I manually start an ordinary local Codex chat and give its thread link to my Dot, cloud_threads.read fails with:

AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [redacted] has unsupported placement format version 1

An older ordinary local thread on the same computer fails with the same message but placement format version 3. The IDs were copied from the actual local chats, not constructed. We have not tested sending to those unreadable threads or edited any IDs/session storage.

This distinction matters: creating a new Dot-coordinated task on the laptop does not restore access to the existing local chat, and it can expose different tools/permissions. The failure has prevented my Dot from checking and coordinating work I had to start manually.

The native local-helper read/relay reports in this discussion look promising, but we have not yet verified that workaround in my environment. Please distinguish a supported way to read/continue existing local threads from creating replacement tasks. If placement versions 1 and 3 are supposed to be supported, an explicit compatibility fix or diagnostic would help.

There is also a separate MXC browser-launcher failure in our delegated Windows tasks, reported in #53188. These are two observed failures; we do not have evidence that they share one root cause.

Update, 14:53 UTC: the read-only workaround is now verified here. An already-existing delegated executor exposed native mcp__codex_app__list_threads/read_thread. Its read_thread with hostId: local successfully read the exact ordinary local chat that the parent's cloud_threads.read could not read. No replacement task, ID edits, raw session-file access or permission changes were needed. This establishes a working native read path in this executor; it does not establish that parent routing is fixed or that native message relay has been tested.

Reproduced on Windows 11 on October 13, 2026.

The desktop was reported as connected, attached, and authorized for tasks. A direct call from the dot conversation to cloud_threads.send_message for an existing local Codex thread returned:

CloudThreadNotFoundError: The cloud thread was not found.
error_code: NOT_FOUND

For comparison, a helper task on the same desktop used the native send_message_to_thread tool with the same thread ID and hostId: "local". That call was accepted without an error. The requested acknowledgment was not observed, so this confirms acceptance only, not successful processing.

A separate creation test using create_thread with target: {"type": "projectless"} returned hostId: "local" and a test reply, but the resulting thread was still labelled as cloud in the UI. Therefore, hostId: "local" alone did not establish the local thread type expected by the user.

The remaining requirement is direct dot-to-existing-local-thread access, without a helper task. Is there a supported fix or an app version that addresses this route?

Thread IDs, computer names, local paths, and screenshots are intentionally omitted for privacy. The exact desktop app build was not collected for this retest.

Navigation Menu

Repository navigation

Dot cannot create or follow up with local Codex tasks in saved projects #49729

Summary

Reproduction

Actual behavior

Expected behavior

Why this matters

Related and duplicate review

Possible workaround for new dot-created Windows tasks

What failed

What worked: step-by-step workaround

Limits and Mac comparison

Environment and scope

Observed sequence

Expected behavior and impact

Environment

Reproduction and errors

Successful control

Version caveat and requested clarification

29 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Dot cannot create or follow up with local Codex tasks in saved projects #49729

Description

Summary

Reproduction

Actual behavior

Expected behavior

Why this matters

Related and duplicate review

Activity

github-actions commented on Sep 30, 2026

aaronjones003 commented on Sep 30, 2026

xthunder0 commented on Oct 1, 2026

fukaya0404 commented on Oct 1, 2026

0xAISam commented on Oct 1, 2026

alenknight commented on Oct 1, 2026

Possible workaround for new dot-created Windows tasks

What failed

What worked: step-by-step workaround

Limits and Mac comparison

futurenowlabs commented on Oct 1, 2026

Environment and scope

Observed sequence

Expected behavior and impact

agbushuo commented on Oct 1, 2026

Environment

Reproduction and errors

Successful control

Version caveat and requested clarification

shieldsnapreport-maker commented on Oct 1, 2026

JAMESHPF commented on Oct 1, 2026

alenknight commented on Oct 1, 2026

29 remaining items

ngderf commented on Oct 6, 2026

aetherxeg-source commented on Oct 6, 2026

jeonghakhui-art commented on Oct 6, 2026

ngderf commented on Oct 6, 2026

nicocostac commented on Oct 6, 2026

omarpinarecords commented on Oct 7, 2026

imyhxy commented on Oct 9, 2026

ngderf commented on Oct 9, 2026

imyhxy commented on Oct 9, 2026

nokiyliao commented on Oct 10, 2026

ngderf commented on Oct 10, 2026

flamingice commented on Oct 12, 2026

yxt2050-oss commented on Oct 12, 2026

ArTeGaS commented on Oct 13, 2026

moz9 commented on Oct 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions