Codex Desktop: send_message_to_thread requires opening the target task on the local desktop first

Open 💬 2 comments Opened Jul 14, 2026 by amatsuki5032

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_thread for 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/start vs thread/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.

View original on GitHub ↗

2 Comments

Mavumavu · 1 month ago

I reproduced what appears to be the same desktop-activation dependency on Windows, but through spawn_agent during a persisted Goal rather than send_message_to_thread.

Environment:

Codex Desktop 26.715.7063.0
Windows 10 Pro 22H2, build 19045, x64
computer remained awake on the High performance plan; AC/DC sleep was disabled

Sanitized timeline (Europe/Brussels):

08:49:12: parent rollout records function_call name=spawn_agent.
08:49:18: the child rollout receives session_meta, but no task_started.
08:49:20 and 08:49:22: local logs record codex_rmcp_client::rmcp_client::streamable_http_retry warnings.
The parent and child then make no progress for approximately 2h18m while Codex Desktop is backgrounded.
Around 11:07: the user returns to and activates the Codex Desktop window.
11:07:31.805: the child rollout records task_started.
11:07:32.140: the parent receives sub_agent_activity and the delayed spawn_agent result.
11:07:32: local logs record codex_core::responses_retry with connection/disconnected/retry indicators.
11:07:54.136: the new user message is registered, about 22 seconds after the child already started.

The ordering matters: activating the Windows app appears to have resumed dispatch before the new prompt was submitted. This was not a Windows sleep/resume or renderer Not Responding event; the desktop and computer remained responsive.

There is a corresponding Remote symptom. While Desktop is in this stalled state, mobile Remote cannot establish a usable connection to the Windows host or receive live task progress. After local Desktop activation wakes the stalled state, Remote becomes usable again and pending output can arrive. This suggests that background child dispatch and Remote host availability may share the same app-server/reconnect wake path.

Expected behavior: programmatically created child tasks, Goal continuation, and Remote host connectivity should recover from transient connection errors and continue while the awake Windows app is backgrounded. Desktop view activation or a new user turn should not be required to pump reconnect, resume, or mailbox delivery.

I initially opened #34503 for this measured occurrence. Because the core behavior matches this issue's local-desktop-activation prerequisite, I am consolidating the unique evidence here and closing #34503 in favor of this report. No private thread IDs, prompts, project names, repository paths, usernames, or raw logs are included.

Mavumavu · 1 month ago

Another occurrence on 2026-07-23 (Europe/Brussels): the persisted Goal was last demonstrably active at 23:49:45, then made no visible or tool progress until 07:41:22 — approximately 7h51m. No owned build/test/provider process was running, and the repository HEAD and index remained unchanged. The task and its read-only reviewer became responsive again only after a new user interaction.

This is not an isolated hiccup: it now recurs almost daily during multi-day autonomous runs. It makes unattended execution unreliable, wastes hours without an explicit failure state, and can also leave Codex Remote unable to reach the Windows host as described above.