Code Mode dispatch worker stops at sampling end while yielded cells still need subsequent tools #45945

What version of Codex CLI is running?

Installed upstream CLI: 0.154.0. Source inspection below is pinned to upstream main 4701aa4. The end-to-end fix validation was on a local fork; this is not a claim of a fresh stock-0.154.0 runtime reproduction.

What subscription do you have?

ChatGPT Pro

Which model were you using?

The proposed failure mechanism is in the tool dispatch lifecycle, rather than a specific model's output. Model for a fresh upstream reproduction: not yet recorded.

What platform is your computer?

Linux 7.0.0-31-generic x86_64 unknown

What terminal emulator and version are you using (if applicable)?

Not recorded.

Codex doctor report

Not collected for this source-level report.

What issue are you seeing?

A yielded Code Mode cell may remain alive after the assistant ends its turn, but subsequent nested tool calls cannot be dispatched while the thread is idle. The first already-dispatched tool can finish; the next awaited tool then waits for a receive worker from a later sampling request.

This is separate from automatically waking the model: even without any completion wake, the Cell's JavaScript should be able to finish sequential non-interactive tools while idle.

What steps can reproduce the bug?

Suggested minimal reproduction (stock-current-version runtime confirmation still pending):

1. In interactive CLI with Code Mode available, ask for one Cell containing the following JavaScript.
2. Have the assistant finish its turn after the Cell yields. Do not call wait or send another user message during the sleeps. Ensure each command is permitted without additional approval.
3. Observe whether the second command starts after the first returns, without another sampling request.

// @exec: {"yield_time_ms": 1000, "max_output_tokens": 1000}
const first = await tools.exec_command({
  cmd: "sleep 8", yield_time_ms: 10000, max_output_tokens: 100
});
text({step: 1, result: first});
const second = await tools.exec_command({
  cmd: "sleep 8", yield_time_ms: 10000, max_output_tokens: 100
});
text({step: 2, result: second});

The outer Cell yields after one second, but each inner tool has time to finish before its own yield. A deterministic regression should gate the first tool result until after the parent reaches idle, then assert that the second tool dispatches before any further model request. Our local fork has such an HTTP MCP regression, in addition to a manual two-sleep success test on the patched binary.

What is the expected behavior?

Ordinary nested tools requiring no new approval should continue until the live Cell completes, without keeping the model busy. This does not ask for idle approval UI, unlimited tool timeouts, or an automatic model continuation.

Additional information

Source inspection at the pinned upstream commit:

• Sampling request owns a local _code_mode_worker.
• Worker receive loop exits on shutdown.
• CodeModeDispatchWorker::drop sends shutdown.

These lifetimes explain the observed boundary in our investigation; the suggested stock repro above has not yet been rerun in this reporting session.

A possible approach is to retain the existing dispatch worker while unfinished Cells exist, releasing it on completion/teardown and respecting existing sampling-boundary replacement. Approval provenance and cancellation need explicit handling; retaining the worker alone exposes previously unreachable idle prompt paths.

Reference experiment: fork commit af1f26f725. This sits on top of separate completion-wake changes and is not an independent upstream-ready patch or a PR request.

Related, but distinct:

• Preserve yielded Code Mode execution cells across native goal continuations #34122 concerns lost Cell handles across native goal continuations.
• Nested Code Mode exec_command is invisible while running and appears after task_complete #40041 concerns visibility/order of nested command activity.
• Code-mode exec silently degrades a long-running command into a full-context model polling loop (34.6M tokens burned after the task already completed) #38495 concerns Cell completion push and polling cost.
• Event-driven wakeup when background exec sessions complete #32188 concerns waking on background command completion.