Repository navigation
Dots existing Local-task access: placement-format errors versus documented continuation and recovery #51722
Description
Summary
Dots' documented support for continuing existing Local Codex tasks conflicts with placement-format failures reported by multiple users. Please clarify the compatibility and recovery contract and connect the documentation to the existing reports below.
This issue consolidates the documentation/support-matrix gap. It does not assert a new root cause or that all Local tasks are inaccessible.
Reproduction and observed result
Observed on October 7, 2026:
- A Mac was connected and authorized for dot access.
- The user explicitly identified an existing user-created, projectless Local Codex task.
- The dot called
cloud_threads.readfor that task. - The operation returned:
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [REDACTED] has unsupported placement format version 2 - No task content was returned. Reads of other existing Local tasks had returned placement-format version 3.
The desktop app had been updated, but its new installed/running build was not independently verified. This report therefore does not attribute the failure to a specific current build. A reader error does not establish that execution of the Local task failed.
Documentation versus observed behavior
Official pages checked October 7, 2026:
- Tasks and memory explicitly describes continuing an existing Local Codex task on a connected computer after identifying the task and requested change.
- Computers and apps describes creating Local Work/Codex tasks and continuing existing Local Codex tasks.
- Meet dots describes Local work and task follow-up, while qualifying access to prior conversations.
The documented connectivity, permission, availability and conversation-access boundaries matter. The gap is an explicitly identified task being rejected by a placement-format parser without an actionable explanation of eligibility or recovery.
Please distinguish:
- Existing Local Codex versus existing Local Work tasks. Documentation is more explicit about the former.
- User-created versus dot-created tasks.
- Project versus projectless tasks.
- Creating a task versus reading or continuing the original existing task.
- Mac connectivity versus compatibility of the task's placement format.
News and documentation consistency
Introducing dots uses broad cross-channel context and connected-computer language. The DevDay 2026 recap describes ongoing agent work with availability qualifications. Detailed documentation adds narrower context/access boundaries.
This is a wording and discoverability tension, not proof of a promise to read every prior conversation. Please make the existing-task compatibility limits visible alongside the broad capabilities, rather than leaving users to infer them from unexplained errors.
Related open reports
- Dot cannot read an existing local Work thread: unsupported placement format version 2 #50698: existing Local Work read rejected with placement format version 2; closest exact error match.
- Dot cannot create or follow up with local Codex tasks in saved projects #49729: known-ID Local project task read/message interoperability failures.
- Dot cannot resume existing Windows Codex tasks: placement formats 3 and 2; local controls work in desktop #50440: placement-format versions 2 and 3, including a desktop-versus-dot distinction.
- macOS dot: local thread read rejects placement format v1 and delegated task loses native thread tools #50077: macOS placement failure and separately reported missing native thread tools.
These were open when checked. Their common root cause, if any, remains unconfirmed; no maintainer-confirmed direct-access fix was found in the inspected discussions.
Separate incident and workaround limits
The October 7 resolved incident concerns creation of new Work threads. It does not by itself verify recovery of dot-side reads of existing Local tasks.
A new intermediary/helper task is not equivalent to restoring direct access to the original task and is unsuitable when the user's required workflow is direct Local task interaction. Please document a supported path that preserves the existing task.
Requested resolution
- Publish an explicit support matrix for existing task types, origins and placement/client versions.
- Return an actionable compatibility/eligibility error.
- Provide direct recovery that preserves task identity and history.
- Link documentation to the correct tracking issue and consolidate related bugs if appropriate.
- Verify reading the original affected task and, when authorized, sending a follow-up to that same task. Successful new-task creation or a working desktop UI alone is insufficient.
Feedback reference
A sanitized report was submitted through the web “Report a bug” form on October 7 at approximately 15:23 UTC. The form closed, but no feedback ID or retained success confirmation was exposed. No feedback ID is claimed; this field can be updated if a verified receipt becomes available.
Privacy
No private task IDs, account identifiers, local paths, conversation contents, screenshots, diagnostic logs, credentials or private project information are included.
Activity
github-actions commentedon Oct 7, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
omarpinarecords commentedon Oct 7, 2026
Reviewed the suggested reports #50698, #50780 and #50704 and their current discussion histories. They overlap with the observed existing-task placement/access failures: #50698 covers an existing Local Work read; #50780 combines existing Local reads with task-creation failures; #50704 adds native-versus-cloud controls and capability exposure.
This report's requested deliverable is the documentation/support matrix and an actionable recovery contract for existing task types and origins. It does not assert a separate underlying defect or ask for duplicate implementation work. Please consolidate implementation tracking where appropriate while retaining these documentation and existing-task recovery acceptance requirements. Successful new-task creation does not verify a read of the original affected task.
omarpinarecords commentedon Oct 7, 2026
Additional observation from October 7, 2026, recorded at approximately 15:42 UTC: my dot attempted to read two existing Local tasks I had identified. One read returned “unsupported placement format version 2”; the other returned “unsupported placement region 14”. The region-14 error blocked the dot's access to that task's conversation.
This adds the region-14 variant to this report. Another user reported the same error in #50704 (comment). A shared cause has not been established, and the read failure does not establish that Local task execution failed.
williamsdigitalservices-sys commentedon Oct 8, 2026
I’m also affected on Windows 11 Pro 25H2, build 26200.9457, using Codex 26.1002.52244. My desktop-created task successfully writes/reads files and uses Chrome and the in-app browser. However, dot cannot read it (“unsupported placement format version 3”) or send instructions (“CloudThreadNotFoundError”).
Feedback ID: 01a1192c-c39a-71f1-9e5e-fa2fea551f38
omarpinarecords commentedon Oct 8, 2026
October 8 bounded existing-original read test and verified feedback receipt
Account plan: ChatGPT Pro 20x. Current macOS 27.0.1; desktop app 26.1002.52244, build 13536, prod channel. The app's native update check earlier today reported up_to_date. These measurements apply to today's test, not retroactively to the October 7 observations.
At approximately 13:11 UTC on October 8, one authorized diagnostic was performed in the existing parent dot. Its visible completed response reported:
mcp__codex_app__list_threads,mcp__codex_app__read_thread, andmcp__codex_app__send_message_to_threadnames were absent from its catalog andundefinedas direct tools. The send tool was not invoked, and no general loader exposing those names was available.connected,attached=true, andis_authorized_for_tasks=true, separately from the dot's own cloud computer.tools.mcp__codex_apps__cloud_threads_read, withthreadId,limit, andcursorin the reported schema; there was no host/environment selector. Each original was attempted once withlimit=3.No conversation content, title, or summary was returned. Errors were
AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [REDACTED] has unsupported placement format version [1 or 2], withisError=true,error_code=UNKNOWN, and no request IDs reported.Evidence boundary: these dot-side details come from its visible diagnostic response; the Local investigator did not independently inspect raw dot tool traces. Earlier native
mcp__codex_app__read_threadcalls from the Local investigator returned turns/items for the same four originals. That is a working comparison route, not direct-dot recovery. Recovery in the dot is 0/4.The #49482 conditional native-route check was performed, but that route was not exposed in this dot session. #49925 remains the related native-tool exposure scope; #50698 covers the Local version-2 rejection; #51880 reports the same macOS app version. A common root cause is not established. No unchanged retries, new helpers, replacement tasks, history migration, restart, permission change, task interruption, or model/effort change occurred.
Please clarify the supported reader/routing contract and compatibility matrix for identified existing originals across Local project, Local projectless, and Cloud placement versions, and provide recovery that preserves their identities and histories. Closure requires actual content retrieval from the original affected surface. Local caller success and new-task creation alone do not meet that criterion.
New feedback receipt:
no-active-thread-01a11bb8-4bb0-7311-897c-bb9ff9a30865, submitted and verified October 8 at 13:33:47 UTC through the documented Codex App Serverfeedback/uploadAPI. This is a new follow-up for today's test; it does not establish delivery of the uncertain October 7 web-form attempt.includeLogs=false,extraLogFiles=null,threadId=null; no attachments, screenshots, traces, logs, private task identifiers, host/environment identifiers, local paths, or conversation/legal content were sent.omarpinarecords commentedon Oct 11, 2026
October 11, 2026 — updated desktop baseline; original dot recovery still unproved
A current Local update audit establishes production desktop 26.1007.30912 / build 20156, bundled engine 0.162.0-alpha.17.2, and workspace dependencies 26.1009.11318. The maintained desktop update check reports
up_to_date. These are installation observations, not a fresh reproduction of the original dot errors.The October 9 Dots update describes broader context, browsing/networking, navigation and recovery improvements. It does not by itself establish that the placement-format reads on the four original objects in my October 8 comment now succeed. That 0/4 recovery result remains the last affected-surface test; the originals were not retested in this audit, and no replacement conversation or indirect Cloud/Local bridge was created.
Please identify the supported access correction, applicable version/rollout and the original-object retest route. Direct Local capabilities and successful browser operations do not certify dot reader recovery. Keep read access, continuation dispatch, delivery and creation-placement acceptance separate. No closure or shared cause is claimed from the newer desktop build or announcement.
Prepared with Codex assistance at the affected user’s explicit request. No attachments, screenshots, raw logs, transcripts, credentials, private task identifiers, or local paths are included.
omarpinarecords commentedon Oct 16, 2026
October 16 recurrence on the current macOS desktop
Desktop baseline: 26.1013.31256 / build 20586, macOS 27.0.1 arm64. This identifies the desktop client, not the reader backend version.
At 11:53:33–11:53:34 UTC, the coordinating dot made one owner-authorized cloud_threads.read call for an explicitly identified existing native Local task (limit 10). It returned no task content:
The exact same original was subsequently readable through the supported native read_thread route, returning current content and ongoing work. This is a working comparison route, not recovery of the dot's failing reader, and the placement rejection does not mean the original task stopped or lost work. The failed dot call was not repeated.
A desktop capture includes the reported interval, but its full-buffer/import diagnostics and lack of a request-linked placement-error event do not expose the backend's rejection path. No causal connection to separate desktop room/history refresh errors or attachment delay is established.
Please provide the supported placement-version compatibility/recovery path for the original task. No private task IDs, local paths, raw traces/logs, screenshots, conversation content or attachments are included. Prepared with Codex assistance at the affected user's request.
omarpinarecords commentedon Oct 16, 2026
Focused engineering request for the already reported October 16 rejection
This supplements the existing single-attempt receipt; it is not a new recurrence or retest.
The retained error and currently exposed supported tools do not provide:
Please correlate that original 11:53:33–11:53:34 UTC attempt through normal private support access and identify the rejecting service/deployment, its supported placement versions, the decoding/routing stage and Local-dispatch outcome. Please provide an actionable, identity-preserving correction and the supported condition/route for a same-original retest.
No desktop room request, feedback receipt or tool-call identifier establishes the missing backend correlation. Separate desktop refresh events do not prove the placement rejection's cause. The failed call was not replayed; native success does not meet direct-dot recovery acceptance. The repair remains open pending actual content retrieval from the original affected dot surface after a supported correction.
Prepared with Codex assistance at the affected user's request. No private identifiers, paths, conversation content, raw diagnostics or attachments are included.
omarpinarecords commentedon Oct 16, 2026
October 16 — verified use of the existing-chat workaround
In a newly authorized content request, the saved workflow was selected without a routing reminder. The request identified the same affected Local task but supplied no positive reader/relay routing instructions. An existing capable chat performed one native read_thread(hostId=local) against that original task and returned fresh conversation content to the requesting dot. The returned source identifiers and substantive content were matched privately.
The incoming request and native read execution were independently inspected. The requesting dot's operation to read the response is self-reported; actual content receipt is corroborated by the matching new content and source identifiers. This verifies use of the existing-chat workaround on this occasion, not guaranteed future adoption.
The original cloud_threads.read placement-v3 defect remains unresolved. The broken call was not replayed, this issue remains open, and the existing upstream compatibility investigation and original-reader repair criteria are unchanged. This update reuses the completed observation; no additional content test was performed for reporting.
No names, private identifiers or links, local paths, source conversation excerpts, raw diagnostics, screenshots or attachments are included.
omarpinarecords commentedon Oct 16, 2026
October 16 — native read/send identity mismatch: request for supported target resolution
Desktop baseline: 26.1013.31256 / build 20586. This identifies the client, not a backend deployment.
A retained native read_thread result resolves the delegation source identifier as kind=codex, hostId=durable, null title, idle and zero turns. One native mcp__codex_app__send_message_to_thread call to that exact identifier and host was rejected: “Some requested entity was not found: thread not found.” Delivery is not established. The full correct callable was used; the failed send was not repeated. Metadata visibility alone does not establish send eligibility, and these results do not prove that the identifier is an internal execution thread rather than a main conversation.
Bounded archived native history recovered the original October 1 successful-handoff source underlying #50138. Its send_message_to_thread call used a different destination identifier, hostId=durable, and no model or effort override; the retained call status is completed (928 ms). Subsequent source messages report destination-message readback and processing. Historical tool records expose original arguments/statuses, but not the raw MCP result payload. A bounded current read of that historical destination also returned metadata only with zero turns. The historical destination is therefore not established as a current messageable target. No new send or task restoration was performed.
Please provide:
Those backend fields and a target-scoped view of the recipient's actual runtime tools/custom-rule decisions are unavailable through the exposed supported interfaces. No custom-rule cause or incorrect user-owned route instruction is established, so no local configuration or permission correction is justified.
This is a related native target-resolution boundary, separate from the cloud_threads.read placement-v3 rejection tracked above; a shared cause is not established. The existing-chat native Local-read workaround remains verified. The direct route and original reader remain unresolved; existing repair criteria remain unchanged. The earlier successful-delivery enhancement in #50138 remains distinct. Prepared with Codex assistance at the affected user's request. Private identifiers, paths, conversation content, raw diagnostics and attachments are excluded.
omarpinarecords commentedon Oct 16, 2026
October 16 — zero-saved-rules sender control and current outgoing-delivery control
A coordinator completed one explicitly authorized comparison after removing all eight saved Custom rules and verifying an empty list after reload. At 14:06:05–14:06:06 UTC (10:06:05–10:06:06 EDT), one call to the correct full native send_message_to_thread callable, using the same candidate target and durable host with no model/effort overrides, again returned “Some requested entity was not found: thread not found.” Removing the saved rules did not repair this test; delivery and acknowledgment remain unproved. No backend correlation ID was returned. This does not expose rule-evaluation telemetry or exclude every instruction source.
A separate native inspection found an actual current cloud_threads.send_message delivered to an existing child task. Its delegation envelope carries the same source identity used as the candidate in the failing native send. This proves outgoing dot-to-child delivery on this occasion; it does not establish that source_thread_id is a supported return-message recipient binding. The active child was not interrupted.
Restoration is a separate settings problem: five rules are saved (four exact originals and one accepted narrower replacement). Three originals remain preserved but unrestored after “Permission denied” and “Custom rules can't be edited right now.” Supported Reload rules reconciled the five saved rules but did not unlock editing. No bypass was attempted, and this restoration lock is not established as the sender's cause.
The existing request remains: provide the authoritative current messageable main-dot target/type/host and an identity-preserving correction; identify the rejecting service/deployed version, backend correlation and target-resolution/dispatch stage where available. Those fields remain unavailable through the retained supported evidence and exposed tools. The cloud placement-v3 reader defect remains separate; the verified existing-chat workaround and original repair criteria are unchanged.
This update reuses completed controls. No sender/reader replay, new task, settings change or raw evidence upload was performed by the reporting owner. Please keep this issue open. Private identities, names, task/conversation IDs, paths, rule contents, screenshots and raw diagnostics are excluded.