dot cannot read user-created Codex threads: “unsupported placement format version” / “unsupported placement region”

What issue are you seeing?

Summary
I’m trying to use dot to access existing Codex threads that I created myself, rather than tasks originally created by dot. Reading these threads fails with backend errors, even though my Windows desktop is connected and dot can discover my local Codex projects.
This appears inconsistent with the recently announced ability to follow up on existing Codex threads:
Official announcement:
https://x.com/ChatGPT/status/2108636748217770180?s=20
Official release notes:
https://learn.chatgpt.com/docs/whats-new/dots-october-9-2026
Related documentation:
https://learn.chatgpt.com/docs/dots/tasks-and-memory
The announcement describes starting Codex work and following up on existing threads. In my tests, access works for a previously dot-created task, but fails for the user-created threads tested below.

What steps can reproduce the bug?

Environment

Test date: October 10, 2026; earlier attempts also failed before this date.
Codex/ChatGPT desktop on Windows; requests to dot sent through ChatGPT web on Windows.
Desktop reported connected, attached, and authorized for tasks.
I updated the desktop app and requested another test. The same Architect-thread error persisted afterward.
Reconnecting the computer did not resolve that error either.
Exact desktop app/build version was not captured during these tests.
Steps to reproduce

Connect the Windows desktop to dot.
Copy a codex://threads/<thread_id> link from an existing user-created Codex session.
Ask dot to read that thread without sending messages or modifying it.
dot invokes cloud_threads.read with the supplied threadId and a small limit, such as 2 or 3.
The request fails before returning conversation content.
Tools used

cloud_threads.read — full tool name: mcp__codex_apps__cloud_threads_read.
cloud_threads.list_threads with children_only=false, limit=50; archived=true was checked separately.
cloud_threads.list_environments.
cloud_threads.list_projects with the connected computer’s environmentId.
Observed results
A. Existing project-associated Architect thread:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID <THREAD_A> has unsupported placement format version 2
This was reproduced repeatedly, including after the desktop update and reconnection.
B. Another existing user-created thread:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID <THREAD_B> has unsupported placement format version 3
C. An existing session not associated with a project:
AppServerBackendRequestError: thread not found: <THREAD_C>
D. A new session I created specifically for testing after the update:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID <THREAD_D> has unsupported placement region 10
These read failures returned isError=true and error_code=UNKNOWN. No conversation content was returned.
Successful control checks
cloud_threads.read successfully returned messages from a previously dot-created task on the same computer.
cloud_threads.list_environments confirmed the desktop connection and task authorization.
cloud_threads.list_projects successfully returned my registered local projects, including the relevant project’s ID and root path.
Additional findings and limits
Account-level list_threads returned 30 IDs with no continuation cursor. The first two failing thread IDs were absent. The archived list was empty. This listing check occurred before the new test session was created.
That listing exposed IDs, not thread titles or project associations. It therefore did not provide a usable list of chats belonging to my local project.
Project discovery only confirms access to the sidebar project registry. Its registered root path is an old folder; active worktrees are elsewhere. We did not establish access to those worktrees through this check.
The read-tool description mentions expanded access to existing threads, but no available status field confirmed whether that capability is enabled for my account.
No messages were sent to the affected threads. No threads or worktrees were created by dot during this investigation, and no project files were changed.
Expected behavior
dot should be able to resolve and read an authorized existing local Codex thread on the connected computer, consistent with the announced feature. If a thread type, account rollout, or app version is unsupported, the error should explain the requirement or limitation clearly.
Impact
I cannot use dot to follow an existing Architect session and coordinate ongoing project work. I still have to manually copy messages and reports between Codex and dot.
Diagnostic interpretation — not a confirmed root cause
The placement-format and placement-region errors suggest a possible thread-ID compatibility or routing problem. We have not confirmed whether this involves local versus cloud thread storage, rollout state, permissions, or another backend issue. The errors do not establish that the threads were deleted, and “region 10” should not be assumed to represent my geographic location.
Please investigate why existing-thread reads fail while desktop/project discovery and a dot-created-thread read succeed, and confirm whether any account setting or client update is required.
I can provide the actual thread IDs privately through Feedback/support; they are intentionally omitted from this public report.

What is the expected behavior?

No response

Additional information

No response

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

[macOS / dots] Cannot read manually created Codex threads (placement format v2/v3); repeated app approvals #52247
dot cannot read Codex threads: unsupported placement regions 6 and 14 #52331
[macOS 26.1002.52244] Dot still cannot read the original Local Codex task: unsupported placement format version 2 #51880
Dot cannot connect to codex conversations Error unsupported placement format version 3 #51731
dot coordination with tasks failing #51931

Powered by Codex Action

I’m seeing a matching Windows existing-thread read failure today, October 10: unsupported placement format version 2. A separate older conversation is readable, while the affected conversation can work when I send instructions directly in Codex Desktop. I also observe unconfirmed continuation from dot text chat/voice and unconfirmed new-chat starts, but we have not established that these delivery symptoms share the read error’s cause. My detailed, privacy-redacted report is here: #50698 (comment). The new-task creation timeout reported in #52793 is also related by symptom, not a proven common cause. Please consolidate or route the separate symptoms as appropriate.

Same issue on macOS with ChatGPT desktop 26.1007.30912, October 11.

I gave dot a codex://threads/ link to a local Codex thread I created. The thread worked directly in Codex, but dot’s cloud_threads.read call returned:

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

No conversation content was returned. Reads of other dot-created tasks worked. I had to copy the local thread’s completion summary into dot manually.

Additional Windows reproduction on 2026-10-12 (Asia/Bangkok):

A manually created Codex desktop thread was active on a Windows computer and was returned by the desktop's native thread listing with hostId: "local".
The user copied its internal codex://threads/<thread_id> deeplink to dot and asked dot to read it.
dot's task service rejected the read with the exact sanitized error: unsupported placement region 13.
No thread content was returned. The thread remains readable and active in the desktop app.
As an independent control in the same manually created thread, the supported Codex In-app Browser (iab) successfully opened https://example.com/, read “Example Domain,” and closed the temporary tab. This browser result is separate from the cross-placement thread-read failure.
A data: page test was not retried because the browser correctly restricts navigation to HTTP/HTTPS.

The private thread ID, account identifiers, and local paths are omitted. This adds region 13 to the placement-region variants already documented here and supports the same user-created local-thread versus dot-created-task distinction.

Additional Windows reproduction on 2026-10-12, approximately 14:18–14:19 UTC+08.

The Windows computer was reported as connected, attached, and authorized for dot tasks. Local project discovery had also succeeded.
I supplied the exact link/ID of an existing local Codex conversation and requested read-only progress monitoring. A fresh dot-side cloud_threads.read call with limit: 5 returned:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [redacted] has unsupported placement format version 1
The result had isError: true and error_code: UNKNOWN. No conversation content or request ID was returned.
Following the native-tool discovery example in Improve discovery and wrong-route diagnostics for dot continuation of local Codex chats #49482, exact callable checks in this dot context returned undefined for all three:
- tools.mcp__codex_app__list_threads
- tools.mcp__codex_app__read_thread
- tools.mcp__codex_app__send_message_to_thread
  None of these exact names appeared in the available tool catalog.
A read-only web check could retrieve older dot-dispatched conversations, but did not locate the selected original local conversation. A /local/ URL alone did not establish native local placement: the opened pages were labeled cloud chats.

No new controller task was created, no instruction was sent to the affected task, and no task was resumed or interrupted.

Please clarify the supported route and capability requirements for dot to read an explicitly identified existing local Codex conversation, then monitor it and send follow-up instructions when separately authorized. Requiring another task to relay information undermines this workflow and risks context loss or duplicate work.

This reports the observed failure and missing tool exposure in this context; it does not establish a common root cause or product-wide unavailability. The desktop app/build version was not captured. Private conversation IDs, paths, account identifiers, and project contents are omitted.

Additional controlled reproduction on Windows, 2026-10-12 at 18:33 UTC:

The desktop is connected, attached and authorized for dot tasks.
Parent-side cloud_threads.read of an existing user-created work thread fails before returning content: AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [redacted] has unsupported placement format version 2.
Parent-side cloud_threads.send_message to the same existing thread returned CloudThreadNotFoundError: The cloud thread was not found at approximately 18:01 UTC.
Control: parent-created desktop tasks can be created and read successfully.
Control: a parent-created local coordination task successfully used the supported desktop Codex thread tools to read and send a scoped instruction to that exact existing work thread, which executed it and returned a completion result. Thus the existing thread is present and reachable through the local tool route.

The local relay is a workaround, not a repair of the direct route. Please clarify whether this requires an account rollout/capability change or a backend placement-decoding fix, and identify the supported repair or release when available. We can provide exact identifiers privately through Support. Private thread IDs, local paths, project contents and credentials are omitted here. A separate delegated-browser initialization issue is being tracked independently; no shared cause is claimed.

Update, 2026-10-12 at approximately 18:51 UTC: in-app feedback submission is now confirmed. Feedback ID: 01a118b6-32a4-74ac-bbad-a30e5ca9c0cc. Please use this reference to correlate the report internally. No private screenshot or conversation transcript is attached to this public comment.

Additional reproduction on 2026-10-13 (UTC), submitted with the affected user's permission. Private thread IDs, conversation contents, local paths and credentials are omitted.

The discrepancy is still reproducible on a connected, attached Windows desktop authorized for dot tasks:

Direct cloud_threads.read of existing local coordinator A fails with unsupported placement format version 3; coordinator B fails with unsupported placement format version 2.
Direct cloud_threads.send_message to those same existing IDs returns CloudThreadNotFoundError / NOT_FOUND.
A third existing local thread read fails with unsupported placement region 6.
Direct read/send succeeds for newly dot-created helper tasks on the same connected computer.
From an authorized local helper, native read_thread resolves the exact failing coordinator IDs, including their titles and idle/active states. Native send_message_to_thread can send to those same IDs, and subsequent reads have shown coordinator replies and active execution. Thus the direct NOT_FOUND response does not establish that the local conversation is absent.
cloud_threads.list_threads(children_only=false, limit=50) returned 37 IDs and no next cursor in one check; the affected old coordinator IDs were absent. This is a cloud-directory observation, not an exhaustive statement about local history.
The direct read failure was still observed at approximately 05:04 UTC today while local-helper coordination worked. The exact desktop build was not captured in this reproduction; we are not claiming a particular release caused or fixes it.

The user recalls earlier successful coordination. Our available evidence confirms earlier successful local/native-helper coordination, but does not establish a previously successful direct cloud read of the same affected ID. Please distinguish a direct-route regression from an unsupported or unresolved native-thread placement. We cannot determine from the error whether the fault is ID parsing, thread registry/routing, capability rollout or authorization resolution.

Could maintainers confirm the supported direct path for an existing user-created local thread, whether any specific update or account capability is required, and whether a fix is available? A useful acceptance test would be direct dot read of the unchanged original ID, followed by an explicitly authorized send/read-back on that same ID. Creating a replacement thread or using a local helper does not verify that the direct route is repaired.

WORKING SOLUTION*

Additional Windows verification on October 13, 2026: a local native-tool workaround worked for us, while the direct dot read route remains broken.

Direct cloud_threads.read of two unchanged existing user-created Codex thread IDs still returned “unsupported placement format version 3” and “unsupported placement format version 2.” Neither call returned conversation content.

We continued an existing dot-created helper session on the connected Windows computer. Its actual exposed native Codex tools included mcp__codex_app__list_threads and mcp__codex_app__read_thread. Using read_thread from that local helper successfully read BOTH original failing threads, including titles and latest completed turns. No replacement of either original thread was needed.

We then tested native mcp__codex_app__send_message_to_thread on both inactive/completed original threads. Each received a benign reply-only instruction and returned its own unique acknowledgment, verified by subsequent native reads. Both test turns completed and ended idle. No file edits, commands or deployments were requested in these messaging tests.

Local creation also worked through the supported native route. After restoring an existing project’s missing sidebar entry, we created exactly one new local test session inside that project and verified its project association and acknowledgment. A separate test created a local session in a specified sidebar Working Bucket; explicit section membership was verified, rather than inferred from running status. The user also confirmed Full Access in that new session’s UI.

A read-only PowerShell diagnostic in the newly created local session executed successfully, read the project directory and found an installed codex.exe through PATH without the earlier filesystem-provider initialization warning. An older helper still had that warning and could not find Codex through its PATH. This demonstrates a difference between execution contexts; it does not establish the cause or a general PowerShell fix.

Important limits: the native local helper route is a verified workaround, NOT a repair of cloud_threads.read. Installing a CLI or using hooks was not necessary for the successful native read/message tests. We have not established the underlying routing/placement cause, the effect of approval-policy changes, or which app build fixes the direct route. App/build versions were not captured. Private thread IDs, usernames, paths and conversation contents are intentionally omitted.

Could maintainers confirm whether native local-thread tools are the intended supported workaround, and whether a direct-route fix is available?

Here is a prompt to give your DOT to get up and running quickly!

Reusable prompt for testing the local Codex workaround

Paste this into your dot/Jim conversation and replace the bracketed values:

Please investigate and test a supported local-native workaround for reading this existing Codex conversation: [codex://threads/THREAD_ID]. My computer is [COMPUTER_NAME], and my existing Codex project is [PROJECT_NAME].

Use my connected local computer, not a cloud workspace. Prefer continuing an existing authorized local helper task. If none exists, you may create one small local diagnostic helper in the specified existing project. Verify actual computer and project placement; a working-directory path alone is not proof of sidebar project association. If the project is missing from discovery, ask me to check its sidebar entry before creating a substitute.

First inspect the helper’s actual available tool catalog for supported native Codex thread tools. In our successful example, these were mcp__codex_app__list_threads and mcp__codex_app__read_thread. Names and availability can differ: do not invent tool calls or assume they are exposed.

If a native reader is available, attempt a bounded read of the exact original thread ID. Do not resume, fork, interrupt or send instructions to the original thread during this first test. Verify returned conversation content and current state. Report whether the local native read works separately from the direct cloud_threads.read result.

Do not install a CLI, modify configuration or permissions, disable security controls, inspect private history files, or retry explicitly denied filesystem lookups as part of this test. The successful native route did not require those changes. If native tools are unavailable, explain the specific missing capability rather than claiming the workaround works.

After a successful read, ask me whether to test messaging. If I approve and the target is idle, use its supported native messaging tool to request a unique reply-only acknowledgment: no commands, file edits, deployments or project work. Verify the target-generated reply with a subsequent read; delivery admission alone is not success.

Optional separate tests, only when I request them: create one local reply-only session in my existing project; place it in a specified sidebar bucket if supported; run bounded read-only PowerShell diagnostics. Verify local host, project and explicit bucket membership, and distinguish UI-confirmed Full Access from settings not exposed by tool metadata. Check for duplicates before retrying an uncertain creation.

Give me a concise report of the route used, verified results and remaining limitations. Treat this as a local workaround, not proof that the direct reader is fixed. Keep any public report free of private thread IDs, usernames, local paths, credentials and conversation contents.**

Background report: #52873

This prompt requests capability checks; it cannot grant tools or permissions that the user’s installation or account does not expose.

Reproduced on macOS on October 14, 2026, around 21:13 UTC.

Dot cannot read local Codex threads I create myself on my laptop, including brand-new threads. Direct cloud_threads.read calls returned:

unsupported placement format version 3
unsupported placement format version 2

Neither call returned conversation content. I have observed this across multiple repositories. In contrast, Dot can read the local helper threads it creates itself.

There is also a separate desktop visibility/pinning issue affecting those successfully created Dot tasks, documented at #51675 (comment) . No shared root cause is established.

Additional Windows Remote Control evidence observed October 14, 2026 (October 15, 01:08–01:45 UTC). This overlaps the placement-v2 symptom, but our affected route is native cross-host Codex app tools, not only cloud_threads.read.

Both Windows installations report app package 26.1007.9446.0 and actual bundled codex-cli 0.162.0-alpha.17.2.

Observed:

A coordinating desktop/voice chat successfully creates a fresh saved-project/local chat on an enrolled remote Windows worker with create_thread.
The worker's local UI continues execution and displays approvals normally. SSH and the task's own saved scope/results confirm progress; one affected task completed its release and QA while remote status reads were failing.
From the coordinator, native read_thread, wait_threads, and list_threads intermittently report unavailable host/cannot determine whether the thread exists. One passive read reported a host change. Native send_message_to_thread can remain unresolved beyond one minute without a delivery receipt. We do not infer whether those uncertain sends were ultimately delivered.
Some later native reads work; fresh chat creation can work while reading/following that fresh chat fails. Worker reboot did not prevent recurrence.

Correlated desktop errors for the fresh affected chat around 01:41–01:42 UTC:

-32000: Codex app-server is not available
failureReason=remote_unavailable
app_server_client_request_queue_rejected reason=queue-expired
thread/read and thread/turns/list: 15000ms timeouts
-32600: thread not loaded: [REDACTED]
-32602: Client specified an invalid argument: post-cutover thread ID [REDACTED] has unsupported placement format version 2
grpcStatusCode=3

A subsequent fallback produced conversation_inaccessible/404, while the actual worker task continued locally. These are correlated symptoms; a shared internal cause with this issue is not established. Matching installed app/runtime versions rule out a simple observed version mismatch, not every compatibility or backend rollout possibility.

Impact: coordinator loses visibility and follow-up delivery despite healthy worker execution, requiring manual status recovery and creating pressure to duplicate chats. Expected: native remote reads/steering remain available or expose accurate reconnect state and bounded delivery receipts.

A separate permission-inheritance symptom in the same workflow is documented with additional evidence under #40125. We are not asserting it shares the connection failure's cause. No private thread/host/account IDs, project content, email addresses, raw session logs or credentials are included.

Follow-up to my October 13 report above, with a fresh Windows observation on October 17, 2026, at approximately 10:40 UTC.

Observed through dot's supported task tools:

Reading existing target A with cloud_threads.read consistently returns "unsupported placement region 9".
Reading existing targets B and C consistently returns "unsupported placement format version 1".
The same target-specific errors persisted across earlier attempts over several hours; these reads returned no conversation content.
In the same diagnostic period, other existing conversations were readable through cloud_threads.read, and follow-up messages to working conversations succeeded.
The selected Windows computer was reported connected and authorized for tasks, and cloud_threads.list_projects successfully discovered the relevant local project.

This adds current region-9 and format-1 observations with successful controls. It does not establish that every existing conversation fails, that the affected histories are lost, or that "region 9" identifies a geographic/network region. No controlled network-path comparison has established a local proxy or network cause. Exact desktop/backend versions were not verified for this observation.

Separate creation symptom during the same investigation: several cloud_threads.create attempts returned "Internal error"; subsequent inspection found empty task records with latestTurn=null. Attachment succeeded, but a subsequent send returned NotFound. Please keep this creation/initialization symptom separate from the existing-thread placement rejection unless backend evidence establishes a shared cause. An attached record alone did not demonstrate a usable running task.

Impact: dot cannot reliably inspect and coordinate the selected existing tasks, while some other task routes remain usable.

Could maintainers identify:

The supported direct read/continuation route and required capability or deployment for these existing targets.
Which component rejects the placement region/format, and whether rejection happens before dispatch to the connected computer.
A supported correction or release, with a same-original-ID read as the recovery check.

A local relay or successful replacement-task creation would be useful workarounds but would not establish repair of the original direct reader. No official root-cause conclusion is asserted here.

Submitted with the affected user's approval. Private thread/computer IDs and names, conversation contents, personal paths, credentials, screenshots and raw logs are omitted.

Additional macOS reproduction and native-read workaround verification on 2026-10-17, approximately 14:06–14:11 UTC.

The desktop reported connected, attached and authorized for tasks. Codex had just been updated/restarted according to the user; exact app/build and runtime versions were not captured.
Direct dot-side cloud_threads.read repeatedly failed on an existing user-created local thread with this sanitized error:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [REDACTED] has unsupported placement format version 2
error_code: UNKNOWN
Control: a new local helper task was successfully created on the same connected desktop, and dot-side cloud_threads.read successfully read that helper's result.
From that helper, the actually exposed mcp__codex_app__read_thread successfully read the same original thread ID, returning conversation content and active/in-progress status.
A direct cloud_threads.read retry after the native-read success, at approximately 14:11 UTC, still returned the same placement-format-v2 error.

The diagnostic did not send messages to, interrupt or replace the original conversation. No files/settings were changed, and no CLI, hooks or services were installed. Native message-send was not tested.

This verifies a read-only local-helper workaround in this environment, not a repair of the direct route or a confirmed root cause. Could maintainers identify any fixed app build or backend rollout? A useful acceptance check is successful direct cloud_threads.read of the unchanged original thread ID, without requiring a replacement conversation or helper relay.

Private identifiers, usernames, computer names, paths, project/conversation content, credentials, screenshots and raw logs are omitted.

Actual human edit: A weakness with these models is the fact that they'll post bug reports as if they're responding to the operator's prompt, assuming that everyone in this repo somehow cares whether private identifiers were left out or if it interrupted or replaced the original conversation. And let's end off talking about what wasn't done, as if that's not an infinite list.

Retracted: this comment concerned the wrong instance and was incorrectly associated with dot. Please disregard the previous report.

補充 Windows 同一原始對話串的唯讀重測，時間為 2026-10-17 18:22–18:27 UTC（2026-10-18 02:22–02:27，UTC+08:00）。

已核對的桌面版本

應用程式回報 installedVersion: 26.1013.40934、installedBuildVersion: 20770、installedReleaseChannel: prod。
內建更新檢查回傳 up_to_date；這只代表目前安裝管道沒有提供更新，未核對後端或 bundled CLI 版本。

同一原始 ID 的對照與重測

本機官方 mcp__codex_app__read_thread 可讀取該既有串，回傳標題、最新回合與執行狀態。重測前後讀取的都是同一原始 ID，沒有換成替代串。
dot 的實際回覆回報，cloud_threads_list_environments 呼叫一次，該 Windows 電腦為 connected、attached=true、is_authorized_for_tasks=true。
首次 dot 唯讀讀取失敗後，再於目前 dot 主對話核對工具並對相同 ID 重測一次：mcp__codex_apps__cloud_threads_read，limit=2。仍取得 0 則訊息，沒有對話 metadata、標題、最新回合 ID 或內容。

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

dot 在該回合的工具盤點中回報：mcp__codex_app__read_thread 與 mcp__codex_app__list_threads 均未提供；cloud_threads_read 可用。未找到其他明確支援讀取既有本機 Codex 串內容的正式入口。因此，無法直接切換到本機原生 reader。

診斷界線與請求

這組對照顯示：電腦連線正常、原串在本機可讀，但 dot 的直接讀取路徑仍拒絕該 ID 的 placement 格式。這不代表原串不存在，也未確認內部根因究竟是識別碼解析、路由、能力開放或服務端部署。

本輪是既有 dot 主對話中的唯讀診斷，未建立輔助任務，也未向目標串送出訊息或中斷其既有工作。沒有可驗證的本機修復；原生讀取成功不能當作 dot 直接路徑已修復。

請協助確認適用的正式讀取入口、必要能力或修復版本。復原驗收應以 dot 成功直接讀取未變更的原始對話串 ID，並回傳正確 metadata 與最新內容 為準。

Additional affected user on 18 October 2026, using two Macs and the mobile interface. This breaks an ordinary workflow: continue existing work from another computer without manually copying the conversation.

The assistant on the other device reported that account-wide task discovery did not surface an existing desktop-created task. After I supplied its exact thread ID, it reported unsupported placement format version 3 on reading and thread not found on messaging. Those failures are evidenced by a screenshot of that assistant's report; the raw failing tool outputs were not available to the diagnostic session, so the exact backend call and root cause remain unverified.

Control checks performed from the source Mac in the same troubleshooting session:

mcp__codex_app__read_thread successfully read the affected task by the same ID.
mcp__codex_app__list_threads included that task and tasks on another host, with no unavailable hosts reported.
mcp__codex_app__read_thread with the returned host ID successfully read a task on that other host.
The built-in update check returned installed version 26.1013.40934, build 20770, release channel prod, status up_to_date. This describes the source Mac only; the other device's app version was not verified.
No new cross-host message was sent during these checks, so two-way messaging has not been verified.

The task exists and is readable through the desktop tools, while the other assistant's route reports unsupported placement / not found. Please investigate compatibility and routing between these task surfaces, and provide an actionable error or supported fallback. Asking users to keep copying IDs, briefs and summaries between their own devices defeats the purpose of cross-device continuity.

Private thread IDs, screenshots containing unrelated conversation content, repository names and logs are intentionally omitted from this public comment.

Additional reproduction on macOS, 2026-10-18, approximately 15:57–15:59 UTC, submitted with the affected user's permission.

Observed from the dot's actual tool calls:

cloud_threads.list_environments twice reported the intended Mac as connected, attached, and is_authorized_for_tasks=true.
A direct cloud_threads.read of an existing local Codex thread with limit=1 failed before returning any conversation content:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [REDACTED] has unsupported placement format version 2
isError=true; error_code=UNKNOWN.
Control: cloud_threads.read of the current dot conversation succeeded during the same check.
The exposed dot tool definitions provide read/send_message by threadId, but no hostId/local selector or native local read_thread/send_message_to_thread tools. No placement repair/migration tool was exposed.

This reproduction establishes a direct-reader failure; no new send was attempted, and no common underlying cause or specific app-build regression is claimed. The exact desktop build was not collected. Private thread IDs, environment IDs, account details, local paths and conversation contents are omitted.

Please clarify the supported direct route for an authorized existing local thread, any required capability rollout or supported repair, and whether a fix is available. The required acceptance test is direct dot access to the unchanged original thread, followed by a separately authorized send and target read-back. A helper/relay or replacement thread does not demonstrate that the direct route has recovered.

I'm seeing the same failure on macOS. Fresh checks on 2026-10-19 at approximately 00:28–00:32 UTC produced:

The intended directly connected Mac was reported as connected, attached, and authorized for dot tasks. The second Mac is intentionally reached through an existing SSH setup.
cloud_threads.read with limit=1 rejected two existing operations threads before returning content: one with unsupported placement format version 3, the other with unsupported placement format version 2. Both returned error_code=UNKNOWN.
cloud_threads.send_message to those IDs returned CloudThreadNotFoundError / NOT_FOUND.
Read/send operations to cloud product-owner tasks work. Messages originating from the existing local tasks also reach those cloud tasks. That reverse direction does not prove dot-to-local access works.
The dot's available controls have no native local-thread reader/sender or host selector. The exact installed desktop build has not been collected in this diagnostic session.

The local threads still work when I interact with them directly, but I have to copy instructions between chats. This makes an otherwise ordinary cloud-development/local-build workflow unreliable. Please identify the supported recovery or compatible release that preserves the original threads and history. Related macOS report: #52247.

Private thread IDs, environment IDs, repository details and conversation contents are omitted. I can provide identifiers through private support. These observations do not establish the internal root cause.

Navigation Menu

Repository navigation

dot cannot read user-created Codex threads: “unsupported placement format version” / “unsupported placement region” #52873

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

WORKING SOLUTION*

Here is a prompt to give your DOT to get up and running quickly!

Reusable prompt for testing the local Codex workaround

Paste this into your dot/Jim conversation and replace the bracketed values:

已核對的桌面版本

同一原始 ID 的對照與重測

診斷界線與請求

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

dot cannot read user-created Codex threads: “unsupported placement format version” / “unsupported placement region” #52873

Description

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Oct 10, 2026

OKhan99 commented on Oct 10, 2026

cyscott commented on Oct 11, 2026

btheorystartups commented on Oct 12, 2026

diego4-2 commented on Oct 12, 2026

dansesmacabres commented on Oct 12, 2026

wmy5555 commented on Oct 13, 2026

infrazenithtech commented on Oct 13, 2026

WORKING SOLUTION*

Here is a prompt to give your DOT to get up and running quickly!

Reusable prompt for testing the local Codex workaround

Paste this into your dot/Jim conversation and replace the bracketed values:

EmilioEsposito commented on Oct 14, 2026

synthaxxx333 commented on Oct 15, 2026

wmy5555 commented on Oct 17, 2026

matthabermehl commented on Oct 17, 2026

SatireLord commented on Oct 17, 2026

tw0928796891-cmd commented on Oct 17, 2026

已核對的桌面版本

同一原始 ID 的對照與重測

診斷界線與請求

todd866 commented on Oct 18, 2026

jiang401253851-lab commented on Oct 18, 2026

BsnizND commented on Oct 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions