Background process polling wastes tokens: each write_stdin poll triggers full API turn with complete history

[jitlabs-sg]

Problem

When a background process is running (e.g. cargo build, cargo test), Codex enters a polling loop where each status check triggers a full API round-trip with the entire conversation history. This burns tokens/credits proportional to history size × poll count, even though no meaningful work is being done.

Root Cause (from source analysis)

The turn loop in codex.rs:4869 works as follows:

1. Model issues exec_command → local process spawns → partial output returned
2. needs_follow_up = true (stream_events_utils.rs:133)
3. Loop back → clone_history().for_prompt() sends full history to API (codex.rs:4901-4905)
4. Model sees process still running → issues write_stdin with empty input to poll
5. process_manager.rs waits MIN_EMPTY_YIELD_TIME_MS (5s) then returns "(no new output)"
6. needs_follow_up = true again → goto step 3

Each poll = 1 full API request with complete conversation history. A 60-second cargo build generates ~12 polling turns. With 250+ items in history, this is extremely wasteful.

The model also "reasons" about whether to wait or do something else during each poll, consuming additional output tokens for no useful purpose.

Observed Behavior

From proxy debug logs, a single Codex session shows items growing: 237 → 239 → 242 → ... → 300+ over routine tool calls. Each turn re-transmits the entire history. During background waits, the cadence is ~10s per poll with no substantive new content.

Confirmed by Community

Issue #10957 reporter noted:

"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"

Proposed Solutions

Option A: Local wait before API turn (preferred)

When write_stdin returns no new output and the process hasn't exited, do not set needs_follow_up = true. Instead, wait locally (30-60s configurable) and only re-poll the API when:

• The process produces new output, OR
• The process exits, OR
• A timeout expires

This could be implemented in the tool handler layer — if write_stdin response has no output and no exit code, sleep locally before returning, rather than bouncing back to the model.

Option B: Increase MIN_EMPTY_YIELD_TIME_MS

Change MIN_EMPTY_YIELD_TIME_MS from 5s to 30-60s for truly empty polls. This is a minimal change but still wastes one API turn per interval.

Option C: Batch tool results

When the model issues write_stdin for a process that has no new output, return the tool result without setting needs_follow_up. The model only gets called again when the process finishes or produces output (via a notification/callback mechanism).

Environment

• Codex CLI via Responses API proxy
• Observed on both macOS and Windows (Windows worse due to slower builds)
• History sizes: 200-300+ items typical for medium sessions
• GAC (proxy) bills per payload KB, making this especially costly

Related Issues

• Unified exec: long-running background commands stops unexpectedly #10957 — unified exec background commands + token inefficiency
• Background tasks keep spinning independently w/o way to kill them #8656 — background tasks spinning independently
• Token usage spikes too quickly in Codex CLI sessions #6113 — token usage spikes
• Background Terminal Sessions #3968 — background terminal sessions

[github-actions]

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

• A way to limit command executon tokens #11629

Powered by Codex Action

[vjain419]

Please multiple team member sees this issue best workaround I found is use a subagent to not mess up with main agent context.

[happyme531]

I completely agree with this issue, but the token waste is only half the problem. The biggest dealbreaker here is that the AI literally "loses patience" and abandons long-running tasks.

While the token burn is awful, the current polling behavior completely breaks down on heavy, time-consuming commands (like a large compilation or a massive test suite that takes 20-30 minutes).

Here is what happens:

• The agent starts the command in the background.
• It polls write_stdin 10 to 15 times over the span of a few minutes.
• Because the process is still running and returning nothing new, the AI agent gets "impatient" (likely hitting a maximum iteration limit or hallucinating that the process is hung).
• It abruptly stops checking, assumes the task failed, or just drops the context entirely.

It is incredibly frustrating to wait for a 30-minute build, only to realize the AI gave up on monitoring it 5 minutes in.

For single, synchronous, or known long-running tasks, the agent should stop abusing the background terminal feature, and simply execute them in the foreground.

[miraclebakelaser]

@jitlabs-sg can't you already do option B with background_terminal_max_timeout in config.toml?

[kcosr]

• It polls write_stdin 10 to 15 times over the span of a few minutes.

You're lucky. It's polling every second (yield_time_ms=1000) by default for my tasks. I can't use it for background tasks that don't produce frequent output. I've even added heartbeat output and the model ignores it and aborts because "it's taking too long to get the final output."

[robertmsale]

All of the reasons everyone put in this issue are extremely valid and relevant, but I would like to add something to this.

I found a workaround by using MCP servers for long-running commands, but the problem is you have to develop your own sandboxing and agent thread bookkeeping. Basically, the only way to ensure long-running commands run until completion is by routing them through an MCP server that can be abused or avoided, or just create a bunch of friction.

They should at least allow a config to raise the minimum yield time so that we can raise it to whatever we want, such as 2 billion years. That would be better than the way it currently works.

[robertmsale]

You guys are gonna get a kick out of this.

• New skill: https://github.com/robertmsale/.codex/tree/main/skills/command-execution
• New MCP: https://github.com/robertmsale/.codex/tree/main/mcp/command-execution
  ^^^ Outdated

Codex searches your PATH for the shell you're using, and assigns that path to the PTY that the agent will use for the rest of the program. There is no configurable way to change the polling frequency, and in unified_exec=false mode there is no way to raise the command execution cap beyond 10 minutes (also the agent can set arbitrarily low timeouts, which it does fairly often, and runs the command multiple times up to the 10 min cap before giving up or deciding the timeout is a codebase issue and tries to fix non-problems). However, you can trick Codex (the application) into loading a shell that produces a job ID with every command execution that the agent sees, and with the MCP server they can pass that job ID and wait until that command completes. On mac the process looks like this:

1. Create a folder somewhere (e.g. /opt/homebrew/shim on my system)
2. Symbolically link the launch-job script, essentially a passthrough to zsh with recursion-safe job ID wrapper into that folder as zsh
3. Launch codex with env PATH="/path/to/shim:$PATH" codex

The skill instructions tell them that all commands produce a job ID whether they like it or not, and if the command is not finished they use the MCP to wait until the command finishes. Set the tool call timeout to some absurdly high value and that's all she wrote!

Past couple days have been using this with extremely good results. Wasting tokens is not the biggest issue, as others have pointed out, it's the decisions the agent makes when a process runs for what they perceive as "too long", and no amount of prompt engineering seems to prevent them from eventually terminating a good process (besides tediously steering the agent). Also this prevents the spinlock/reawakening so it really does save tokens.

Anyways, figured I'd share this little workaround incase OpenAI decides to close this as not planned (lack of votes or otherwise), or it just takes months to land on an agreed solution + implementation. Not practical, preserved for historical reference only

Looks like this in practice: