Add blocking commands back optionally

[dotdioscorea]

What variant of Codex are you using?

CLI

What feature would you like to see?

Originally all Codex CLI interactions were blocking, until the optional experimental background tasks feature was added. Since then, this has been made the default, and AFAIK the option to disable has been removed.

This is proving extremely difficult for many of my projects. I have quite a few builds and test suites which take a long time to run, think 10 minutes upwards of a few hours. This never used to be a problem, but these days, the agents constantly poll them. Firstly, this wastes tokens, but secondly, I find they nearly always get impatient and end up self sabotaging, trying stupid tricks to speed up the process, stopping and restarting them. I just need them to be blocked until the process finishes. Its thousands of source files compiling, it just needs to wait.

It would be nice to reintroduce the option to disable background tasks. Or even better, add a filter list of blocking commands, so I could make known long executions like cmake, ctest, waiting for CI through MCPs, block, but preserve the current background task behaviour for other tasks.

Especially with 5.4, it is painful watching Codex constantly fidgeting and compromising long running commands.

Additional information

No response

[github-actions]

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

• Background process polling wastes tokens: each write_stdin poll triggers full API turn with complete history #13733
• CLI agent defaults to detached launch (nohup/setsid) and does not reliably preserve foreground preference #13141
• Remove awaiter #12921

Powered by Codex Action

[JiaJunDeng5930]

I think this issue can be addressed with a relatively small runtime change.

I suggest adding an optional field to exec_command, for example:

{
  "wait_until_exit": true
}

The default would be false, so existing behavior stays unchanged.

Proposed semantics

When wait_until_exit = true:

• exec_command keeps waiting until one of the following happens:
  • the process exits
  • the current turn is interrupted / cancelled
  • another existing runtime termination path is triggered
• in normal success / failure cases, the tool result is only returned after the process has actually exited
• in this mode, the command should therefore not be converted into a background session

When wait_until_exit = false:

• keep the current behavior unchanged

Design split

The responsibilities can be separated cleanly:

• runtime provides an explicit capability: wait_until_exit
• agent prompts / tool usage guidance decide which commands should preferentially use that capability

That keeps the execution primitive and the command-selection policy separate.

High-level implementation shape

At a high level, this seems fairly localized:

• add a new optional parameter to exec_command
• thread it through the unified exec request path
• in the unified exec wait loop, use that parameter to decide whether to continue waiting for process exit
• still allow interrupt / cancel to break the wait

Expected tests

If this direction is acceptable, I think the minimum test coverage would be:

1. default mode preserves current behavior
2. wait_until_exit = true waits until process completion
3. wait_until_exit = true does not convert the command into a background session
4. interrupt / cancel still terminates the wait promptly

If maintainers think this direction makes sense, I’d be happy to help refine the implementation boundaries further in-thread.