Unified exec: long-running background commands stops unexpectedly

Resolved 💬 6 comments Opened Feb 7, 2026 by vjain419 Closed Feb 9, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Bug report

With unified exec enabled (Codex 0.98.0), long‑running background commands stop unexpectedly. The process goes into "waited" state and /ps shows no command running in the background terminal.

Environment

  • Codex version: 0.98.0
  • Unified exec: enabled

Repro

1) Start a background command:

while true; do
  date; echo "---"; sleep 120; done

2) Observe output for ~10 minutes

Actual behavior

  • Command stops after ~10 minutes
  • Background process status becomes "waited"
  • /ps shows no command running

Expected behavior

  • Background command should continue running until explicitly stopped

Notes

This used to work in a previous version (unknown); appears to be a regression. The issue makes it impossible to keep long‑running background processes alive for hours.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 5 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #10860
  • #10767

Powered by Codex Action

jif-oai contributor · 5 months ago

Could you /feedback on such session and send me the session ID?

vjain419 contributor · 5 months ago

@jif-oai 019c2ae0-ce91-7191-b38b-90ff2d2f357a this is my reproduction attempt - let me know if that's helpful but you should be able to reproduce with what I mentioned above with simple while.

I think (actually codex by looking at codex) issue is when the job doesn't stream for 30s it finish the turn and soemhow close the terminal as well. But not an expert - Just tried asking codex what could be the issue.

jif-oai contributor · 5 months ago

Yes this is what I wanted to confirm. We recently introduced a new tool to run processes (called background terminals) and as part of this, as a first step, we decided to close all the processes at the end of a turn. So this is an expected behaviour.

But I merged earlier today the next step which will maintain processes alive across turns (and introduce a /clean to kill them). So you should see this being fixed as of the next release.

You can already test it on v0.99.0-alpha.10

vjain419 contributor · 5 months ago

@jif-oai I can confirm in latest release jobs are running in background but not sure implementation is very "token" friendly as it keep polling and reasoning about it instead of just waiting? if my job take hrs then it just wasting token in my point of view.

is it not possible to add config to change time for this polling so I can say wait for 2hr for every poll and max 8hr before killing?

• I'm confirming that the command may finish without output and that the current method returns
  the process exit status; I need to ensure the code waits for the process to fully exit before
  proceeding.

• Considering whether to check job status during long compile stages, but leaning toward waiting
  for current command completion to avoid complexity from parallel execs.

• I'll proceed with polling the job status to check progress and consider extending the
  compilation time if results remain unavailable.
jif-oai contributor · 5 months ago