What version of Codex CLI is running?

v0.118.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.4 high

What platform is your computer?

Linux x86_64

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

tmux

What issue are you seeing?

I hit a bad TUI/runtime state around subagent switching.

The important operator action is that I was switching between the subagent and the main agent via /agents.

After the child subagent completed, the parent/main thread ended up in a stale busy-looking state instead of cleanly recovering.

From the user side this looked like the app hung or crashed while leaving the screen in a state that still suggested work was ongoing.

What I observed locally on the affected tmux pane:

• the pane content still contained repeated Waited for background terminal lines from the earlier work
• the final assistant response from the parent thread was already printed
• the normal prompt was visible again at the bottom
• but the tmux pane title remained stuck at ⠧ home (busy spinner title) and did not clear
• the title stayed exactly ⠧ home across repeated checks over multiple seconds, instead of returning to a non-busy title
• the Codex process remained alive
• a stale child process was still present:
  • systemd-inhibit --what=idle --mode=block --who codex --why "Codex is running an active turn" -- sleep 2147483647
• that inhibitor was still alive more than an hour after the turn had already completed

So even if the backend believes the turn finished, the TUI/runtime busy-state cleanup did not happen correctly.

This is not just “the turn completed and I did not want it to” (although from the operator side it did feel wrong). The concrete bug is that the CLI was left in a contradictory state:

• visible prompt is back
• parent turn has completed
• but busy indicators and the active-turn idle inhibitor are still stuck as if a turn were running

What steps can reproduce the bug?

I do not yet have a minimal deterministic repro, but the sequence that triggered it was:

1. Start Codex CLI in tmux.
2. Use a workflow that spawns/uses a subagent.
3. Switch between the child and main thread via /agents.
4. Switch back to the main thread and wait for the child subagent to complete.
5. Observe that after completion, the main thread can be left in a stale state:
   • the screen still looks like it was working recently (Waited for background terminal still visible)
   • the tmux pane title remains stuck on a busy spinner
   • an active turn systemd-inhibit child remains alive
   • the process is alive, but the session no longer feels cleanly interactive from the user perspective

Affected top-level thread ID:

• 019d61b9-5b70-78e2-9a11-56ebcfd12bba

Child subagent completion was delivered into that parent thread via <subagent_notification>.

What is the expected behavior?

After subagent completion and return to the main thread, Codex should do one of these consistently:

• keep the parent turn active and visibly keep waiting, or
• complete the parent turn and fully clear all busy state

It should not leave the session in a contradictory half-finished state where:

• the prompt is back,
• the backend turn is complete,
• but the busy spinner/title and the Codex is running an active turn inhibitor are still stuck.

Additional information

Concrete local evidence from this incident:

• parent thread rollout recorded task_complete at 2026-04-06T10:55:05.491Z
• affected tmux pane title remained:
  • ⠧ home
• repeated checks over ~6 seconds showed the title was still unchanged:
  • t0: ⠧ home
  • t+3s: ⠧ home
  • t+6s: ⠧ home
• the stale inhibitor process remained present long after completion:

systemd-inhibit --what=idle --mode=block --who codex --why Codex is running an active turn -- sleep 2147483647

Related but not identical issues:

• #11472 (sub-agent shutdown / parent restoration)
• #12033 / #14303 / #14314 (stale Waiting/Waited for background terminal state)
• #12645 (tmux TUI/input stuck after completion)

My current guess is that this is another turn-lifecycle cleanup bug in the TUI/runtime layer, possibly triggered specifically by the /agents thread-switch path around subagent completion boundaries.