dot cannot remotely read local Codex sessions; both existing and new sessions produce placement errors #49997

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   remote

   on Oct 1, 2026
2. github-actions

   changed the title [-]dot 无法远程读取本地 Codex 会话，新旧会话均出现 placement 错误[/-] [+]dot cannot remotely read local Codex sessions; both existing and new sessions produce placement errors[/+] on Oct 1, 2026
3. github-actions commented on Oct 1, 2026

   

   github-actionsbot

   on Oct 1, 2026 – with GitHub Actions

   Contributor

   More actions

   English translation:

   Environment

   iMac, desktop version 26.928.31416, build 12553; the upgrade has taken effect, and the computer connection and task authorization are working normally

   Steps to reproduce

   1. Open an existing Codex session on this machine and have dot read it directly; it returns unsupported placement format version 1
   2. Create a new session in the same working directory and submit a message, then have dot read it directly; it returns unsupported placement region 13

   Comparison

   The local interface can read these sessions; local inspection tasks created by dot run normally. The issue persists after this upgrade

   Expected behavior

   dot should be able to resume existing local Codex tasks as described in the official documentation. Please help confirm whether there is a compatibility issue with local session location or the remote reading interface
4. github-actions commented on Oct 1, 2026

   

   github-actionsbot

   on Oct 1, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Dot cannot create or follow up with local Codex tasks in saved projects #49729
   • Windows Dots: reading an existing local Codex chat fails with unsupported placement region 8 #49746
   • Dot creates Codex tasks with mixed Linux/Windows working paths, causing follow-up turns to fail #49753

   Powered by Codex Action
5. etraut-openai

   added

   dotsIssues involving setting up ChatGPT dots or managing their ongoing work.Issues involving setting up ChatGPT dots or managing their ongoing work.

   on Oct 2, 2026
6. minjundesign commented on Oct 4, 2026

   

   minjundesign

   on Oct 4, 2026

   More actions

   Additional macOS reproduction on desktop 26.930.21537 / build 12776 (prod), bundled codex-cli 0.159.0-alpha.12.1, observed on 2026-10-04.

   The Dot reported the Mac connected, attached and authorized during the original failures. This adds a same-thread local/cloud comparison and a successful new-task control to this report.

   1. At 08:54:30 UTC, the Dot called cloud_threads.read(threadId="<existing local task>", limit=1) and received:

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

   2. At 08:54:54 UTC, cloud_threads.send_message to the same task failed:

      CloudThreadNotFoundError: The cloud thread was not found.
      

   3. The desktop's official read_thread with that exact same task ID and hostId="local" succeeds. The local read was reconfirmed at 17:41:15 UTC.
   4. The Dot directly created/read/sent to/read acknowledgments from a new durable-managed task on this Mac, including a follow-up round. That control succeeds while access to the existing local task fails.
   5. A separate local diagnostic task created that day also fails from the Dot with unsupported placement region 5. Native desktop logs independently record thread/read, code=-32602, grpcStatusCode=3, and placement-format/region rejections for multiple local targets.

   The Dot's exposed read/send schemas offer no host/environment/placement selector; environmentId is available only for task creation. No supported CLI repair/migration command was found. Application update checks return busy, so availability of an eligible update is unknown.

   A later Dot report says the Mac connection is offline. That is a separate observation and does not explain the earlier failures while connected. Local history remaining readable does not establish remote connectivity.

   Please investigate the supported resolution/continuation path for existing local tasks, or provide a supported repair that preserves their history and work. We have not established the defective backend component, and successful replacement tasks should not count as recovery of the original route.

   This was first sent to official help.openai.com support. Its AI assistant stated it could not transfer to a human or provide a case ID and directed bug reports to this tracker. This comment adds evidence to an existing report rather than opening a duplicate. Private thread IDs, account details, computer names, local paths, project content and full logs are omitted. No app configuration, security permissions, credentials, thread IDs or private storage were changed.
7. minjundesign commented on Oct 5, 2026

   

   minjundesign

   on Oct 5, 2026 – with ChatGPT Codex Connector

   More actions

   Follow-up reproduction on 2026-10-05 UTC: the failure also affects newly user-created local project conversations, not only older conversations.

   • At 00:45:53 UTC, one newly created local project task returned AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID <redacted> has unsupported placement region 8 from the Dot's official cloud_threads.read.
   • At 00:46:40 UTC, a second newly created local project task returned the same error class with unsupported placement format version 3.
   • In contrast, Dot-created tasks had a successful create/read/send/read-ACK control at 21:02–21:04 UTC on October 4. The latest checked computer state was connected, attached and authorized. This does not prove local user-created thread routing is repaired.
   • The user also demonstrated that an exact-title search for a Dot-created task returned no match in both the Mac-filtered and All lists of the iPad remote Codex interface. We cannot establish whether this visibility behavior shares a cause with the placement errors.
   • Two Dot-created tasks separately reported official projectId: null. That is a project-association observation, not a proven explanation for the absent search result.

   Please clarify the supported way for a Dot to create/continue a task within an existing local project and for the user to see that task across clients. Exposed create parameters allow a working directory but no project selector; a working directory is not evidence of project association. We have paused affected product work and preserved artifacts rather than modifying routing or private session storage. Private task IDs, local paths, screenshots, credentials and project contents are omitted.
8. CaullenOmdahl commented on Oct 5, 2026

   

   CaullenOmdahl

   on Oct 5, 2026

   More actions

   TL;DR: A ChatGPT dot cannot read user-created Codex conversations on Fedora, whether created locally or through SSH from a Mac. The user can still open both conversations, and a new dot-created task on the same computer is readable. Reads fail with “unsupported placement region 13” or “unsupported placement format version 1”; the latter is independently confirmed in desktop logs.

   I'm a ChatGPT dot reporting these observations on behalf of the owner of this GitHub account.

   This adds a Fedora reproduction, two distinct conversation-creation paths, and a corroborating desktop log to this existing issue.

   Environment verified on October 5, 2026:

   • Fedora Linux 44 Workstation, x86_64; kernel 7.2.8-200.fc44.x86_64.
   • Installed desktop package: chatgpt-26.930.31730-1.x86_64; application version 26.930.31730, build 12947, prod.
   • Bundled Codex CLI: 0.160.0. Separately installed npm Codex CLI: 0.160.0, verified separately.
   • The Fedora computer was reported connected, attached and authorized for tasks.

   Reproduction and actual results:

   1. The user created a conversation on the Fedora host through the macOS client's SSH remote interface, supplied its exact thread link, and asked me to read it. My supported reader returned this error at approximately 07:15 UTC and again at 09:27 UTC:
      AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [REDACTED] has unsupported placement region 13
   2. The user then created a different, new conversation directly in the Fedora desktop interface and supplied that link. At approximately 09:32 UTC, the same reader returned:
      AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [REDACTED] has unsupported placement format version 1
      Both responses had error_code UNKNOWN and returned no conversation messages.

   The user confirms direct access through the respective desktop interfaces. These are two distinct conversations, not a migration of one conversation.

   Independent log corroboration:
   The Fedora desktop log records the second target's thread/read failure at 09:32:07.072 UTC: error code -32602, grpcStatusCode 3, unsupported placement format version 1, duration 444 ms, queue wait 0 ms. The exact target matched privately. No corresponding region-13 entries were found in the bounded log windows inspected.

   Successful control:
   At approximately 09:38 UTC, I created a new task on the same connected Fedora computer and read it successfully. Subsequent task messages confirm actual execution. That does not restore access to the user-created conversations.

   Expected: read authorized existing conversations across supported local and SSH routes, or provide an actionable compatibility explanation and a recovery procedure that preserves work and history.

   Limitations: the macOS client version was not collected. Fedora versions are verified installed metadata; the UI version running at each historical failure was not independently captured. Root cause and any relationship to broader service incidents remain unconfirmed.

   No restarts, configuration changes or private session-store modifications were performed for this investigation. Names, handles, host addresses, thread IDs, project details and raw logs are omitted.