Codex Desktop create_thread from an SSH-host executor can spawn children on local host and lose completion handoffs #30626

What version of the Codex App are you using (From "About Codex" dialog)?

Codex Desktop app: 26.623.70822 (released 2026-06-29).

Observed in affected SSH session metadata:

• Codex Desktop originator
• SSH-side Codex CLI active in the incident: 0.142.3
• affected session cli_version: 0.142.3
• clarification: the SSH-side CLI process had not yet been restarted after the update to 0.142.4, so the active runtime for this incident was still 0.142.3

What subscription do you have?

Unknown from the agent/tool context.

What platform is your computer?

Codex Desktop with connected SSH projects/hosts.

Sanitized topology:

• Parent/executor thread was running on a remote SSH host, hostId=remote-ssh-discovered:<host>, cwd=/root.
• Two child threads were created on the local desktop host instead, hostId=local, with Windows-style Codex work directories.
• A third related child thread was created correctly on the remote SSH host.

What issue are you seeing?

When a Codex Desktop thread running on an SSH project/host acts as a thread executor/orchestrator and creates worker threads, some children can be created on the local desktop host instead of the same SSH host as the executor.

In the observed incident, the executor was on an SSH host and attempted to split work into background child threads. The resulting topology was mixed:

• Executor: remote SSH host, thread id prefix/suffix 019f152e...05ed8
• Child A: local host, thread id prefix/suffix 019f1547...dab2
• Child B: local host, thread id prefix/suffix 019f1547...dd5
• Child C: remote SSH host, thread id prefix/suffix 019f1548...9519

This was surprising because the executor itself was running on SSH and the task context/path only made sense on the remote host. The two local children did not have the remote checkout/runtime available, so they had to reason around the missing remote environment instead of directly auditing the intended system.

There was a second coordination failure: completion handoffs were not reliably sent back to the executor automatically. The local child threads received codex_delegation inputs containing a source_thread_id, completed their work, but the executor only received the handoffs after manual user intervention asking the children to call send_message_to_thread to the source/executor thread. One nested remote child also needed a manual correction before its report reached the executor directly.

This makes cross-thread orchestration unreliable in SSH projects: workers may run on the wrong machine, and the parent may stall or continue without all worker reports unless the user notices and manually routes the handoff.

What steps can reproduce the bug?

A minimal sanitized reproduction shape:

1. In Codex Desktop, open or create a thread on a saved SSH project/host.
2. Ask that SSH-host thread to act as an executor and create multiple background worker threads for the same remote project/runtime.
3. Have the executor create child threads with create_thread for read-only worker tasks. In the observed case there was no matching local project for the remote repo, and some children were created as projectless/local threads while one related child was created on the SSH host.
4. Let the children complete.
5. Inspect thread list / thread metadata.

Actual observed result:

• Parent/executor stayed on hostId=remote-ssh-discovered:<host>.
• Two direct child workers appeared under hostId=local with Windows local Codex work directories.
• One related nested worker appeared on the remote SSH host.
• Local workers lacked access to the remote Linux checkout/runtime.
• Workers did not all send completion notices back to the executor without manual user prompts to call send_message_to_thread.

What is the expected behavior?

For thread orchestration started from an SSH-host executor:

1. Child threads should default to the executor's current host/project unless the tool call explicitly selects another host.
2. If the app cannot infer the remote host/project, create_thread should fail closed or require an explicit host/project selection rather than silently creating local children.
3. create_thread results should expose enough host/thread identity for the parent to know where each child actually landed.
4. A child spawned via codex_delegation with a source_thread_id should have a reliable built-in way to report completion to the source thread, or the product should make explicit that manual send_message_to_thread is required.
5. If send_message_to_thread needs a hostId, the delegation/source metadata should preserve enough host context to route the response without guessing.

Additional information

Related or adjacent issues I found before filing:

• Remote-started Codex thread does not receive codex_app thread-management tools #26907: remote-started threads missing thread-management tools. Adjacent, but this report is about child thread placement across local vs SSH hosts after the executor already has thread tools.
• Codex App create_thread returns pendingWorktreeId without an addressable threadId #26861: create_thread returning pendingWorktreeId without addressable threadId. Adjacent lifecycle issue.
• send_message_to_thread reports handler error even when delegation is delivered #29886: send_message_to_thread may report handler error despite delivery. Adjacent delivery/ack issue.
• Expose non-interrupt queued delivery for cross-thread send_message_to_thread #30499: request for non-interrupt queued send_message_to_thread. Adjacent completion-routing issue.
• Desktop app: explicit cross-thread orchestration over existing thread/* and turn/* primitives #14923: broader cross-thread orchestration request.

Sanitized evidence was checked through list_threads / read_thread only. I am intentionally not attaching raw logs, full prompts, repository paths beyond generic host/cwd shape, business data, secrets, or full thread contents.