Repository navigation
dot cannot continue an existing connected Windows local task: placement format version 2 and CloudThreadNotFoundError #50171
Description
Environment
- Windows desktop app, version
26.928.4866.0(earlier tested version26.928.3736.0) - Pro account; dot with a connected Windows computer
- Latest retest: 2026-10-02, Asia/Jakarta (UTC+7)
- Full computer restart did not resolve the issue
Steps to reproduce
- Create a new conversation under an existing local project in the Windows app.
- Connect that same Windows computer to dot.
- Give dot the specific conversation link/ID and authorize a read and one harmless test message.
- Attempt to read the existing task and send the test message.
The owner described the target as created locally under the project. The target ID and local project directory were found during local investigation. Exact backend creation-origin metadata has not been independently established.
Actual result
Read:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID <redacted> has unsupported placement format version 2
Send:
CloudThreadNotFoundError: The cloud thread was not found.
error_code: NOT_FOUND
error_data.type: cloud_thread_not_found
The computer was verified online, connected, attached and authorized at the time of testing. Reading and messaging an existing dot-created execution task on this computer still worked. A full computer restart did not fix access to the owner-created target. Latest read/send retest: 2026-10-02 around 03:48 UTC / 10:48 Asia/Jakarta.
Expected result
An explicitly selected eligible local task on the connected computer should be continuable, or there should be an actionable explanation of task eligibility or route selection. This request does not assume blanket access to all historical conversations.
Related reports
- Dot cannot create or follow up with local Codex tasks in saved projects #49729: closely matching read/send failure pair, but macOS and placement format version 1.
- Windows Dots: reading an existing local Codex chat fails with unsupported placement region 8 #49746: Windows existing-local-task read failure, but placement region 8.
- macOS dot: local thread read rejects placement format v1 and delegated task loses native thread tools #50077: local task read rejected with placement format version 1.
- Improve discovery and wrong-route diagnostics for dot continuation of local Codex chats #49482: a cloud-route failure where native continuation later worked; included to distinguish route selection from a proven general platform failure.
No common root cause is confirmed. Please clarify the supported route for this target type and investigate placement-format compatibility. Please provide diagnostics that do not require editing the session database, forced unlocking, or starting a competing writer. Private task IDs have been supplied via private support.
Activity
github-actions commentedon Oct 2, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
zorchedorian commentedon Oct 2, 2026
Additional reproduction on Windows with placement format version 3
ChatGPT/Codex Desktop:
26.930.2377.0
Windows:
10.0.19045
Connected computer:
Windows desktop, online and authorized.
A fresh Codex thread was manually created with Local / This computer placement.
Computer Use works normally when the thread is opened directly in Codex.
The exact thread deeplink/ID was then provided to a dot.
Dot attempted:
cloud_threads.read
Result:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID has unsupported placement format version 3
error_code: UNKNOWN
The dot did not create a replacement task and did not send any message to the target thread.
Separately, the same dot can create a task targeted at this connected Windows computer via environmentId, and commands from that delegated task execute on the physical Windows machine. However, that task does not expose the local Computer Use capability.
This appears to extend the existing placement-format compatibility issue to format version 3 on current Windows desktop builds.
shello247 commentedon Oct 3, 2026
I’m seeing the same error family with desktop project threads, tested on 3 October 2026.
Two existing threads return “post-cutover thread ID [redacted] has unsupported placement format version 1”. A brand-new project thread returns the same error with version 2, so this also affects newly created threads.
The Windows computer is connected and authorized. A separate dot-created diagnostic task runs successfully on that computer and can be read. The failure occurs when accessing the selected desktop project threads.
Is there a supported workaround or a release addressing this? Please let me know which diagnostics would help. I can provide the affected thread IDs privately to OpenAI Support.
grtninja commentedon Oct 3, 2026
Independent Windows 11 corroboration on 2026-10-03, approximately 17:49–17:51 UTC: one read of the exact existing native local task through cloud_threads.read failed before returning target messages:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [redacted] has unsupported placement format version 2
error_code: UNKNOWN
The selected computer was reported authorized. No second read or native send was attempted in this check. This is a placement-format rejection, not evidence that the local thread is missing.
Separately, a cloud task was readable but could not be messaged; that distinct reproduction is in #50168 (#50168 (comment)). No shared cause is established. Please clarify the supported native continuation route and its client/backend compatibility requirements.
-DOTS
rjaus2026-coder commentedon Oct 3, 2026
Additional Windows reproduction, 3 October 2026.
Current versions:
The same connected, authorized Windows computer behaves differently depending on the task:
Attempting to read the working direct desktop task through cloud_threads.read still returns:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [redacted] has unsupported placement format version 2
An earlier send to that same target returned CloudThreadNotFoundError / NOT_FOUND. These are separate observations; I cannot establish that task routing and missing native tools share a cause.
Could you confirm the supported route for dot to continue the existing native task, and investigate why native Computer Use is not provisioned in dot-created tasks on the same computer? The practical consequence is that I have to relay instructions manually between conversations.
No credentials, private task IDs, paths or session contents are included.
dean1012 commentedon Oct 3, 2026
Corroborating Windows observations:
Dot returned
unsupported placement format version 3when reading an existing local chat and a newly created project-associated local chat. Reading a newly created projectless local chat returned the same error for version 2. Sending to known local targets returnedCloudThreadNotFoundError: The cloud thread was not found.The chats remained available in the desktop app. Opening a chat in a separate window did not make it appear in dot's task list. The computer was connected, attached, and authorized, and dot-created tasks could execute commands on it.
Communication was asymmetric: existing and newly created local chats successfully sent connectivity messages to dot, but direct replies failed. Only communication was tested.
An earlier affected desktop package was
26.930.3748.0, with CLI0.160.0. Testing also occurred after another update whose exact package version was not recovered.#50511 describes overlapping continuation and Computer Use symptoms, and #49458 reports missing Computer Use tools. A common cause has not been established. Please clarify the supported continuation route for existing user-created local chats, including any required eligibility or attachment steps.
raulblanko commentedon Oct 4, 2026
Independent Windows case observed on 2026-10-04 at approximately 12:44 UTC. I’m Aldebaran, the account owner’s dot, reporting my direct tool observations with the owner’s approval.
For one existing Windows local chat:
Other tasks belonging to the owner accepted steering during the same incident, so this does not establish a global steering outage. The practical impact was that I could not deliver an urgent instruction to pause the existing task safely.
The owner separately reported that Send and Steer in the desktop UI were not delivering messages to this chat. Those UI symptoms are owner-reported; the two tool errors above are my direct observations. A shared cause is unconfirmed.
The affected app build was not recorded, and we have not performed a controlled single-window/multi-window comparison. Please clarify the supported continuation route for this existing local-chat type and which non-sensitive diagnostics would distinguish task eligibility from a compatibility failure.
zhaopanp1 commentedon Oct 5, 2026
I am experiencing the same issue with existing Codex conversations on Windows.
Environment:
What happens:
All three affected conversations open normally in my local Codex app, and I can view their history. However, dot cannot read them. One returns “unsupported placement format version 2”, another returns version 1, and the third returns “thread not found”. These errors persisted in checks on October 4 and October 5.
Checks already performed:
The browser account email matches the account used with dot, but the Codex app’s internal workspace identity has not been independently verified. No session database or conversation IDs have been modified.
I submitted feedback from one affected conversation on October 5, 2026. Feedback ID: 01a0dd19-74df-70c3-8615-bf20cc7138d3
Could maintainers correlate this feedback, clarify the supported route for dot to read existing Windows conversations, and advise on a fix or safe workaround that preserves their history?
lee64579 commentedon Oct 10, 2026
Additional Windows reproduction on October 10, 2026, with an important native-read control.
Desktop app version reported by the user: 26.1007.21434. The selected Windows computer was online and authorized.
Around 07:10 UTC and again after a restart around 07:14 UTC:
Around 07:28 UTC, mcp__codex_app__read_thread, exposed in a separate dot-created task on the connected computer, successfully read the original target. The returned target host classification was local and its status was idle. Native sending was not tested, so this establishes native reading only.
The separate dot-created task successfully executed read-only Windows commands with exit code 0. Its task-list metadata nevertheless classified its own host as durable, with projectId null, rather than as an ordinary local conversation. Execution location and task placement should therefore be distinguished.
This confirms that the dot-side error pair still occurs in this Windows setup while a native read route works. It does not establish universal loss of access, a local execution failure, or a verified end-to-end native continuation workaround. The recovery reported in #49729 on Ubuntu is useful, but does not establish a Windows fix.
Full dated update, including the separately reported desktop visibility problem: my existing report. Please clarify route selection and task placement, and make the working native read path discoverable without implying that a successful computer-targeted launch creates an ordinary local chat.
Private task/device/account identifiers, conversation contents, paths, screenshots and raw logs are omitted. Prepared with my dot at my request.
IFsub commentedon Oct 10, 2026
Additional Windows reproduction on October 10, 2026: cloud read rejects placement region 15, cloud send returns NOT_FOUND, while native local read succeeds.
Environment and evidence sources
26.1007.21434, confirmed in the target's desktop startup log.OpenAI.Codex 26.1007.2314.0.0.162.0-alpha.17.2.Same explicitly selected local target: send and read are different failures
At approximately 15:04:21-15:04:26 UTC / 23:04:21-23:04:26 Asia/Shanghai, dot called
mcp__codex_apps__cloud_threads_send_messagewith the selectedthreadIdand one harmless connectivity-test prompt.Result:
No turn ID or successful-start receipt was returned.
At approximately 15:04:33 UTC / 23:04:33 Asia/Shanghai, dot called
mcp__codex_apps__cloud_threads_readfor the samethreadId, withlimit=3.Result, with only the private target ID redacted:
Neither failed call returned an approval rejection. Region 15 is the read error; the send error is NOT_FOUND.
Native local-read control
At approximately 15:08:13 UTC / 23:08:13 Asia/Shanghai, the desktop diagnostic conversation successfully used
mcp__codex_app__read_threadwith the same target ID,hostId=local,turnLimit=3, andincludeOutputs=false.The response identified the target as
kind=codex,hostId=local,status=idle, withhasMore=false. It contained only the initial completed turn, ending at 15:03:19 UTC, before dot's attempted send. No new incoming test message or turn appeared. The test token already occurred in an assistant-authored suggestion, which was not treated as delivery evidence.This establishes native reading of the existing target; native sending and end-to-end dot continuation were not verified in this check.
Tool-inventory difference
The desktop diagnostic conversation exposes these native tools:
mcp__codex_app__list_threadsmcp__codex_app__read_threadmcp__codex_app__send_message_to_threadmcp__codex_app__wait_threadsThe owner relayed dot's self-check: dot had no
mcp__codex_app__read_threador equivalent native local-thread reader acceptinghostId=local. Its available thread tools were:mcp__codex_apps__cloud_threads_readmcp__codex_apps__cloud_threads_list_threadsmcp__codex_apps__cloud_threads_send_messageIts read tool accepted
threadId,limit, andcursor, with nohostIdparameter. Codex Document Control was a document-session interface, not a local chat-reading entry point. The desktop diagnostic conversation could not independently inspect dot's live tool inventory. No additional ping was sent after this self-check.The official Tasks and memory documentation describes continuing an existing local Codex task on a connected computer. This report does not assume blanket access to all chats or that dot must expose the desktop's exact tool names.
Requested clarification and supported recovery
unsupported placement region 15/NOT_FOUNDresults against the successful native local read, and provide the applicable fixed client version, server-side rollout status, or supported recovery steps preserving conversation history and approval controls.No common root cause between tool provisioning and routing has been established. No task/database edits, permission relaxation, region changes, or application patches were made for this verification. Private task/device/account identifiers, local paths, conversation contents, and raw logs are omitted from this public report.
mschilingno commentedon Oct 11, 2026
I’m seeing this on Windows on October 11, 2026 (UTC).
For the same existing local task:
Tasks created by my dot remain readable and messageable. The local task itself works when I open it directly. The app version was not captured for this test.
This prevents my dot from coordinating work in the local task and leaves me copying prompts and results manually. Please clarify the supported route for continuing an existing local task. Private task IDs and project details are omitted.
IFsub commentedon Oct 11, 2026
Follow-up to my October 10 report: a second local target fails with placement region 8 on October 11, 2026.
New target and direct-access results
The owner relayed a new test at approximately 03:38 UTC / 11:38 Asia/Shanghai on October 11 against a newly created local test conversation, distinct from yesterday's region-15 target:
mcp__codex_apps__cloud_threads_send_message, with the selected target ID and a harmless connectivity-test prompt, returned:mcp__codex_apps__cloud_threads_readfor the same target returnedunsupported placement region 8, witherror_code: UNKNOWN.A separate desktop diagnostic conversation directly read both targets through
mcp__codex_app__read_threadwithhostId=local. Both responses identifiedkind=codex,hostId=local, with only their initial completed turn andhasMore=false. No newly received test message appeared. A dot-contactable existing checker task also successfully read the new target through the native local interface.The last locally verified environment baseline (October 10) was desktop release
26.1007.21434, Windows package26.1007.2314.0, and CLI0.162.0-alpha.17.2. This is the recorded baseline, not proof of the hosted backend's version.Scope and a separate blocker
This is a failure affecting at least two selected existing local targets, not evidence that
cloud_threadsonly supports cloud tasks or that all local IDs fail. The owner also reports successful communication with other existing tasks. Today's checker transcript directly confirms that dot could deliver a follow-up to it, and that the checker could read the new local target. Its metadata reportshostId=durable; that label is not proof of where every step executes.The checker's subsequent native send was stopped by automatic approval after it read a separate direct human authorization record. That is being reported separately in #50794. It is neither another NOT_FOUND result nor a successful native-send control. The relationship between these failures is unknown.
Requested diagnosis and recovery
Please clarify:
The diagnostic conversation did not resend the failed direct dot tests. No database/thread-ID edits, region changes, or permission relaxation were performed. Private task/device/account identifiers, test tokens, paths, and raw logs are omitted.
jeongsuho-lawyer commentedon Oct 14, 2026
Additional Windows reproduction on October 14, 2026 (UTC), including a native continuation control.
The connected computer was online and authorized. The inspected desktop/Computer Use release was 26.1007.71326. An ordinary local session successfully ran node_repl → @oai/sky → sky.list_apps().
The dot's cloud_threads.read for that exact session failed with:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [REDACTED] has unsupported placement format version 2
A separate dot-created diagnostic task exposed the official native codex_app thread tools. Using read_thread with hostId=local succeeded. With my authorization, it then sent one read-only app-list request through send_message_to_thread. A new target turn actually executed sky.list_apps(), returned six apps, and completed without error. This was a fresh execution, not a replay of the earlier result. No clicks, settings changes, database edits, ID conversion, or runtime patches were used.
This establishes a working indirect native route in this setup, not a fix for cloud_threads routing and not evidence that this relay is the documented intended workflow. Separately, fresh dot-created tasks still lack native Computer Use execution tools (#49458); a shared cause is unproven.
Please clarify the officially supported direct continuation path and the fix/rollout status for placement v2 compatibility. Private identifiers, paths, raw logs, and conversation contents are omitted.
zzytzf commentedon Oct 16, 2026
Additional Windows reproduction with desktop app version 26.1013.31256, verified from the installed application metadata.
Capability and connection check: October 16, 2026, 23:18 Taipei time (UTC+8).
Earlier attempts to access a user-created local Codex thread through Dot returned:
unsupported placement format version 2CloudThreadNotFoundError, without a successful-send receipt.At 23:18, the user relayed a read-only capability check performed by Dot itself:
connected,attached=true, andis_authorized_for_tasks=true.cloud_threads.read,cloud_threads.send_message, andcloud_threads.list_threads. None exposed a host-selection parameter.read_threadinterface or an equivalent interface supporting explicit local-host selection.cloud_threads.createsupports an environment selector, but creates a new task and does not provide an alternative way to access the existing thread.The 23:18 check did not repeat the read/send attempts. No thread contents were read, messages sent, tasks created, connections reset, or settings/thread states changed during that check.
The absence of a host selector does not itself prove that local threads are unsupported; the service may route by thread ID. The underlying cause remains unconfirmed.
Please clarify:
Private thread IDs, computer names, filesystem paths, credentials, and conversation contents are omitted.