Codex 0.144.6 status detection misses Code Mode lifecycle events

[kouyichi]

Environment

• abtop 0.5.3
• Codex CLI 0.144.6
• Linux

Problem

Codex session status frequently flips to Waiting while a turn is still active, and some waits are shown as Executing.

Current Codex Code Mode rollouts use response_item.custom_tool_call and custom_tool_call_output, while the collector only tracks function_call and function_call_output. The rollout also emits intermediate agent_message events before continuing to reason or invoke another tool, but the collector currently treats every agent_message as the end of the active turn.

This causes several observable errors:

• Code Mode tool calls are absent from the timeline and can be reported as Waiting while executing.
• A progress agent_message closes the Thinking window even though the same turn continues.
• After a tool result, continued model reasoning can be reported as Waiting.
• A pending request_user_input call is reported as Executing instead of Waiting.
• Busy persistent children such as codex-code-mode-host can override explicit rollout state and report Executing after a turn has completed.
• Automatic/subagent turns that start with task_started but have no user_message never enter Thinking.

Expected behavior

Explicit rollout lifecycle events should take precedence over CPU heuristics:

1. A completed turn or an explicit user-input request is Waiting.
2. An open ordinary tool call is Executing.
3. An active turn with no open tool is Thinking.
4. Descendant CPU activity is only a fallback when the rollout has no explicit active state.

Both standard and custom tool-call event forms should participate in the same lifecycle and timeline tracking.

Reproduction

1. Start abtop 0.5.3 and Codex CLI 0.144.6 with Code Mode enabled.
2. Ask Codex to inspect a repository and run several commands.
3. Observe abtop after an intermediate progress message and between a tool result and the next action.
4. Trigger request_user_input and observe that it is shown as Executing.

The status differs from the actual rollout state in each case above.