Unified exec: long-running background commands stops unexpectedly #10957

Activity

1. vjain419

   changed the title [-]Unified exec: long-running background commands stop after ~10 minutes (regression?)[/-] [+]Unified exec: long-running background commands stops[/+] on Feb 7, 2026
2. vjain419

   changed the title [-]Unified exec: long-running background commands stops[/-] [+]Unified exec: long-running background commands stops unexpectedly[/+] on Feb 7, 2026
3. github-actions commented on Feb 7, 2026

   

   github-actionsbot

   on Feb 7, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Background processes started with nohup are killed at turn end in codex-cli 0.97.0–0.98.0; setsid survives #10860
   • codex no longer able to run non-background tasks broke my workflow #10767

   Powered by Codex Action
4. jif-oai commented on Feb 7, 2026

   

   jif-oai

   on Feb 7, 2026

   Contributor

   More actions

   Could you /feedback on such session and send me the session ID?
5. vjain419 commented on Feb 9, 2026

   

   vjain419

   on Feb 9, 2026

   ContributorAuthor

   More actions

   @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.
6. jif-oai commented on Feb 9, 2026

   

   jif-oai

   on Feb 9, 2026

   Contributor

   More actions

   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

   ❤️React with ❤️1Reacted by vjain419

   🚀React with 🚀1Reacted by vjain419
7. jif-oai

   closed this as completedon Feb 9, 2026
8. vjain419 commented on Feb 10, 2026

   

   vjain419

   on Feb 10, 2026

   ContributorAuthor

   More actions

   @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.
   

   👍React with 👍1Reacted by kshramt
9. jif-oai commented on Feb 19, 2026

   

   jif-oai

   on Feb 19, 2026

   Contributor

   More actions

   #12228