Repository navigation
Dot cannot read existing remote Codex sessions: unsupported placement format versions 1 and 2 #50157
Description
Summary
I asked my dot to read existing Codex sessions associated with a remote server. Reads of two explicitly supplied session IDs failed with the same error family, with placement format versions 2 and 1 respectively.
This looks related to #49729. This report adds a reproduction involving existing remote Codex sessions and both format versions.
Steps to reproduce
- Open a conversation with a dot (tested from the iOS app).
- Provide the ID of an existing remote Codex session and ask the dot to read it.
- Repeat with another session ID.
Actual results
First session, October 2, 2026 at approximately 03:12 UTC:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [redacted] has unsupported placement format version 2
Second session, October 2, 2026 at approximately 03:17 UTC:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [redacted] has unsupported placement format version 1
Neither read returned session contents. As a control, the dot successfully read a different account-level cloud conversation during the same interaction.
Expected result
The dot should be able to read an existing session that the account is authorized to access when given its exact ID, or return an actionable access/compatibility explanation.
Additional observations
The available-environments lookup returned empty lists. One attempt errored, then a retry again returned empty lists. It is unknown whether that is related to the thread-read failure. No claim is made that the remote server was offline or the sessions were corrupt.
The exact client and remote-server software versions were not collected. Session IDs, server name, and conversation contents are intentionally omitted from this public report.
User feedback: Dot cannot directly access existing Linux SSH conversations
- Source: GitHub #50157 · Linux SSH reproduction
- Type: external
- User reports:
- Linux desktop, October 16, 2026, approximately 00:09–00:22 UTC: Dot cannot directly read three existing SSH-hosted conversations that remain usable in Codex. Two return
unsupported placement format version 2; one returns version 1. - A separate direct send to the version-1 conversation returns
CloudThreadNotFoundError: The cloud thread was not found.No message was delivered. - The desktop is connected, attached and authorized for Dot, but the account-wide cloud listing omits the affected SSH conversations.
- A Dot-created desktop task can be read/messaged and previously accessed the SSH conversations through host-side tools. This relay does not restore direct access from the main Dot conversation and adds coordination friction.
- Client/server versions were not collected. Conversations remain usable; deletion, corruption and a common cause across these errors are not established.
- Linux desktop, October 16, 2026, approximately 00:09–00:22 UTC: Dot cannot directly read three existing SSH-hosted conversations that remain usable in Codex. Two return
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
Veggie95 commentedon Oct 2, 2026
I reproduced a related failure on Windows with an existing Local Codex chat on 2 October 2026, 21:54–21:55 KST (12:54–12:55 UTC).
Environment: installed Windows package
OpenAI.Codex 26.930.2377.0; internal app build26.930.21537.Steps:
Expected: Dot reads and continues the identified existing Local chat.
Actual:
cloud_threads.readfails. Dot reports:No messages were returned, and no message to the Local target was attempted.
Control: the supported Local Codex app tool
read_thread, usinghostId: local, successfully reads the SAME target. This does not establish Dot access.This adds a Windows Local version-3 reproduction to the version-1/2 reports here and the Local-chat report in #49729. The shared root cause is not confirmed. Could the Dot/Codex routing team check whether these belong to the same issue? This blocks Dot from reading and coordinating my existing Local work.
Update — October 4, 2026
Further testing on my connected Windows PC still hasn’t established working Dot-to-Local chat access. My About screen showed 26.930.31428, and I subsequently installed 26.930.31730; that later version is user-reported rather than independently verified by the diagnostic task.
The practical goal is for Dot to plan and coordinate work that Local Codex executes on my computer, and receive its results through a supported route. Continuing an existing Local chat is one option; delegating to a Codex task equipped with official local Chrome/browser or desktop controls could also meet that need. Please identify which routes are supported today and the supported next steps for the routing and tool-availability failures separately. I am not assuming a shared cause or that PR #50129 resolves either.
lucilacoelhonegocios-boop commentedon Oct 3, 2026
Additional report from Windows, involving LOCAL Codex threads rather than the remote/iOS setup in the original issue.
Tested October 2 with Windows package 26.930.2377.0 and internal app version 26.930.21537:
cloud_threads.readcall returnedunsupported placement format version 1.read_threadtool with the local host can read those same threads.A separate launcher workaround associated with #49820 was tested and fully reverted after a fresh Dot task still lacked the native local chat-reading tools. I am not asserting that the placement-format error, tool startup failures, and the original remote reproduction share one cause.
The case has been escalated to official support. Is there a supported route for Dot to resolve/read local Codex thread identifiers, and a confirmed version or deployment addressing this format error?
siglr commentedon Oct 3, 2026
I saw the same error family on September 30 with existing, independently created local Codex threads on Windows. When I gave dot known thread IDs and asked it to read them, it returned "unsupported placement region 8" and "unsupported placement format version 2". Reading dot-created child tasks and retrieving their results still worked.
My case involves local Windows threads; the original report involves remote-server sessions. I don't know whether they share a root cause. These errors were observed before my October 1 app update, so this is not a claim that I reproduced them after that update. I've omitted private thread IDs and logs.
quiet-cedar-482 commentedon Oct 3, 2026
Dot returned the exact error
unsupported placement format version 2when accessing a cloud chat that Dot itself created.I use the Windows Codex desktop app. On this same cloud chat, I also often cannot send a simple desktop follow-up, although Dot has been able to communicate with it at other times. I’m reporting both observations without assuming a shared cause.
I observed the failures on October 2, 2026, from 4 p.m. Pacific time (PDT) onward. They continue on October 3 with Codex app version 26.930.31730, build 12947.
This makes continuing the existing conversation unreliable. Please let me know which additional details or simple diagnostic would help.
ivg-design commentedon Oct 3, 2026
Additional macOS local-session reproduction, October 3, 2026.
A Dot was explicitly authorized to access an existing local Codex implementation session by its exact ID. A fresh direct cloud_threads.read check returns:
No session contents were returned. This check was read-only; no message was sent to the target and no project work was resumed.
Earlier checks in the same investigation successfully read a Dot-created coordination task, while an account-wide listing omitted the affected existing session. A local helper previously read the affected session successfully; that control was not repeated in this latest cloud-only check.
Expected: Dot can resolve and read an owner-authorized existing local Codex session. Actual: the direct cloud reader rejects its placement format. This adds a macOS local-session case; a common root cause with the remote and Windows reports is not established. The desktop build has not been independently verified for this report.
Is there a supported existing-session routing workaround or a confirmed deployment fixing placement-format-v2 reads? Private thread IDs and session contents are omitted.
tantalum666 commentedon Oct 4, 2026
I’m also seeing “unsupported placement region 9” when asking dot from iOS to read an existing Codex session originally created on my Mac. It reproduced on October 3 and October 4, 2026. A different, newly dot-created Mac task was readable on October 2. Is there a supported workaround or confirmed fix?
Tocktock commentedon Oct 5, 2026
Additional macOS reproduction, October 5, 2026 (UTC), with a successful relay control after a user-reported restart.
The Mac was reported connected, attached, and authorized for dot tasks. Exact-ID
cloud_threads.readcalls against two existing local implementation threads returned no conversation contents:AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [redacted] has unsupported placement format version 2AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [redacted] has unsupported placement region 12error_code: UNKNOWN.At approximately 01:20 UTC, a read of A failed with the same version-2 error in about 318 ms, while the same tool successfully read an existing dot-created coordination task in about 1.14 s. These timings do not establish which internal stage failed.
After the user reported restarting the local machine, at approximately 01:50 UTC the environment again showed connected/attached/authorized. Direct reads still returned the two errors above. Before that restart, B had returned a timeout; this is a separate observation, not proof of a shared cause.
A useful control: the existing coordination task then relayed a unique, harmless check message to A, and at approximately 01:55 UTC A sent an explicit report back confirming receipt of that marker. No code change or model call was requested for the check. Thus the relay round trip worked while the direct cloud reader still failed in the latest check. Earlier attempts in that same coordination task had reported that local thread read/send tools were absent; their later recovery is an observation, not proof that restart fixes tool exposure or the direct-reader error.
Expected: supported direct resolution of an owner-authorized existing local thread, or actionable compatibility guidance. Could the routing team investigate the placement-format-v2 and placement-region-12 failures and clarify the supported path? I am not asserting a permissions problem, corrupt conversation, or a confirmed common cause with all reports here.
The application build was not independently captured. Private thread IDs, hostnames, project names, filesystem paths, conversation contents, and credentials are omitted.
Maybewuss commentedon Oct 10, 2026
I am seeing the same error when my dot tries to read an existing remote Codex conversation:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [redacted] has unsupported placement format version 2My main workflow is the Mac Codex desktop client connected to remote machines over SSH. The dot-side read was retried on October 8 and still returned no conversation contents. Its environment lookup listed my connected, authorized Mac but did not list the SSH server as a separate environment. I have not collected the relevant client/server versions, so I cannot identify the root cause.
The core request is broader than reading history: I want dot to be able to work with my SSH machines alongside my Mac, with explicit authorization. That should include reading and continuing existing remote tasks, coordinating work on those machines, and giving me a consolidated view of progress and blockers across the machines I authorize. Most of my work happens over SSH, so without that context dot misses my main work and I have to relay it manually.
Could the team clarify which dot-to-SSH workflows are supported today, whether this placement-format error is a known limitation or bug, and the supported path for enabling this? A clear per-machine/project authorization flow would be useful. I am not asking to bypass existing permissions.
Server addresses, session IDs, and conversation contents are omitted.
lnsflive commentedon Oct 16, 2026
Adding another reproduction from a Linux desktop with existing SSH-hosted Codex conversations, checked October 16, 2026 at approximately 00:09–00:22 UTC.
My dot cannot directly read three existing conversations that I can still open and use in Codex:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [redacted] has unsupported placement format version 2.unsupported placement format version 1.cloud_threads.send_messageattempt to the version-1 conversation returnedCloudThreadNotFoundError: The cloud thread was not found.No message was delivered through that attempt.The desktop was listed as connected, attached, and authorized for dot tasks. An account-wide cloud thread listing omitted the affected SSH conversations. The current client and remote app-server versions were not independently collected.
As a control, the dot can read and message an existing dot-created task on the connected desktop. That task previously accessed the SSH-hosted conversations through the desktop's host-side tools and coordinated work successfully. This does not fix direct access from the main dot conversation, and the extra coordination task adds friction to the workflow.
The goal is to have my dot coordinate my existing worker, reviewer, and logging conversations, including scoped artifact handoffs, without manually copying responses between them. The conversations themselves remain usable; I have no evidence that they are deleted or corrupt. I also cannot establish whether all these errors share one underlying cause.
Is there a confirmed fix or supported way for the main dot conversation to read and continue existing SSH-hosted threads directly? Private thread IDs, hostnames, paths, conversation contents, and project artifacts are omitted.
dram-solutions commentedon Oct 18, 2026
Also having the same issue on linux dot cannot continue a remote session that I launch even though its on the same server through the ChatGPT desktop client.
iHateThisGameSo commentedon Oct 18, 2026
Adding a Linux local-session case with a longer troubleshooting history. This is not a new problem as of today: our conversation records document coordination failures since at least October 7, 2026, plus a related missing-tools problem on October 6.
Timeline (UTC):
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [redacted] has unsupported placement format version 1
No conversation contents were returned. The acknowledgment was conditional on successful reading, so none was sent.
The chronology includes different coordinator sessions over time. We are not claiming that every error came from one unchanged ID, or that the older reports and latest reproduction have a confirmed common cause. Client/app-server build versions were not collected.
This prevents dot from coordinating existing local worker/coordinator conversations without manual copying or an extra relay. Could the team clarify the supported direct route, any confirmed fix/deployment for placement resolution, and the separate availability of native local-thread tools in delegated tasks?
Private session IDs, hostnames, filesystem paths, conversation contents, and credentials are omitted.
iHateThisGameSo commentedon Oct 18, 2026
Controlled Linux diagnostic follow-up — October 18, 2026
Posted by the Codex investigating agent with the account owner’s explicit authorization.
Follow-up to our Linux report, with a controlled October 18, 2026 diagnostic. Private session IDs, hostnames, account identifiers, paths, conversation contents, credentials and raw logs are omitted.
Environment observed directly: Ubuntu 24.04.5 LTS, x86_64; desktop package 26.1007.71326, build 20398, installed channel prod. The live desktop app-server executable reports 0.162.0-alpha.17.2. The separately installed primary CLI reports 0.163.0; an additional npm installation reports 0.147.0 and was not used for task execution. No software was updated.
The main dot reported its connected computer as connected, attached and authorized throughout the tests. We independently verified the official dot profile/channel. The dot exposes cloud_threads read/create/send/list operations, but not the desktop's hostId-aware read_thread operation.
A task-origin reference returned metadata and zero turns when read locally. We did not treat that empty result as a validated dot recipient and did not send to it. Independent task-initiated messaging to the correct dot conversation remains unverified.
An existing authorized desktop SSH connection also made a remote conversation discoverable/readable through native host-aware tools and the dot-created executor, while that remote host remained absent from the main dot's environment listing. The remote target was active, so no message was sent. We treat these discovery surfaces as distinct capabilities, not proof of an authentication failure.
Account security was investigated without weakening it. Notification metadata places security-key/passkey additions, Daybreak Blue onboarding, Advanced Account Security enablement and an MFA change on September 30. These predate our reported failures but do not establish causality. No authentication files were read or copied, and no additional-authentication error was observed in the bounded account-read probes. We did not test a security-mode change.
No service, hook, production coordinator, relay, security setting, database or UUID was reset or changed. Existing conversations were preserved; only bounded diagnostic turns were added. A normal desktop restart at the same version was reported by the owner and corroborated by replacement processes. Direct reads retained the same placement errors. The two local diagnostic targets initially returned notLoaded, so the executors correctly skipped the conditional sends. Opening each existing conversation through the native application navigation changed its observed state to idle. After that, both distinct indirect circuits completed again, with one native send each, correct delegation sources, distinct nonces and preserved context markers. The main dot reread both results. Reopening still did not repair direct reads. We did not test sending to notLoaded targets, so we do not claim it is unsupported or impossible. Independent reverse initiation and project association remain open; no route is being presented as meeting all acceptance criteria.
Could the routing/tooling team clarify the supported direct path for eligible existing local references, the separate provisioning of native tools in older versus fresh delegated tasks, projectId preservation, and the supported endpoint for executor-initiated messages to the parent dot? We can rerun bounded nonce tests through a supported diagnostic channel without exposing private identifiers publicly.