Code-mode `exec` silently degrades a long-running command into a full-context model polling loop (34.6M tokens burned after the task already completed)

Summary

In code mode, when a script passed to exec outlasts the yield deadline, the CLI parks it as a numbered cell and hands control back to the model. There is no completion push and no timer — the only way to learn that the command finished is for the model to spend a turn calling wait(cell_id). Each such turn resubmits the entire conversation context.

The result is a busy-wait loop where "ask whether the process is done yet" costs exactly the same as "perform a full code analysis". In the session below, a single git worktree remove --force over a large directory tree (~9.5 minutes of real unlink time) produced 90 model turns, 21,610,789 input tokens and 3,837 output tokens — an input:output ratio of 5632:1 — and all of it happened after the agent had already delivered its result and written its report to disk.

This is the mechanism-level report behind the symptoms in #38335, #34115 and #38437.

Mechanism

1. Model emits tools.exec_command({cmd, yield_time_ms, max_output_tokens}).
2. Script exceeds the yield deadline (default 10000 ms). The CLI returns Script running with cell ID <n> — not an error, not a handle the runtime will follow up on.
3. Resumption is pull, not push. The model must emit wait({cell_id, yield_time_ms, max_tokens}) to learn anything.
4. Every wait is a full model turn: complete context re-sent, ~240k input tokens in, ~31 tokens out.
5. The loop is not idle. There is no schedule_wakeup and no timer event in the rollout — it is a continuous turn chain that also holds a concurrency slot for its whole duration.

Two consequences worth stating explicitly:

• exit_code cannot rescue this. Per the CLI's own contract, exit_code is present only "when the command finished during this call" — so while the process is genuinely still running, it is legitimately absent on every single poll. The model is being told the truth; the truth just costs 240k tokens to obtain.
• git worktree remove (like rm -rf) prints nothing while unlinking. "Deleting file 80,000 of 134,000" and "hung forever" are byte-identical from the model's point of view, so it has no basis on which to stop polling.

Observed incident

Session 019ffc35-8a14-76b3-bd0b-7e6bfe18b62c, plan prolite, 2026-08-14 17:39:56Z → 18:15:09Z.
Total: 275 turns / 54,701,161 tokens.

Timeline:

turn/record	event
638	task result written back (ok: true) — work complete
642	report artifact written to disk — deliverable complete
648	exec_command with a 7-statement cleanup compound, yield_time_ms: 30000
649	Script running with cell ID 88 / Wall time 11.0 seconds
651–663	wait{cell_id:"88", yield_time_ms:1000} × 5
664	Script completed
666	write_stdin({session_id: 1095, chars: "", yield_time_ms: 30000, max_output_tokens: 5000})
667	Script running with cell ID 89 / Wall time 11.0 seconds
668–931	16 byte-identical write_stdin execs + 67 wait calls, cells 89–98 and 103–107, every one at yield_time_ms: 1000, all returning net-empty output
932	model gives up and sends  (Ctrl-C) — 9.5 minutes later
935–938	task_complete

Note record 666: an inner yield_time_ms: 30000 nested inside a call whose own outer yield deadline is 10000 ms. The park is structurally guaranteed, every time.

The actual slow statement was the second of seven:

git -C repos/<repo> worktree remove ../../agent_workspace/<id>/worktrees/<name> --force

Filesystem forensics confirmed it was genuinely progressing, not deadlocked: the target tree still held 134,186 files (130,633 of them under node_modules), with node_modules mtime 02:13 and the package store mtime 02:14 — i.e. actively unlinking mid-poll. Statements 3–7 of the compound never ran.

Per-turn bills during the loop (token_count events):

rec  trigger  input     cached   output  total
662  wait     237,280   236,672      31  237,311
665  wait     237,339   236,672      31  237,370
668  exec     237,400   236,672      45  237,445
...
931  wait     242,794   241,792      31  242,825
937  exec     242,920   241,792     396  243,316

90 turns: input 21,610,789 / output 3,837
mean:     240,119 in / 42 out     ratio 5632:1

Input ratchets upward monotonically (237,280 → 242,920) because each poll writes itself into the history that the next poll must re-send. Every turn's entire product is 31 tokens: {"cell_id":"89","yield_time_ms":1000,"max_tokens":5000}.

Inter-call gaps are irregular inference latency, not a schedule — median 3.05 s, range 2.23–15.27 s (wait-preceding, n=72). There are zero schedule_wakeup, user_message, task_started or interrupt records after 648. And with yield_time_ms: 1000, the 67 waits spent a combined 67 seconds actually waiting, across 9.5 minutes of wall clock.

The escape hatch exists, and nobody can use it

I want to be precise here, because the fix is not "add a primitive". The primitive is already shipped:

// @exec: {"yield_time_ms": 120000, "max_output_tokens": 1000}

The CLI's own documentation even demonstrates it: "imagegen needs a few minutes to finish. In code-mode, use the first-line @exec directive to give the initial call 120 seconds and the same yield for any waits that follow." There is no documented upper bound — the only stated constraint is "must be non-negative safe integers".

Across 19,392 exec calls in my fleet's rollouts, the pragma was used 0 times.

That is the actual defect surface:

• The default (10000 ms) is far below the duration of ordinary filesystem and build operations.
• Exceeding it degrades silently into a paid polling loop instead of surfacing a handleable condition.
• Using the escape hatch requires knowing the command's duration before running it — precisely the thing you cannot know for rm -rf, bun install, git worktree remove, or any user-supplied tool.
• Resumption is pull-only, so the cost of not knowing is billed per turn at full context.

This is not a one-off

Same fleet, same rollout corpus:

• 8,752 MCP tool calls; 86 took ≥10 s; 70 of those 86 (81%) were parked into a cell. Each parked call then needed median 4 / mean 4.7 / max 13 wait turns to collect. 329 waits + 70 parked execs ≈ 399 turns of pure polling — on the order of 10^8 tokens at these context sizes.
• All 12 slowest calls were a single long-running tool endpoint. Any user who registers a slow MCP tool or shells out to an external CLI reproduces this by default.
• Global wait yield_time_ms distribution: 30000 → 2,516 calls, 1000 → 979 calls. The model frequently picks a 1-second poll interval against multi-minute work, which is the worst possible ratio. (I'll note honestly that this specific choice is model behavior — but the CLI is what makes a 1 s interval cost 240k tokens instead of being harmlessly cheap.)

Question about quota enforcement

In the same session, rate_limits.primary.used_percent progressed:

17:40:07   21,664 cumulative tokens    92.0%
17:46:01    4,176,704                  95.0%
17:53:23   14,271,350                  98.0%
17:57:08   20,084,287                 100.0%   <-- limit reached

The busy-wait loop did not begin until ~18:05 — 8 minutes after used_percent hit 100.0 — and the CLI accepted a further 18 minutes and ~34.6M tokens of requests, with rate_limit_reached_type reported as null on every event.

Is post-100% execution expected behavior? If the limit is a soft accounting boundary rather than an admission gate, that is a reasonable design — but combined with the polling loop above it means a single unattended slow command can spend multiples of a weekly allowance with no backpressure anywhere in the stack.

Expected behavior / asks

1. Push cell completion, or at minimum make the default yield adaptive (e.g. exponential backoff up to a bounded ceiling) so that N-minute commands do not cost N/interval full-context turns.
2. Raise the 10 s default, or apply the documented pragma value to follow-up waits automatically.
3. Include elapsed time and a liveness signal in the wait/park output so the model can distinguish "progressing" from "hung" and choose a sane interval. Right now both look like empty output.
4. Cap or warn on repeated identical polls — 16 byte-identical write_stdin calls in a row is trivially detectable.
5. Per-session usage telemetry surfaced to the user, so a runaway loop is visible before it consumes a plan rather than after.
6. Quota reset for the affected account. The 34.6M tokens were spent entirely after the task's result had been delivered and its artifact written, in a loop the model had no primitive to avoid and no signal to exit.

Environment

• macOS (Darwin 25.3.0), Apple Silicon
• Codex CLI in code mode, ChatGPT-plan auth, plan prolite
• Non-interactive codex exec, multiple concurrent sessions
• Evidence: rollout JSONL 019ffc35-8a14-76b3-bd0b-7e6bfe18b62c (identifiers redacted; happy to share the relevant token_count / custom_tool_call / function_call records on request)

Related

• #38335 — same class, maintainer-labeled rate-limits. I posted a condensed version of this trace as a comment there (https://github.com/openai/codex/issues/38335#issuecomment-5289676893); this issue exists so the mechanism is searchable under its own title rather than buried in a thread about quota symptoms. Its Reproduction B (external CLI delegation burning 2–3% of a weekly allowance in ~1 minute) and its two asks — "waiting for an external CLI or background process should not silently generate large amounts of model usage" and "automatic polling, retries or waiting should not repeatedly resubmit large contexts at significant quota cost" — are exactly the mechanism documented above.
• #34115 — empty write_stdin polling of a live background process; explicitly mentions rm -rf cleanup routing.
• #38437 — 56.4M tokens / 2.59B cached.
• #36827, #38093, #38453, #38367, #38480 — related quota-burn reports.

Start by tracing the code-mode exec_command, wait, and write_stdin paths that create and poll numbered cells; the issue names no source files or tests. Compare the current 10-second yield behavior with the documented @exec directive, and define done around preventing runaway full-context polling while preserving command completion behavior.