Nested Code Mode exec_command is invisible while running and appears after task_complete

What version of Codex CLI is running?

codex-cli 0.149.0

What subscription do you have?

ChatGPT Pro

Which model were you using?

gpt-5.6-sol (local model metadata: tool_mode = "code_mode_only")

What platform is your computer?

Linux 7.1.3-arch1-3 x86_64 unknown (Arch Linux)

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

kitty (TERM=xterm-kitty), no tmux or Zellij

Codex doctor report

codex doctor --json reports overallStatus: "ok". Relevant details:

{
  "codexVersion": "0.149.0",
  "auth mode": "chatgpt",
  "config parse": "ok",
  "model": "gpt-5.6-sol",
  "platform": "linux-x86_64",
  "install method": "standalone",
  "terminal": "kitty",
  "state DB integrity": "ok",
  "rollout DB parity": "ok",
  "latest version": "0.149.0",
  "latest version status": "current version is not older"
}

The full path-redacted doctor report can be provided if needed.

What issue are you seeing?

A shell command invoked as a nested Code Mode call can execute without any command activity being shown at the point where it starts. If the command outlives the nested exec_command yield and the outer functions.exec cell returns without polling the returned session, the assistant can continue through commentary and a final answer. The TUI's Ran ... record then appears much later, outside its chronological position, or is effectively omitted from the visible turn.

This is an auditability problem: whether the user sees that a command was launched depends on whether model-authored JavaScript notices and polls a returned session_id.

In the observed thread, the rollout contained no CommandExecution start item for the affected command. It contained only an item_completed(CommandExecution) record after the process ended, and that record was persisted after task_complete.

A second nested command that completed immediately produced its CommandExecution item in the expected part of the turn, which isolates the problem to the yielded/long-running lifecycle.

What steps can reproduce the bug?

1. Start Codex CLI 0.149.0 with gpt-5.6-sol.
2. Have Code Mode execute JavaScript equivalent to:

const r = await tools.exec_command({
  cmd: "sleep 20; echo repro-marker",
  yield_time_ms: 10000,
  max_output_tokens: 1000
});
text(r.output);

1. Do not poll the session_id returned by the nested tool. Let the assistant continue with commentary and finish the turn.
2. Observe that the TUI does not show the shell command when it starts. Its completed Ran ... entry may arrive only after the turn has completed and therefore appears out of chronological context or not at all in the visible turn.

Observed real-session timeline (UTC):

00:46:02.303  commentary: filesystem search starting
00:46:08.136  outer custom_tool_call functions.exec
00:46:18.492  outer custom_tool_call_output after 10.3 s, containing partial stdout
00:46:21.141  next commentary: "Found it"
00:46:25.443  second, quick functions.exec call
00:46:25.497  second call's CommandExecution item_completed (correct position)
00:46:29.648  task_complete
00:46:47.794  first call's CommandExecution item_completed

The late command record reported:

started_at:   00:46:08.480
completed_at: 00:46:47.794
duration: 39.311607297 s
source: unified_exec_startup
status: failed (exit 1)

The outer Code Mode result had returned to the model after 10.3 seconds, while the nested shell process continued for another ~29 seconds.

Thread ID: 01a026ee-2681-7531-924f-87ac3d3086f8. The complete rollout can be provided privately if needed.

What is the expected behavior?

User-visible command activity should be independent of model polling behavior:

• Emit and render a command-start item as soon as any nested exec_command is dispatched.
• Keep the command at its original chronological position.
• Update that existing item when output or terminal status arrives.
• Preserve and render terminal status even if it arrives after the model has continued or the turn has completed.
• Never make command visibility depend on whether model-authored Code Mode JavaScript prints or polls a returned session handle.

Incorrect model orchestration may affect whether the model consumes the final result, but it should not affect the user's audit trail.

Additional information

Local feature state showed code_mode = false, code_mode_host = true, and unified_exec = true; the selected model's catalog metadata forced code_mode_only.

Related but not duplicate:

• #38495 covers the long-running Code Mode yield/polling mechanism and lack of completion push, primarily as a token-consumption issue.
• #12278 covered unified-exec commands disappearing from the TUI, but was closed and diagnosed a different cause: call_id mismatch handling in an active ExecCell.
• #29122 covers broader long-running Code Mode lifecycle problems, mainly for MCP/IDE calls.

This report is specifically about command-start visibility, chronological ordering, and preserving an audit trail when a nested shell command outlives its outer Code Mode cell.