Codex Desktop: send_message_to_thread returns thread not found for a readable/listed local thread #49676

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

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   tool-callsIssues related to tool callingIssues related to tool calling

   on Sep 30, 2026
2. MassiveMassimo commented on Oct 2, 2026

   

   MassiveMassimo

   on Oct 2, 2026 – with ChatGPT Codex Connector

   More actions

   I observed a similar read/send mismatch with durable cloud tasks, whereas this report concerns a local desktop thread.

   • I manually created two tasks in the same saved cloud environment and completed a harmless ping/Pong exchange.
   • My dot could read each task successfully, but sending a follow-up through its cloud task messaging returned CloudThreadNotFoundError / NOT_FOUND for both.
   • Two replacements created by my dot using saved cloud environments supported both reads and follow-up sends, with acknowledgments returned.

   This comparison doesn't establish an ownership requirement or a shared cause with the local-thread failure. The replacements also couldn't be moved into my existing local project folders; I added that observation to #49586.
3. nikolaj-sympact commented on Oct 10, 2026

   

   nikolaj-sympact

   on Oct 10, 2026

   More actions

   Confirmed on Windows 11 with the current desktop app on 2026-10-10.

   Desktop update checker reports installedVersion 26.1007.21434, build 13901, status up_to_date. Bundled engine reports codex-cli 0.162.0-alpha.17.2.

   Observed on the SAME existing local thread:

   • The UI shows the retained conversation but submitting a message displays thread not found: <same thread ID>.
   • Native read_thread succeeds and reports notLoaded. Earlier native sends to that thread worked.
   • Native navigate_to_codex_page returns navigated:true, but a subsequent harmless, authorized send_message_to_thread still returns thread not found.
   • Opening the same codex://threads/ deep link does not restore sending.
   • Read-only local state inspection confirms the exact thread exists, archived=0, history_mode=paginated, with its original rollout file present and matching session_meta ID.
   • A separate bounded diagnostic using the SAME bundled engine and supported stdio JSON-RPC initialize + thread/resume successfully resumes the SAME ID as idle with 237 retained turns, both with default settings and features.code_mode_host=true. No turn/start, inference, fork, database edits, or replacement thread were performed.

   The app routing/resumption path therefore remains broken despite readable and resumable persisted history. This is an observed workflow, not a verified fresh-install deterministic reproducer. The exact root cause is unknown.

   Impact: an ongoing long-lived task cannot receive follow-up instructions through the normal UI/native app route. Creating a replacement thread is not an acceptable workaround for preserved identity and continuity. A full app restart was not performed because it could interrupt other active agent turns.

   Requested: a same-thread, non-destructive recovery path and an actionable lifecycle error instead of claiming the existing thread does not exist.

   No thread IDs, user/account identifiers, host names, paths, transcripts, screenshots, raw logs, credentials, or customer documents are attached.
4. Dy3r commented on Oct 15, 2026

   

   Dy3r

   on Oct 15, 2026 – with ChatGPT Codex Connector

   More actions

   Additional observed native status/send mismatch on October 15, 2026, for the reverse direction: a Windows desktop task attempting to send a harmless coordination probe to its verified main dot conversation (durable host).

   Observed sequence:

   1. The destination ID was independently verified through cloud_threads.read, which returned that exact conversation.
   2. On the desktop, native wait_threads with the same target and timeoutMs=0 succeeded, reporting host durable, status idle and a cursor.
   3. Exactly one authorized send_message_to_thread using that target and the returned host failed with: "Some requested entity was not found: thread not found". No message or turn ID was admitted.
   4. A subsequent wait using the returned cursor reported changed=false, the same cursor and idle state, with no new message/turn marker. No receipt, steering or idle wake was observed.

   The send was attempted at approximately 16:05:50 UTC and returned by 16:05:55 UTC. Installed CLI reports codex-cli 0.162.0-alpha.17.2; the desktop app build was not captured, and the CLI version is not being used as a proxy for it.

   Separately, the opposite cloud-to-existing-desktop route returned unsupported placement format version 2 on read and CloudThreadNotFoundError on send. These observations do not establish a common internal cause.

   This is one observed workflow, not a fresh-install deterministic reproducer. No speculative host/ID substitution, retransmission, placement-database edits, raw session inspection, new access, pairing or background service was used. Existing task identity was preserved.

   Expected: a target resolved by supported status/read operations accepts an authorized message, or returns an actionable lifecycle/routing error. Is there a supported non-destructive recovery or cross-surface route for this durable-target case?

   Only sanitized diagnostics are included; task/account/computer identifiers, repository names, paths, conversation content, logs and credentials are omitted.