Repository navigation
macOS dot: local thread read rejects placement format v1 and delegated task loses native thread tools #50077
Description
Summary
A reproducible local-task coordination failure in ChatGPT desktop/Codex: a dot cannot read an explicitly tagged local thread even though the user can open and interact with that same thread. The cloud task reader returns unsupported placement format version 1. A delegated local task also no longer exposes its previously usable local thread list/read/send tools.
Related reports: #49729 and #49997 describe the placement error; #49862 describes missing native thread controls on Windows. This report supplies a macOS reproduction with both observed symptoms. Their causal relationship is not established; please consolidate if appropriate.
Environment
- ChatGPT desktop app, bundle
com.openai.codex: version 26.928.21956, build 12404 - macOS 26.5.2, build 25F84, Apple Silicon
- Separately installed CLI: 0.154.0 (not asserted to be the app's bundled runtime)
- Computer reported connected, attached, and authorized for dot tasks
- Observed October 1, 2026; repeated exact-ID reads at approximately 19:04 and 19:06 UTC
Reproduction
- Connect the Mac to a dot and keep the desktop app running.
- Open a local project thread and interact with it directly.
- Tag that thread in the dot conversation, providing its exact local thread reference.
- Ask the dot to read or investigate the identified thread.
- Retry after interacting with the same local thread again.
Actual result
Both dot-side reads fail before returning thread contents:
AppServerBackendRequestError: Client specified an invalid argument:
post-cutover thread ID [REDACTED] has unsupported placement format version 1
error_code: UNKNOWN
The user's direct interaction with the local thread still works. A read of an earlier dot-created coordination task succeeds, so this is not a blanket failure of every task-read operation.
In that delegated local task, the native local thread read/list/send methods had worked earlier in the same day. Later checks found them absent from the exposed tool catalog, and the native read method was undefined. Filesystem access still worked. No fallback message reached the target local thread, and it was not restarted or modified.
Read-only checks
- User configuration parses successfully.
- The relevant bundled app-tools integration is enabled and the project is trusted.
- No project-specific configuration override was found.
- No configuration change has been established as the cause; configuration was left unchanged.
- Reconnecting through an explicit thread tag and retrying after a fresh user interaction did not clear the placement error.
Expected result
A dot should be able to access an explicitly identified local task through the supported route on an authorized connected computer, or return an actionable supported compatibility/permission requirement. The local execution task should expose supported task controls consistently when that capability is enabled.
Please investigate the local-thread placement/routing compatibility and native tool exposure. A server/client compatibility issue is a hypothesis, not a confirmed diagnosis. No service-wide outage is claimed.
Privacy
This public report omits account email, actual thread/project identifiers, local filesystem paths, raw configuration, logs, screenshots, secrets, and conversation contents. Exact identifiers can be supplied privately through a supported diagnostic channel if needed.
Activity
github-actions commentedon Oct 1, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
wilksys commentedon Oct 2, 2026
I’m seeing this across all my existing project chats on macOS: dot cannot access them, although I can use them directly. My computer has been connected and authorized for dot tasks. My other Advisor/voice coordinator chat can access the same chats without this problem.
Specific tested examples return “unsupported placement format version 2” and “unsupported placement format version 3” on direct reads by dot. A newly created test chat also failed with a placement error. Direct messaging attempts previously returned CloudThreadNotFoundError.
The latest app update and restart on October 2 did not resolve it. Is there a supported recovery step, or does this require a product-side fix?
jinho950920-ctrl commentedon Oct 2, 2026
Removed by author.
app351515-cyber commentedon Oct 2, 2026
Adding another Windows reproduction, observed on October 2, 2026.
A normal project conversation that I created in the Codex desktop app works when I use it directly. When I ask dot to read that same existing conversation, the read fails with:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [REDACTED] has unsupported placement format version 1
This prevents me from using dot to review and supervise the existing project conversation. Ordinary project conversations and unrelated tasks still work.
There is also a separate follow-up problem with dot-created desktop tasks: sending a message directly from the desktop app fails with:
invalid turn/start params: AbsolutePathBuf deserialized without a base path
That second error occurs in both an existing dot-created task and a freshly created diagnostic task. Sending instructions to those same tasks through dot can still execute successfully. I have not established whether the two errors share a cause.
The exact desktop app version/build has not been verified for this reproduction. Thread IDs, project names, and local paths are omitted.
Is there a verified workaround for accessing existing project conversations through dot? Please let me know which diagnostics would help investigate these failures, and whether the AbsolutePathBuf symptom should be tracked separately.
notpaulb commentedon Oct 2, 2026
Adding a follow-up from macOS on Codex 26.930.21537 (build 12776). My computer is connected and authorized for dot tasks. Restarting the app did not restore access.
These failures significantly limit my ability to use dot to coordinate existing project tasks and carry approved work through to completion. I’ve also submitted feedback privately.
Is this a known issue on this version, and is there a supported recovery procedure? Please advise whether the approval-relay symptom should be tracked separately.
hnic1130-jpg commentedon Oct 2, 2026
Adding a Windows reproduction with verified installed versions and a control read, observed on October 2, 2026 (including a read at approximately 21:01 UTC).
Environment:
Reproduction on the affected installation:
Sanitized error:
Additional read-only observations:
Expected: an authorized existing local thread should be readable through a supported route, or the read should return an actionable access/compatibility explanation.
This overlaps with the placement-version reports here and #50157. A routing compatibility issue is a hypothesis; the root cause and any relationship to missing native tools remain unconfirmed.
Project names, account identifiers, thread IDs, filesystem paths, conversation contents, and raw logs are omitted. No files are attached.
Frequency7032 commentedon Oct 5, 2026
Adding another macOS desktop observation, reproduced on 5 October 2026. Reads of existing Codex chats through dot fail with:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [redacted] has unsupported placement format version 1Other affected chats report placement format versions 2 and 3. Reading a newer cloud task succeeds. A separately linked remote conversation returns
AppServerBackendRequestError: thread not found: [redacted].This prevents dot from checking the plans and current state of existing coordinating/implementation chats. Please clarify which existing tasks this read path supports and provide an actionable recovery or compatibility explanation rather than an opaque placement error.
The app version has not yet been collected. We have not established a common cause across the placement errors and the separate not-found result. Account details, task identifiers and conversation contents are omitted.
app351515-cyber commentedon Oct 5, 2026
Update to my earlier Windows report: #50077 (comment)
I retested the original affected PC on October 6, 2026, at approximately 08:19–08:22 JST (October 5, 23:19–23:22 UTC).
dot successfully created a new work chat, and both the initial message and one follow-up received acknowledgments. An older dot-created work chat also acknowledged a new message.
However, reading an existing ordinary project chat through dot still fails with:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [REDACTED] has unsupported placement format version 1
error_code: UNKNOWN
The successful messages were sent through dot. Direct messaging from the desktop app was not retested, so recovery of the separate “AbsolutePathBuf deserialized without a base path” error has not been established.
This is a limited partial recovery; the cause is unknown. The existing-project read problem remains unresolved. Is there a supported diagnostic or recovery step for that remaining failure?
Kohei25-gif commentedon Oct 6, 2026
Adding a macOS reproduction from October 6, 2026 (all times UTC).
The current desktop app version/build has not been verified for this reproduction. A direct-read repair has not been established, and the relationship between the placement error and tool availability remains unconfirmed.
Could maintainers provide a supported route for dot to read an existing local thread directly, or advise on a compatibility fix? Relaying content through another task would not meet the goal of direct access to the existing thread.
Actual thread identifiers, account details, device names, filesystem paths, conversation contents, and raw logs are omitted.
omarpinarecords commentedon Oct 7, 2026
Additional October 7 macOS corroboration: dot-side reading of an explicitly identified existing Local Codex task failed with unsupported placement format version 2 despite connected/authorized computer status. This does not establish that Local execution failed or independently reproduce every native-tool disappearance described here.
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.
JobAnyol commentedon Oct 8, 2026
I can reproduce the same direct-read error on macOS, observed on October 8, 2026.
My Mac was connected and authorized for dot tasks. When my dot tried to read a specifically identified existing local Codex conversation, it returned:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [REDACTED] has unsupported placement format version 1
For comparison, a separate task running on the same Mac successfully listed the local conversations and read all five turns of that exact conversation through the native local-thread API. The conversation itself was therefore readable through that local route.
The native local-thread list/read/send functions were not available in the parent dot's inspected tool context. This is an observation from this test, not a confirmed explanation for the error.
My goal is to let dot read an existing local conversation directly, without creating an intermediary task each time. The intermediary worked for retrieving the content, but did not resolve the direct-access problem.
The exact desktop app and macOS versions were not collected during this test. No settings changes or database modifications were made as part of the test. Private conversation contents, thread IDs, account details, and filesystem paths are omitted.
Is there a supported recovery step for direct access, or any additional sanitized diagnostic information that would help investigate this?
akonyer commentedon Oct 11, 2026
Adding a Windows + NixOS WSL3 reproduction: my dot agent is having trouble with session management/access, while the target Codex session itself runs normally.
Environment, checked October 11, 2026:
26.1007.2314.0.0.162.0-alpha.17.2.0.162.1. This version difference is diagnostic context, not an established cause.Observed behavior:
Additional read-only diagnostic results:
status.type = "notLoaded"and an emptyturnsarray. This did not establish successful access to the actual conversation history.This appears consistent with the local-versus-dot access distinction in this issue. The underlying cause, any relationship to the runtime versions, and any connection to WSL configuration remain unconfirmed.
No personal information, project details, filesystem paths, session IDs, account identifiers, or raw conversation contents are included.
BartoszOGS commentedon Oct 17, 2026
Dot rejects an original local Codex chat while native read/send/reply succeeds
Additional user-authorized reproduction, prepared with Codex assistance. Observed October 16, 2026, America/Chicago (October 17 UTC).
Problem
On an Apple Silicon Mac running macOS 27.0.1, the user asked Dot to read the title and latest assistant reply of an explicitly identified existing local Codex chat. Dot reported the correct computer connected and authorized, but cloud_threads.read returned no chat content:
The affected running desktop version is 26.1007.71326, build 20398. Build 20586 is staged for that account but has not been activated. A different account's build-20586 transport test does not establish a same-account reader retest on that version.
Controls
Separate transport symptom
All four isolated account apps on this Mac now exhibit repeated executor read-error disconnects after approximately five seconds. In a fresh complete four-minute comparison, the affected original-chat account recorded 37 disconnects with a median connected spell of 5.102 seconds. The user also supplied an Offline computer card after the earlier connected/authorized result. Older stable transport observations must not be taken as current stability. Native controls remain functional; the relationship between these transport failures and the placement rejection is unproven. No broad credential, registration or session-ID reset was performed.
An earlier bounded trace captured the underlying socket error: WebSocket protocol error: Connection reset without closing handshake. It establishes abnormal closure, not the terminating party. An independent live socket observation later confirmed a socket appearing and disappearing with the approximately five-second executor connect/read-error events while the executor process retained its original start.
Additional controls: the updated isolated pilot runs the newest production build offered to that installation (20586). Public unauthenticated WebSocket echo controls survived 35 seconds both idle and active (11/11 echoes). Host proxy/PAC and the macOS application firewall are disabled; no attributable network-denial rule was found in the inspected policy data. A prior opaque IPv4-only test on the actual pilot executor still reproduced resets. These controls do not rule out every endpoint-specific network, client or service cause.
Requested engineering diagnosis
Please identify the supported direct route for Dot to access this original local chat, including any client/version, account, placement or capability gate. If this rejection needs service-side correction, please provide a private diagnostic channel to correlate a fresh bounded attempt, identify the rejecting service/deployment and whether local-host dispatch occurred, and supply a correction preserving the original task identity/history.
Acceptance requires Dot retrieving actual content from this same original chat. A new helper task, a visible connection badge, or a native local success alone does not establish direct-reader recovery.
References
This draft omits emails, computer names, exact task/project/environment/account IDs, local paths, raw logs, credentials, screenshots and conversation content. Exact private identifiers have not been supplied publicly.
Additional controlled transport observations, October 17 UTC:
Please advise which private correlation channel or supported client diagnostics can provide the service-side close reason and reader-routing diagnostics without resetting identities or altering existing chats.