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

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:

• #28080 - Desktop thread tools intermittently lose handlers
• #29886 - send_message_to_thread reports failure while delivery may have succeeded
• #29275 - new thread creation fails silently / reports errors while thread exists
• #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:

``text
No handler registered for tool: list_threads
``

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

1. create_thread for the first worker returned:

``text
No handler registered for tool: create_thread
``

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

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

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

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

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

1. 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.