Codex Desktop thread tools intermittently lose handlers and may create systemError worker threads after create_thread failure #31119

Summary

In Codex Desktop on Windows, the thread-management tool surface can intermittently expose tools such as list_threads, read_thread, send_message_to_thread, set_thread_title, and create_thread, but the actual call returns No handler registered for tool: ....

In one recent manager/worker workflow this caused a more serious failure mode: create_thread returned a handler error, but delayed verification later showed that the child thread was actually created. A retry then produced a duplicate/orphan worker. The canonical created workers initially appeared as systemError and only became usable after I manually opened/prompted the worker threads.

Related issues I found before filing:

• Desktop thread tools intermittently lose handlers (No handler registered) within an active session #28080 - Desktop thread tools intermittently lose handlers
• send_message_to_thread reports handler error even when delegation is delivered #29886 - send_message_to_thread reports failure while delivery may have succeeded
• Allow a Codex Desktop thread to spawn visible, running child threads #29275 - new thread creation fails silently / reports errors while thread exists
• Codex Desktop create_thread from an SSH-host executor can spawn children on local host and lose completion handoffs #30626 - possibly related threaded/grouped chat workflow state

This issue is for the combined manager/worker failure mode where handler errors, delayed creation, duplicate workers, and systemError child threads occur together.

Environment

• OS: Windows
• App: Codex Desktop
• CLI visible in same environment: codex-cli 0.142.5
• Shell: PowerShell
• Workspace cwd for the affected threads: C:\Work\Codebase

Observed behavior

A manager thread attempted to create two bounded worker threads from prepared prompts:

• HS-001 Report Command Safety Worker - HydroScope2
• MRW-003 Water Levels Fixture Worker - HydroScope2

Sequence observed:

1. list_threads duplicate checks repeatedly failed with:

   No handler registered for tool: list_threads
   

2. User explicitly approved a narrow blind-create fallback for exactly two named workers.

3. create_thread for the first worker returned:

   No handler registered for tool: create_thread
   

4. Delayed verification initially found no candidate, so the manager performed one permitted retry.

5. Later delayed verification found two matching worker threads, meaning at least one call that reported a handler error had actually created a thread.

6. One worker candidate was selected as canonical. The earlier candidate was marked duplicate/orphan.

7. set_thread_title and send_message_to_thread also failed with No handler registered for tool: ....

8. Direct read_thread sometimes worked and sometimes failed across sessions. When it worked, both canonical worker threads initially showed status=systemError and no acknowledgement.

9. After manually opening/prompting the canonical worker threads, both became active and acknowledged standby. Direct-ID read_thread then worked, but list_threads still failed.

Current state after manual recovery:

• Direct read_thread by known canonical IDs works.
• list_threads still fails with No handler registered for tool: list_threads.
• One duplicate/orphan worker remains recorded and should not be used.
• The manager can only coordinate by known direct thread IDs, not by title/search discovery.

Expected behavior

Thread tools should have reliable, internally consistent behavior:

• If a thread-management tool is exposed in the tool surface, the backend handler should be registered and callable.
• If create_thread returns an error, it should not also create a thread silently.
• If thread creation is accepted but asynchronous, the result should return a pending ID/status or a durable operation ID that can be checked.
• A worker thread created from a valid prompt should not enter systemError before it can acknowledge the prompt.
• list_threads and direct read_thread should not disagree about the existence/reachability of freshly created child threads.
• send_message_to_thread should not report handler failure after actually delivering a message, or should return an explicit uncertain/pending status.

Impact

This breaks manager/worker workflows in Codex Desktop:

• Managers cannot safely deduplicate workers before creation.
• Retrying after a false create_thread error can create duplicate/orphan worker threads.
• Workers may exist but be invisible to list_threads.
• Direct IDs become the only safe control path.
• Durable external logs are required to avoid losing track of created workers.
• It is hard for users to know whether a thread action failed, succeeded, or succeeded after reporting failure.

Workaround used

I added a local delayed-verification workflow:

1. After create_thread returns an error or no ID, wait briefly.
2. Retry a narrow list_threads query if available.
3. If list_threads is unavailable, search recent local rollout/session records for unique title/prompt phrases.
4. Only mark a worker canonical after direct read_thread verifies the thread, cwd, and prompt.
5. Record duplicates/orphans separately.
6. Avoid creating replacement workers while canonical direct-ID reads work.

This is only a workaround. It cannot fix the underlying handler-registration/runtime inconsistency.

Requested fix

Please harden Codex Desktop thread-control semantics so that:

• advertised thread tools are backed by live handlers;
• create_thread is atomic or returns a durable pending operation;
• handler failures cannot mask successful creation;
• list_threads can discover threads that direct read_thread can read;
• newly created worker threads reliably initialize rather than becoming systemError until manually opened/prompted;
• send_message_to_thread has explicit delivered / not delivered / uncertain status semantics.

Local evidence retained

I recorded the incident locally in these workspace logs:

• wiki/logs/2026-07-05-hydroscope2-blind-create-fallback.md
• wiki/logs/2026-07-05-hydroscope2-worker-recovery-attempt.md
• wiki/logs/2026-07-05-hydroscope2-manual-worker-prompt-readback.md
• wiki/logs/2026-07-05-hydroscope2-chief-rereview-manual-workers.md
• wiki/outputs/hydroscope-like-groundwater-workbench-plan-2026-07-04/hydroscope-2-manager-dashboard.md

I can provide more exact thread IDs/timestamps if useful, but I have kept this report focused on the behavior rather than workspace-specific content.