Environment
Codex desktop on Windows, coordinating a local thread with a cloud-backed Dot conversation. Observed September 30, 2026. Exact desktop build and subscription not collected.
Actual behavior
Communication is asymmetric between the local coordinator and Dot:
- The local coordinator successfully uses
send_message_to_thread to deliver a prompt to Dot's cloud-backed conversation.
- The local coordinator can retrieve Dot's conversation using
read_thread and can inspect completion through wait_threads.
- Dot reports that
send_message_to_thread is not available in its tool set. It has cloud_threads.send_message, but reports NOT_FOUND when targeting the local coordinator's thread.
- In the latest check, Dot used
user_message.send_message on the ChatGPT channel to explain the limitation. The local coordinator retrieved that explanation with read_thread; this was not a direct reply delivered to the coordinator.
The inbound delegated prompt and Dot's latest tool invocation were observed through the desktop thread reader. The earlier NOT_FOUND result is Dot's reported evidence, not an independently reproduced raw failure from this latest check. No common root cause or product-wide failure is claimed.
Reproduction outline
- Open a local Codex desktop conversation and a cloud-backed Dot conversation.
- From the local conversation, send a short authorized message to Dot using the native thread-messaging tool.
- Ask Dot to reply to the originating local conversation using the native thread channel.
- Inspect Dot's available tools and reply attempt. In this setup, the local thread-messaging tool is unavailable on Dot's side, and its cloud channel does not resolve the local destination.
- Read Dot's response from the local side. Reading works, but direct reverse delivery is unavailable.
Expected behavior
Provide a supported, permission-scoped bidirectional channel between a user's local Codex conversations and their cloud-backed Dot conversation, or clearly document the boundary and supported alternative. Cross-host destination lookup should return actionable information when a thread exists but is unsupported by the sender's channel.
This request is not to bypass authorization, grant access to unrelated conversations, or allow agents to message without human authorization.
Impact and workaround
The coordinator must pull Dot's replies manually through the thread reader. The user is otherwise asked to copy messages between conversations, causing extra coordination steps. No measured token savings or usage total is claimed.
A business MCP/CRM is deliberately NOT used as a messaging bridge: application clients must not gain access to agent coordination. No CRM permissions were expanded for this report.
Privacy
This report omits private thread IDs, customer/case information, hostnames, local user paths, credentials, and full conversations. The exact desktop version remains unverified. Please advise whether this is a known platform limitation or a supported integration defect and which diagnostic metadata would help.
Environment
Codex desktop on Windows, coordinating a local thread with a cloud-backed Dot conversation. Observed September 30, 2026. Exact desktop build and subscription not collected.
Actual behavior
Communication is asymmetric between the local coordinator and Dot:
send_message_to_threadto deliver a prompt to Dot's cloud-backed conversation.read_threadand can inspect completion throughwait_threads.send_message_to_threadis not available in its tool set. It hascloud_threads.send_message, but reportsNOT_FOUNDwhen targeting the local coordinator's thread.user_message.send_messageon the ChatGPT channel to explain the limitation. The local coordinator retrieved that explanation withread_thread; this was not a direct reply delivered to the coordinator.The inbound delegated prompt and Dot's latest tool invocation were observed through the desktop thread reader. The earlier
NOT_FOUNDresult is Dot's reported evidence, not an independently reproduced raw failure from this latest check. No common root cause or product-wide failure is claimed.Reproduction outline
Expected behavior
Provide a supported, permission-scoped bidirectional channel between a user's local Codex conversations and their cloud-backed Dot conversation, or clearly document the boundary and supported alternative. Cross-host destination lookup should return actionable information when a thread exists but is unsupported by the sender's channel.
This request is not to bypass authorization, grant access to unrelated conversations, or allow agents to message without human authorization.
Impact and workaround
The coordinator must pull Dot's replies manually through the thread reader. The user is otherwise asked to copy messages between conversations, causing extra coordination steps. No measured token savings or usage total is claimed.
A business MCP/CRM is deliberately NOT used as a messaging bridge: application clients must not gain access to agent coordination. No CRM permissions were expanded for this report.
Privacy
This report omits private thread IDs, customer/case information, hostnames, local user paths, credentials, and full conversations. The exact desktop version remains unverified. Please advise whether this is a known platform limitation or a supported integration defect and which diagnostic metadata would help.