fix(codex): track code-mode status lifecycle

[kouyichi]

Summary

• recognize custom_tool_call and custom_tool_call_output events emitted by current Codex Code Mode
• keep turns active from task_started/user_message through task_complete, including automatic turns with no user message
• transition back to Thinking after the final tool result while a turn is still active
• report explicit user-input requests and completed turns as Waiting, with descendant CPU used only as a fallback
• preserve standard tool-call and asynchronous exec_command/write_stdin tracking
• derive current-task text from the final session status so Done and Unknown sessions retain consistent labels

Root cause

The collector treated every agent_message as the end of a turn and only parsed the older function_call event shape. Codex CLI 0.144.6 emits intermediate progress messages and routes Code Mode tools through custom tool-call events, so the parsed state frequently disagreed with the live turn.

Testing

• cargo clippy --all-targets -- -D warnings
• cargo test (207 unit tests and 1 doc test)
• manual abtop --json validation against active Codex CLI 0.144.6 sessions covering active tools, post-tool reasoning, completed turns, and request_user_input

Closes #160

[graykode]

Thanks for the comprehensive lifecycle work. The status ordering and custom tool-call tracking are generally well structured, and the full test suite, clippy, and release build pass locally. However, I found two blocking issues in the current Code Mode path.

1. The user-input wait detection does not match the event shape emitted by Code Mode. tool_waits_for_user checks the recorded tool name for request_user_input or AskUserQuestion, but current Code Mode records this as a custom_tool_call whose name is exec and whose input contains tools.request_user_input(...). call_names therefore stores exec, waiting_for_user remains false, and the open custom call is reported as Executing instead of Waiting. In sampled current rollouts, the user-input requests were custom-wrapped and there were no standalone function_call events for request_user_input. The new regression test uses the standalone function_call shape, so it does not reproduce the actual failure. Please add a fixture using custom_tool_call name exec with tools.request_user_input in input and make that path resolve to Waiting.

2. The new custom-tool branch copies the entire raw JavaScript input into ToolCall.arg after only secret-prefix redaction and a 120-character truncation. sanitize_tool_arg does not call sanitize_terminal_text and does not extract a bounded safe argument. This value reaches current_task, the TUI timeline, and JSON snapshots. Ordinary Code Mode inputs are multiline, and attacker-controlled ANSI/control or bidi characters can pass through as well; the raw source can also contain request bodies or other content that should not be treated as a short argument preview. Please sanitize terminal controls and bidi marks, and preferably extract only an allowlisted path or command preview. If a safe preview cannot be derived, display the tool name without the raw input. Add regression coverage for multiline input, terminal control characters, bidi marks, and sensitive inline content.

The lifecycle changes outside these two paths look sound. My requested changes are limited to matching the real custom-wrapped user-input event and keeping raw Code Mode source out of display and snapshot fields.

[graykode]

The custom-tool payload disclosure is fixed by 559dc1c: opaque inputs no longer reach task descriptions or tool argument previews, with regression coverage. The latest head is exactly that reviewed change merged with main, and CI passes. The previously noted custom-wrapped user-input detection remains a functional limitation (Executing instead of Waiting); I am treating it as a non-blocking follow-up rather than a security blocker. Approving this revision for merge.