Codex threads cannot keep Working while their own background commands run (t3_background_wait is Claude only) #30124

What happens

t3_background_wait keeps a thread in Working while its own background work runs. It is only offered to Claude threads (tool description: "Claude only"). Codex threads that start background commands have no way to mark them as awaited.

Background commands and monitors do not hold completion on their own, which makes sense because they might be long-running dev servers (backgroundWorkKindHoldsCompletion). So a Codex thread waiting on, for example, a test run in the background drops to Done in the sidebar while the work is still running and the task is not finished.

Expected

The same opt-in for Codex threads: either t3_background_wait as an MCP tool there too, or an equivalent way to mark a background command as awaited, so the thread stays in Working until that command exits.

Context

• t3 v0.1.2, Linux, self-hosted.
• For Claude threads, t3_background_wait with the command's task id works as described: the thread stays in Working and is woken when the command exits.
• Related but different: Delegated task reports finished while its child thread still has running work #16603, App-owned follow-up completes while nested work runs, then loses the final result #21837 (completion while nested work runs).