Add blocking commands back optionally

Resolved 💬 3 comments Opened Mar 8, 2026 by dotdioscorea Closed Jul 1, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 5 months ago

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

#13733
#13141
#12921

Powered by Codex Action

JiaJunDeng5930 · 5 months ago

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:

default mode preserves current behavior
wait_until_exit = true waits until process completion
wait_until_exit = true does not convert the command into a background session
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.

etraut-openai contributor · 1 month ago

This feature request hasn't received enough upvotes, so it is being closed automatically. If you still feel this feature is needed, please open a new feature request with an updated title and description.