Codex Desktop UI leaves send_message_to_thread tool call stuck after backend completion

What version of the Codex App are you using?

Codex Desktop for Windows from Microsoft Store/App package path observed as OpenAI.Codex_26.608.1337.0_x64__2p2nqsd0c76g0.

CLI also installed: codex-cli 0.128.0.

What subscription do you have?

ChatGPT/Codex desktop account. I can provide account/subscription details privately if needed.

What platform is your computer?

Windows 11, x64.

What issue are you seeing?

A Codex Desktop thread can remain visually stuck showing the tool-call UI state for send_message_to_thread / "sending message to conversation" even after the backend operation has already completed successfully.

In the affected thread, the visible UI remained on:

• 正在傳送訊息至對話 / sending message to conversation
• the composer still showed the stop button
• the prior text output already reported success: send_result=threadId returned; slept=true

Local delivery state also confirmed completion:

status: visible_sent_unconfirmed
target_thread_id: 019e7294-e2a7-7373-8e5a-9b4d86723694
visible_sent_at: 2026-06-13T00:36:51Z
last_error: null

The event was no longer pending, and the short-lived heartbeat automation file had already been removed/slept. In other words, the backend delivery was done, but the Desktop UI did not mark the tool call as completed.

What steps can reproduce the bug?

This was observed in a Codex Desktop automation/postman thread that uses the official thread tool to forward notifications to another Codex thread.

1. Create or use an existing Codex Desktop thread that can call send_message_to_thread.
2. Trigger a message send from that thread to another existing thread.
3. The tool call succeeds and returns a thread id.
4. The thread prints/logs a success line such as send_result=threadId returned; slept=true.
5. Observe that the Codex Desktop UI can continue showing the tool-call status as still running: "sending message to conversation" / 正在傳送訊息至對話, with the stop button still visible.

The failure is intermittent, but once it happens, the UI state remains stuck even though the backend state and delivery logs indicate success.

What is the expected behavior?

When send_message_to_thread returns successfully, the Codex Desktop UI should mark the tool call as completed and clear the in-progress/sending state.

If the backend delivery completed but frontend status reconciliation fails, the UI should eventually self-heal or show a retriable UI-only state rather than leaving the thread looking active forever.

Additional information

This matters for automation/postman workflows that use a dedicated Codex thread as a visible delivery bridge. The backend result and local state both indicate success, but the Desktop frontend leaves the bridge thread appearing busy/stuck.

Workaround currently being tested: move the actual delivery to a hidden/background CLI dispatch path and keep the UI thread as a status monitor only. This avoids blocking a visible Desktop thread, but it is a workaround; the root issue appears to be frontend/tool-call completion state not being reconciled after a successful tool return.

Searches for existing issues mentioning send_message_to_thread and this specific stuck UI state did not find an obvious duplicate.