Repository navigation
exec_command yield_time_ms is ignored or capped around 30s on initial command #22541
Description
What happened
We tested functions.exec_command with a long-running shell command and yield_time_ms set to 60000. The first call yielded after about 30 seconds instead of waiting up to 60 seconds. Follow-up polling through functions.write_stdin did respect a 60-second wait more closely.
This is annoying in practice because agents trying to run patient terminal work get bounced early into session-polling mode. The dev goblins in the OpenAI caves appear to have installed an initial-command impatience valve.
Reproduction
Environment observed by Codex:
- OS: Ubuntu 24.04.04 LTS
- Shell command tool:
functions.exec_command - Command:
sleep 120 yield_time_ms:60000
Steps:
- Run
date --iso-8601=seconds. - Run
sleep 120withyield_time_ms: 60000. - Observe when the first tool call yields.
- Continue polling the returned session with
functions.write_stdinandyield_time_ms: 60000. - Run
date --iso-8601=secondsafter completion.
Observed result
- Start time:
2026-05-13T21:07:46+02:00 - Initial
exec_commandyielded after about30.0012s, whilesleep 120was still running - First
write_stdinpoll yielded after about60.0014s, while the process was still running - Final poll completed after about
24.6617s - End time:
2026-05-13T21:09:52+02:00
Total elapsed wall time was about 126 seconds, which is plausible for sleep 120 plus tool overhead. The problem is specifically the initial yield happening at ~30 seconds despite the requested 60-second yield window.
Expected result
If yield_time_ms is set to 60000, the initial exec_command call should wait up to roughly 60 seconds before yielding, unless the process exits sooner.
If there is an intentional hard cap around 30 seconds for initial command execution, it should be documented in the tool schema or surfaced clearly so agents can plan around it instead of discovering the goblin with a stopwatch.
Why this matters
Long-running terminal work is normal for coding agents: builds, tests, dev servers, downloads, migrations, and slow integration checks. Inconsistent yield behavior makes progress reporting and command orchestration harder than necessary.
Please either make initial exec_command honor yield_time_ms consistently, or document the cap explicitly. The current behavior is a tiny papercut with steel-toed boots.
Activity
LachlanStuart commentedon Jun 11, 2026
This limit is making it impossible for me to use Codex for orchestrating long-running processes, such as multi-hour model training runs.
It does seem to be documented now. GPT-5.5 seemed aware of the limitation, it just could not find a way to work around it. The options now seem to be:
liyishuai commentedon Jun 12, 2026
Root cause traced
The 30s hard cap on
exec_command'syield_time_mswas introduced in PR #5442 (chore: align unified_exec, merged 2025-10-22). That commit added bothclamp_yield_time()andMAX_YIELD_TIME_MS = 30_000incodex-rs/core/src/unified_exec/mod.rs.PR #12228 later raised the
write_stdinempty-poll ceiling from 30s to 300s but left the initialexec_commandcall still routed through the oldclamp_yield_time()→ 30s path.The initial
exec_commandis semantically identical to an emptywrite_stdinpoll (fire-and-forget output collection, no stdin interaction), so it should use the same configurable upper bound (max_write_stdin_yield_time_ms, default 300s).The fix is a 2-line change in
process_manager.rs:452: replaceclamp_yield_time(request.yield_time_ms)with the same clamp logic used for emptywrite_stdinpolls at line 682.goyiii44545-gif commentedon Jun 15, 2026
g gg goblins?
https://youtu.be/Q4Jzi_ohntg
liyishuai commentedon Jun 18, 2026
@etraut-openai You should not have closed #23603 by saying "Codex already supports hooks." It is a "duplicate", not "completed".
The issue still exists, and is impacting all long tasks that require polling on the external world.
goyiii44545-gif commentedon Jul 1, 2026
My precious, it is a duplicate
liyishuai commentedon Jul 4, 2026
FWIW, I wrote a plugin that hijacks bash commands and executes them inside the hook. Codex then executes a print and exit command that replays the original command's output and return code: https://github.com/liyishuai/Lys-marketplace
Issues/PRs welcome. AI contributions welcome.