What version of the Codex App are you using (From “About Codex” dialog)?
26.928.2636.0 initially verified; updated and restarted October 1, 2026, but updated Desktop package version unverified. Installed CLI: 0.159.2.
What subscription do you have?
Pro Lite — US$100/month (confirmed by the account owner)
What platform is your computer?
Windows desktop; exact OS build not collected in this test
What issue are you seeing?
Observed September 30, 2026, with a post-update retest on October 1, 2026. Cached first-party codex-app-tools version: 0.1.5. Delegated testing used GPT-6.1 Sol with Medium reasoning.
The dot has cloud_threads tools, but lookup of the verified local thread returns “thread not found.” Exact callable checks for mcp__codex_app__list_threads, mcp__codex_app__read_thread, and mcp__codex_app__send_message_to_thread return undefined. The delegated desktop-executor tool catalog also lacks these native methods. Creating and running a separate delegated local task on the connected PC succeeds.
Related issue #49482 now describes a successful native workflow on macOS and a discovery enhancement. This report concerns persistent absence of the exact native methods in the tested Windows setup; a shared cause is not established.
What steps can reproduce the bug?
- Keep the Windows PC connected with Codex Desktop open and an existing local conversation available.
- Ask dot to communicate with that specific existing local conversation. Creating and running a delegated local task on the PC succeeds, but it is a separate conversation.
- Inspect dot’s available tools and attempt the supported existing-thread lookup.
- Observe the local-thread lookup returning “thread not found” and the exact native list/read/send methods remaining unavailable.
On October 1, after the user installed a pending update and restarted Codex, the PC remained connected and authorized, but lookup still failed and the native methods remained absent in both the parent and helper. A new installed executable was found, reporting CLI 0.159.2. The permitted package query returned no result, so the updated Desktop package version was not verified. No new message was sent to the target conversation in this retest.
What is the expected behavior?
dot should be able to read and communicate with an explicitly authorized existing local conversation, preserving its identity and history, or clearly explain the supported availability boundary and recovery route.
Additional information
Additional tested evidence
- Scoped static inspection: codex-app-tools is enabled=true; its cached codex_app definition is enabled=false. The 0.1.5 working directory, launcher, and server files exist. No singular codex_app override was found in the inspected user/workspace configuration. Effective per-task host provisioning remains unverified; the cached flag alone does not prove a defect.
- A prior permitted provider probe initialized successfully, then tools/list failed with JSON-RPC -32603 and “connect EPERM” on the Desktop named pipe. The opaque pipe identifier is omitted. That denied route was stopped; no tools/call followed.
- Installed CLI default-context diagnostics reported “Could not find home directory” and “failed to resolve CODEX_HOME.” Two specifically approved outside-sandbox diagnostics resolved home/configuration and showed the provider reachable. app-server daemon version still failed to connect to the default control socket with Windows OS error 10050. This does not establish a general internet outage.
- A separate supported queue/history test verified one message inserted into the intended existing conversation. Its response was interrupted when the test connection closed; a later continuation encountered an active-writer conflict. Queue acceptance/history insertion is not native sender attribution or verified two-way communication. No acknowledgment or working repair was verified.
Requested investigation
Please diagnose native existing-thread capability provisioning for this task origin. Is this an intended availability boundary, a host registration/discovery failure, or a missing catalog projection? These are hypotheses, not established causes. Please identify a supported recovery that preserves existing conversations and permissions.
This report contains technical version data and redacted error text only. No raw logs, transcripts, screenshots, credentials, private file contents, or identifying thread/account/device paths are attached.
Relevant public references
These references provide context; they do not establish that the same cause applies to this installation.
What version of the Codex App are you using (From “About Codex” dialog)?
26.928.2636.0 initially verified; updated and restarted October 1, 2026, but updated Desktop package version unverified. Installed CLI: 0.159.2.
What subscription do you have?
Pro Lite — US$100/month (confirmed by the account owner)
What platform is your computer?
Windows desktop; exact OS build not collected in this test
What issue are you seeing?
Observed September 30, 2026, with a post-update retest on October 1, 2026. Cached first-party codex-app-tools version: 0.1.5. Delegated testing used GPT-6.1 Sol with Medium reasoning.
The dot has cloud_threads tools, but lookup of the verified local thread returns “thread not found.” Exact callable checks for mcp__codex_app__list_threads, mcp__codex_app__read_thread, and mcp__codex_app__send_message_to_thread return undefined. The delegated desktop-executor tool catalog also lacks these native methods. Creating and running a separate delegated local task on the connected PC succeeds.
Related issue #49482 now describes a successful native workflow on macOS and a discovery enhancement. This report concerns persistent absence of the exact native methods in the tested Windows setup; a shared cause is not established.
What steps can reproduce the bug?
On October 1, after the user installed a pending update and restarted Codex, the PC remained connected and authorized, but lookup still failed and the native methods remained absent in both the parent and helper. A new installed executable was found, reporting CLI 0.159.2. The permitted package query returned no result, so the updated Desktop package version was not verified. No new message was sent to the target conversation in this retest.
What is the expected behavior?
dot should be able to read and communicate with an explicitly authorized existing local conversation, preserving its identity and history, or clearly explain the supported availability boundary and recovery route.
Additional information
Additional tested evidence
Requested investigation
Please diagnose native existing-thread capability provisioning for this task origin. Is this an intended availability boundary, a host registration/discovery failure, or a missing catalog projection? These are hypotheses, not established causes. Please identify a supported recovery that preserves existing conversations and permissions.
This report contains technical version data and redacted error text only. No raw logs, transcripts, screenshots, credentials, private file contents, or identifying thread/account/device paths are attached.
Relevant public references
These references provide context; they do not establish that the same cause applies to this installation.