›_ Codex Issues
Codex Issues / #22541

exec_command yield_time_ms is ignored or capped around 30s on initial command

Open 💬 6 comments Opened May 13, 2026 by janbambot

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:

  1. Run date --iso-8601=seconds.
  2. Run sleep 120 with yield_time_ms: 60000.
  3. Observe when the first tool call yields.
  4. Continue polling the returned session with functions.write_stdin and yield_time_ms: 60000.
  5. Run date --iso-8601=seconds after completion.

Observed result

  • Start time: 2026-05-13T21:07:46+02:00
  • Initial exec_command yielded after about 30.0012s, while sleep 120 was still running
  • First write_stdin poll yielded after about 60.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.

View original on GitHub ↗

6 Comments

LachlanStuart · 1 month ago

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:

  • Wake up the agent to check on the result every 30s - the agent will get impatient and probably cancel the task to try to run it a different way.
  • Give the agent explicit instructions to use the other tool (write_stdin) which has a higher 5 minute timeout - slightly better, but annoying having to negotiate with GPT so much to make a reliable skill.
  • Have the agent ignore the yield - but they'll never get a notification when the process ends.
liyishuai · 1 month ago

Root cause traced

The 30s hard cap on exec_command's yield_time_ms was introduced in PR #5442 (chore: align unified_exec, merged 2025-10-22). That commit added both clamp_yield_time() and MAX_YIELD_TIME_MS = 30_000 in codex-rs/core/src/unified_exec/mod.rs.

PR #12228 later raised the write_stdin empty-poll ceiling from 30s to 300s but left the initial exec_command call still routed through the old clamp_yield_time() → 30s path.

The initial exec_command is semantically identical to an empty write_stdin poll (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: replace clamp_yield_time(request.yield_time_ms) with the same clamp logic used for empty write_stdin polls at line 682.

goyiii44545-gif · 1 month ago

g gg goblins?
https://youtu.be/Q4Jzi_ohntg

liyishuai · 1 month ago

@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 · 19 days ago
@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.

My precious, it is a duplicate

liyishuai · 16 days ago

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.