Codex Desktop: send_message_to_thread requires opening the target task on the local desktop first
What version of the Codex App are you using?
Windows Store package: OpenAI.Codex_26.707.9981.0_x64
Bundled/local CLI: codex-cli 0.144.1
What subscription do you have?
ChatGPT plan with Codex access.
What platform is your computer?
Windows 10 x64, build 19045.
What issue are you seeing?
Cross-task messaging with send_message_to_thread appears to depend on the target task first being opened and displayed in Codex Desktop on the machine that runs Codex.
A newly created target task cannot reliably receive/run a cross-task message while it has never been displayed in the desktop UI. Opening the same target task from ChatGPT mobile does not activate it. After manually clicking the target task in Codex Desktop so that its view is displayed, the same cross-task send works.
This was observed when a GPT-5.6 source task created a GPT-5.5 target task, so cross-model task creation may be a contributing condition. The behavior looks more like a target thread registration/resume lifecycle gap than a model execution failure.
What steps can reproduce the bug?
- In Codex Desktop, use a source task running GPT-5.6.
- From that task, create a separate user-owned target task using GPT-5.5.
- Do not open or display the target task in Codex Desktop.
- From the source task, call
send_message_to_threadfor the target task ID. - Observe that the cross-task send cannot execute or does not reach/start the target.
- Open the target task from ChatGPT mobile, but leave it unopened on the desktop machine.
- Retry the cross-task send. The problem remains.
- On the machine running Codex Desktop, click the target task so its view is displayed.
- Retry the same cross-task send.
- Observe that it now works.
What is the expected behavior?
A valid task/thread ID returned by task creation should be sufficient for cross-task messaging. The target should be registered/resumed in the background as needed, without requiring manual desktop focus or view activation.
Desktop view activation should not be an implicit prerequisite for send_message_to_thread, and opening the task on mobile should not leave desktop-side routing in an unusable intermediate state.
Actual behavior
The target behaves as if it is not messageable until the desktop renderer has displayed it once. Mobile opening does not satisfy that condition; a local desktop click does.
Additional information
No private thread IDs, prompts, repository paths, or account data are included in this report.
Possibly related, but not exact duplicates:
- #30710 — stored-but-not-loaded thread can race
turn/startvsthread/resume. - #30916 — Desktop does not resume threads that appear while the app is already running.
- #32165 — cross-task delegated turns can miss target task execution context until direct user interaction.
The distinguishing behavior here is the send_message_to_thread path itself: a programmatically created target becomes messageable only after local desktop view activation, while mobile view activation does not help.