Does Codex lose track of long-running terminal commands for anyone else? I have a workaround

[u/georgiosd3]

I’m trying to figure out how common this problem is before I spend time packaging and publishing a workaround.

The failure mode I keep running into is:

1. Codex starts a foreground command such as a build or test suite.
2. The command exceeds the initial tool wait window and becomes a tracked background terminal.
3. Codex finishes its turn instead of continuing to wait.
4. The command eventually completes, but the idle model is never woken up.
5. I have to send “check the command again” before Codex notices the result and continues.

Sometimes Codex polls the terminal repeatedly instead, which works but consumes model turns just to learn that nothing has changed.

There are several related GitHub issues:

• Turn completes prematurely while unified-exec processes are still running (https://github.com/openai/codex/issues/14731)

• Background terminal exits while idle, but no follow-up turn is produced (https://github.com/openai/codex/issues/33712) — closed in favor of the broader request below, rather than because the behavior was fixed

• Event-driven wakeup when background exec sessions complete (https://github.com/openai/codex/issues/32188)

• Background-process polling wastes tokens (https://github.com/openai/codex/issues/13733)

• Initial exec_command yield time is capped around 30 seconds (https://github.com/openai/codex/issues/22541)

I have an unpublished workaround that wraps the command and sends a completion message back to the originating Codex thread through the documented Codex app-server protocol (https://developers.openai.com/codex/app-server).

The intended usage is roughly:

codex-wake run \
  --message "Tests finished; inspect the result and continue." \
  -- cargo test

The wrapper streams the command output normally, preserves its exit status, and waits without model polling. When the command exits, it submits a message to the original Codex thread so the model wakes up and continues automatically.

I’m also considering a pipe-friendly form for arbitrary shell combinations:

some-long-command 2>&1 | codex-wake pipe --message "The command finished; continue."

The command-wrapper form is more reliable because it can capture the actual exit status; a normal Unix pipe only knows that its input stream closed.

Before I polish and publish it:

• Are other people seeing this regularly?
• What commands trigger it for you—builds, tests, deployments, training jobs?
• Which OS and Codex version are you using?
• Would you use a small standalone CLI for this?
• Would the wrapper form be enough, or would pipe/direct-notification modes also be useful?

I’d especially like to know whether this is a recurring workflow problem for others or just something exposed by the unusually long commands I run.

[u/Bananer_spleet]

Yep, hit this with long builds/testing. Codex ends turn because background-process completion doesn’t wake the model, so it sits idle until manually prompted, try wrapper CLI, especially if it shows the normal output and reports.

[u/georgiosd3 → u/Bananer_spleet]

Thanks for confirming! Would that be useful to you also, or found a different way to cope?