Repository navigation
Improve discovery and wrong-route diagnostics for dot continuation of local Codex chats #49482
Description
Verification update
Native local-chat continuation works in the tested setup. Native list, read, and send operations succeeded, the intended existing local chats received the requests, and their full responses were retrieved. No permission or settings changes were needed.
This is a discoverability and wrong-route diagnostics feature request. The completed test does not establish a platform bug or missing native capability.
What variant of Codex are you using?
Codex/ChatGPT desktop app on macOS, with a dot and a connected, authorized computer. Exact app version was not collected.
What feature would you like to see?
Improve discovery of the supported route from a dot to an explicitly referenced existing local Codex chat, and provide an actionable diagnostic when the wrong route is selected.
The assigned-work documentation describes continuation of existing local Codex tasks on a connected computer. That capability succeeded in the final test.
Suggested improvements:
- Make the supported native continuation route and callable tool names easy to discover from a user-provided local chat mention or deep link.
- When a cloud-only route cannot address a local chat, explain the scope mismatch and supported next step where the target can safely be identified, instead of leaving an ambiguous not-found result.
- Keep access scoped to the user-authorized chat and request, with existing safety controls intact.
Additional information
Observed on September 30, 2026:
- A cloud-thread messaging attempt for an exact existing local chat reference returned
CloudThreadNotFoundError. This may correctly reflect that API's scope. - Initial agent reporting said native tools were unavailable. The original probe expressions were not recoverable, so that claim cannot establish missing or delayed tools.
- The supported native route subsequently completed the full list/read/send/reply workflow.
- An exact namespace check returned
"function"fortypeof tools.mcp__codex_app__send_message_to_threadand"undefined"fortypeof tools.codex_app__send_message_to_thread.
There is no evidence of the same callable name changing availability. An agent discovery or routing mistake remains a possible explanation for the earlier blockage. The earlier pending-verification description is superseded by the successful end-to-end result above.
Related reports #44212, #40852, #36673, and #49423 were reviewed during triage; this result does not reproduce or establish their failures. Please consolidate if the narrow discovery/diagnostics improvement is already tracked.
No private chat identifiers, contents, local paths, screenshots, or logs are included.
Activity
[-]Make dot continuation of explicitly referenced local Codex chats reliably discoverable[/-][+]Improve discovery and wrong-route diagnostics for dot continuation of local Codex chats[/+]yaoyuliu621-collab commentedon Sep 30, 2026
Related Windows observation for the discoverability/access-scope question in this issue. This is not a claim that the successful macOS result is wrong, or that dots can only access chats they created.
Environment: Windows 11 x64; desktop internal version 26.928.21956 (build 12404, prod), Windows package 26.928.2636.0. The connected computer is reported connected, attached and authorized for tasks.
Observed directions:
After reading this issue's successful namespace correction, we requested a bounded check of the exact names below, rather than the shorter codex_app__ names:
The dot's returned diagnostic message reports undefined for all three and no exact matches in its tool catalog. This is a reported tool-inventory result, not a successful native reverse-call or proof of a product-wide limitation. We did not retry the known cloud-only route or use an unofficial bridge.
The official assigned-work documentation describes continuing an existing local Codex task. Please make the applicable native route discoverable in this Windows/dot environment, or explain the specific capability/account/version gate when it is not exposed. A scope-aware diagnostic would be more actionable than an ambiguous NOT_FOUND.
There is also a separate delegated-browser MCP startup failure, with a successful local-browser control case, documented in our accompanying comment on #49488. A shared root cause is unconfirmed. No private chat contents, identifiers, paths, credentials or screenshots are included.
NaturalMatchaKing commentedon Sep 30, 2026
Additional Windows observation matching the continuation/discovery gap discussed here.
Environment reported by a separate local maintenance check: Windows 10 build 19045, desktop package 26.928.2636.0, internal app version 26.928.21956, bundled engine 0.159.2. The computer was connected and authorized for dot tasks.
Observed workflow:
The local maintenance check confirmed that the target task exists, belongs to the project, is not archived, and that the supplied identifier matched. A separate dot-created local task's available tool catalog did not expose the three native entry points named in this issue: mcp__codex_app__list_threads, mcp__codex_app__read_thread, or mcp__codex_app__send_message_to_thread.
This establishes one failed route in this setup. There was no independent read-call test, and it does not establish that native continuation is impossible or contradict the successful macOS case. A cloud-only lookup may correctly reject a local task. The unresolved problem is discovering an available supported route from dot.
The assigned-work documentation describes continuing existing local tasks. Please clarify the applicable Windows capability or version requirements, expose the native route where supported, and return a scope-aware next step instead of an ambiguous NOT_FOUND.
No further tests or application changes were made for this report. Private task/project identifiers, deep links, paths, account information, conversation contents, logs, and screenshots are omitted.
Aljesf commentedon Sep 30, 2026
Additional Windows/web feedback for this discovery and routing request. The connected Windows computer can run dot-created tasks, but the inspected child task inventories did not expose the supported Computer Use runtime or native local-chat list/read/send entry points. Existing local Codex chats can initiate messages to the dot and retrieve its replies. The attempted dot-to-existing-local-chat send through the cloud-thread route returned NOT_FOUND; a supported native reverse route was not verified in this setup.
This does not establish a product-wide missing capability or contradict the successful macOS case above. The cloud-only route may correctly reject a local chat.
Please make the supported Windows route for continuing an explicitly selected existing local chat discoverable, including:
Related Windows Computer Use reports #49458 and #49588 describe a separate tool-exposure symptom; a shared cause is unconfirmed. Exact application and OS build versions were not collected for this feedback. No private chat contents, identifiers, paths, screenshots, or logs are included.
NaturalMatchaKing commentedon Sep 30, 2026
Additional observation on Windows 10: the same
CloudThreadNotFoundError / NOT_FOUNDoccurred when a dot tried to send a harmless message to a second user-created local Codex Desktop thread. This thread was created without a project, so the failure does not appear limited to local project association. No message was delivered. This does not establish whether the behavior is an intentional access restriction or a routing defect. Please clarify the supported scope for dot-to-local-thread messaging.ayaz-mudarris commentedon Sep 30, 2026
Update from the original macOS setup, September 30, 2026 (UTC):
mcp__codex_app__list_threads,mcp__codex_app__read_thread, andmcp__codex_app__send_message_to_threadcompleted the list/read/send/reply workflow successfully.typeof tools.mcp__codex_app__read_threadandtypeof tools.mcp__codex_app__list_threadsboth returned"undefined". Neither exact name appeared in the available tool catalog. The computer still appeared connected, attached, and authorized in the parent environment inventory.These checks targeted the same selected computer and local task, but they do not establish an unchanged runtime lifetime; refreshed execution may affect capability exposure.
Unlike the initial uncertain probe, this later evidence uses the same fully qualified native names that worked earlier. It therefore supersedes the earlier statement that there was no evidence of the same names changing availability. The successful morning continuation remains valid, while the later catalog omission is now a separate verified checkpoint.
This does not establish a root cause, release regression, or product-wide failure. Please provide diagnostics that distinguish tool exposure, host readiness, and history-transport failures so an authorized continuation can select the supported route or explain the specific blocker.
No private task identifiers, conversation contents, paths, or raw logs are included.
masterAIGC commentedon Sep 30, 2026
Additional sanitized evidence from another macOS setup, submitted at the affected user's request.
mcp__codex_app__read_threadcall withhostId: "local"successfully read that exact conversation.mcp__codex_apps__cloud_threads_send_messagewith onlythreadIdandprompt. No structured computer, host, or environment selector was supplied. Mentioning the Mac in the prompt does not establish routing.14:40:41 is a record made after the tool returned, not a server-provided error timestamp. No request ID was returned.
The dot subsequently reported discovering cloud_threads_list_environments/list_threads/read/send_message but no native local list/read/continue entry point. It did discover the Mac as connected, attached=true, and is_authorized_for_tasks=true. It returned an environmentId, not a hostId.
Crucially, we have not independently captured the dot's exact native-tool discovery expressions. In light of this issue's verification update, its statement that native tools were absent is not proof of a missing product capability. The working native tools available to a separate local conversation also do not prove the dot caller has the same tools or access. We have not yet repeated native continuation using an exact-name probe on the dot side.
This supports the request for discoverable native routing and actionable scope errors. We are not claiming that the cloud-only endpoint should accept a local ID or undocumented host parameters. The enterprise 26.929 requirement has not been established as applicable to this personal account.
Dot-created tasks in this setup have separately passed marker-response and file write/readback checks; basic delegation is not wholly broken. A subsequent Computer Use failure is a separate observation, not an established cause of the local-chat lookup error.
Private conversation IDs, environment identifiers, device names, prompts containing private context, and raw logs are omitted.
masterAIGC commentedon Sep 30, 2026
Follow-up to my report above: the affected user has now relayed the dot's exact-name tool-directory check.
The dot reports no matches for:
mcp__codex_app__list_threadsmcp__codex_app__read_threadmcp__codex_app__send_message_to_threadIt also reports an empty result for the full prefix
mcp__codex_app__. It explicitly did not substitute the plural namespace or omitmcp__.This is a dot-reported directory inspection relayed by the user, not an independently captured raw directory dump or JavaScript callable probe. It supports that these native entry points are not exposed in that dot's currently inspected tool catalog; it does not establish permanent product unavailability, the rollout/authorization cause, or whether another supported discovery mechanism exists.
No messages were sent to the local task, no new tasks were created, and Computer Use was not called for this check.
Could maintainers clarify how the native local-thread tools should be discovered/exposed to a personal-account dot on desktop 26.928.21956, and what sanitized diagnostic can distinguish a tool-exposure/rollout issue from a discovery issue? The native tools remain available to the separate local Codex conversation, so availability differs between the two observed contexts.
The separate Computer Use failure in a dot-created task that passed text/file checks is tracked in #49662; we are not treating it as the same failure.
asisad commentedon Oct 5, 2026
Additional Windows/web discovery observation from October 5, 2026:
I asked my dot to find an existing task by title and continue it. The task was open in my Windows desktop app and the computer was connected, but the task list available to dot returned identifiers without titles. Dot could not identify the intended task.
Some accessible tasks could be read when their IDs were known. The connected-computer task also lacked callable window-reading tools, so it could not inspect the open window. The target ID was never established; this is not a confirmed reproduction of the placement-format errors reported elsewhere.
What is the supported way to identify an existing local task by title or selection? Which Work/Codex task types are supported, and what should users do when native thread tools are unavailable?
Private task details are omitted. App and OS build numbers were not captured.
ayaz-mudarris commentedon Oct 6, 2026
ayaz-mudarris commentedon Oct 6, 2026
Additional macOS checkpoint from October 6, 2026 (UTC), following the earlier successful native continuation and later failures documented above.
The requested action was read-only retrieval from an explicitly identified existing local chat.
cloud_threads.send_messagetargeting that local chat returnedCloudThreadNotFoundError.cloud_threads.send_messagereturnedAppServerBackendRequestError. Earlier Mac task-launch attempts had also failed while the computer was reported connected and authorized for tasks.undefinedfor all three:tools.mcp__codex_app__list_threads,tools.mcp__codex_app__read_thread, andtools.mcp__codex_app__send_message_to_thread.Neither attempted route completed the requested retrieval. The first error may correctly reflect the cloud route's scope. The second is a separate backend/task-continuation failure; a shared cause is unconfirmed. These observations do not invalidate the September 30 native success or establish permanent unavailability of native continuation. Current app and OS build numbers were not captured.
Please provide a discoverable supported route for continuing an explicitly selected local chat, plus distinct, actionable diagnostics for route mismatch, native-tool availability, and desktop executor/backend readiness. A connected/authorized status alone did not identify a working next step in this incident.
Private chat contents, names, identifiers, device identifiers, paths, and raw logs are omitted.
98098051x-svg commentedon Oct 10, 2026
Sanitized Windows continuation evidence, submitted at the affected user's request (October 10–11, 2026, UTC+08).
Environment verified in a separate local Codex conversation: Windows 11 Pro 26H2, build 26300.9457; desktop package 26.1007.2314.0; updater-reported app 26.1007.21434, build 13901, prod, up to date; bundled local core 0.162.0-alpha.17.2.
The owner supplied the exact identifier of an existing user-created local conversation. The local conversation can be read through the supported native read_thread tool from this local diagnostic context. The owner relayed the dot's failed attempt to continue it:
cloud_threads.send_message→CloudThreadNotFoundError: The cloud thread was not found.,error_code: NOT_FOUND,error_data: {"type":"cloud_thread_not_found"}.No task acceptance receipt was returned, and no screenshot or harmless calculator action occurred in the target as a result of that send.
The owner also relayed the dot's tool check: no
mcp__codex_app__send_message_to_threador corresponding localread_threadentry point was available; its available send route was cloud_threads.send_message. This is user-relayed dot evidence, not an independently captured raw tool directory or exact callable probe. The native read/send tools are available in this separate local Codex context. These observations do not prove permanent product-wide unavailability; the cloud endpoint may correctly reject a local ID.Earlier dot-side reads were also reported to return unsupported placement format versions 3 and 1 for different local conversations. These are separate observations, not evidence that the targets do not exist or share one root cause.
Could maintainers prioritize clarification of the supported Windows dot-to-existing-local-chat continuation route, the tool exposure/capability requirements and placement compatibility? Please provide an actionable diagnostic and delivery receipt, so the user can automate authorized dispatch without repeatedly copying instructions or clicking manually. We are not asking for a cloud-only endpoint to silently accept local IDs or for an undocumented bridge.
Computer control in a dot-delegated task has a separate MXC startup failure, now documented in #52407 (#52407 (comment)). A shared cause is unconfirmed. Local native calculator control passed independently, which does not establish a working dot dispatch chain.
The owner reports substantial troubleshooting time and usage allowance spent, without a quantified amount. Private chat IDs, account details, paths, screenshots and raw logs are omitted.