ChatGPT for Windows: dot read/send to selected local thread still fail after update (UNKNOWN / NOT_FOUND) #52892

Summary

After updating ChatGPT for Windows, I still cannot use my dot to continue the existing local thread selected below. This post-update timing is my observation; a causal regression from the update has not been established.

Fresh reproduction on October 10, 2026

My dot could not send a harmless Hola. message to the existing local Codex thread I explicitly selected. The send returned CloudThreadNotFoundError / NOT_FOUND. Reading the same thread separately returned AppServerBackendRequestError: thread not found / UNKNOWN.

The selected computer was reported connected, attached, and authorized for tasks. This records the failure for this particular target through the tools exposed to my dot; it does not establish that all local threads are inaccessible.

Environment and target

• Desktop product: ChatGPT for Windows, as shown in the installed app manifest and Start menu.
• Installed application package version: 26.1007.2314.0; package identity remains OpenAI.Codex.
• Operating system: Windows 11 Home Single Language, 26H2, build 26300.9550, x64.
• These installed desktop/package/OS details were checked locally at approximately 2026-10-10 13:54:25 UTC.
• Executable: app/ChatGPT.exe, file version 155.0.8059.40. This executable file version is included separately and is not the application package version.
• Caller for the dot conversation: ChatGPT web on Windows (web/windows).
• Target: an existing thread supplied by me with hostId=local.
• Thread ID: 019f4f04-fbfc-7e00-b570-9008d9f558bd.
• Original target reference: thread://019f4f04-fbfc-7e00-b570-9008d9f558bd?hostId=local.
• Browser version and subscription: not captured in this reproduction. Codex CLI version was not queried; this report concerns the ChatGPT desktop/local-thread workflow.
• The thread's contents and current local run state could not be independently verified through the failing dot-side read.

Observed sequence

1. I supplied the exact local-thread reference to my dot and explicitly asked it to send Hola. and report the resulting error.
2. At approximately 2026-10-10 13:51:12–13:51:15 UTC, the dot called cloud_threads.send_message for that exact thread ID.
3. The tool returned the send error shown below, without an admitted turn ID or successful-delivery receipt.
4. At approximately 2026-10-10 13:51:39 UTC, cloud_threads.list_environments reported these fields for the selected computer:

   {
     "status": "connected",
     "attached": true,
     "is_authorized_for_tasks": true
   }

   This is a relevant-field excerpt; computer name, environment ID, and unrelated entries are omitted.
5. A separate cloud_threads.read request for the same thread returned the read error below.

Send request

Tool: mcp__codex_apps__cloud_threads_send_message

{
  "threadId": "019f4f04-fbfc-7e00-b570-9008d9f558bd",
  "prompt": "Hola."
}

Complete returned send payload:

{
  "content": [
    {
      "type": "text",
      "text": "CloudThreadNotFoundError: The cloud thread was not found."
    }
  ],
  "structuredContent": {
    "error": "CloudThreadNotFoundError: The cloud thread was not found.",
    "error_code": "NOT_FOUND",
    "error_data": {
      "type": "cloud_thread_not_found"
    }
  },
  "isError": true
}

Read request

Tool: mcp__codex_apps__cloud_threads_read

{
  "threadId": "019f4f04-fbfc-7e00-b570-9008d9f558bd",
  "limit": 1
}

Complete returned read payload:

{
  "content": [
    {
      "type": "text",
      "text": "AppServerBackendRequestError: thread not found: 019f4f04-fbfc-7e00-b570-9008d9f558bd"
    }
  ],
  "structuredContent": {
    "error": "AppServerBackendRequestError: thread not found: 019f4f04-fbfc-7e00-b570-9008d9f558bd",
    "error_code": "UNKNOWN"
  },
  "isError": true
}

Diagnostics and limits

• These are two different operations and error payloads: send returns NOT_FOUND; read returns UNKNOWN.
• No stack trace, stack frames, server logs, HTTP status, backend request ID, or delivery receipt was included in these returned payloads. The JSON above is the complete error evidence available from those calls.
• The exposed send schema accepts threadId, prompt, and optional model/thinking settings. It does not expose a hostId or environmentId parameter. The hostId=local part of the supplied reference therefore was not passed as an unsupported argument.
• Inspection of the real dot session's available tool catalog found no send_message_to_thread tool or singular mcp__codex_app__ namespace. This is a tool-catalog observation, not a claim that a native desktop method was invoked and failed.
• Some other delegated tasks have worked in this workflow. They were not rerun as controls in this reproduction, and their success does not establish that this particular existing local target is supported.
• Routing, target eligibility, or task visibility could be involved, but the returned errors do not establish a root cause.

Expected behavior and requested investigation

An explicitly selected, eligible existing local Codex thread on the connected computer should accept the authorized follow-up through a supported dot-side operation. If this target is ineligible or requires a different route, the response should identify that boundary and the supported next step.

The October 5–9 release notes describe following up on existing Codex threads. The existing-local-task documentation describes continuation on a connected computer, while also noting that connection alone does not grant access to every conversation.

Please clarify which existing local thread types are supported, how the dot should address this target, and how to obtain useful diagnostics when read and send return the errors above.

Related reports

• Dot cannot continue an existing local Codex chat on a connected Windows computer #52222: the closest matching Windows dot-to-existing-local-thread send failure.
• dot cannot continue an existing connected Windows local task: placement format version 2 and CloudThreadNotFoundError #50171 and Dot cannot create or follow up with local Codex tasks in saved projects #49729: related read/send failures, with placement-format errors on read rather than this reproduction's plain thread not found.
• Improve discovery and wrong-route diagnostics for dot continuation of local Codex chats #49482: native continuation succeeded in another setup; this is why no universal lack of local-thread support is asserted here.

The target identifier and harmless test prompt are included at my request for tracing. Private project contents, machine/environment identifiers, credentials, and unrelated conversation data are omitted.