codex - 💡(How to fix) Fix exec_command yield_time_ms is ignored or capped around 30s on initial command [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#22541Fetched 2026-05-14 03:34:41
View on GitHub
Comments
0
Participants
1
Timeline
2
Reactions
0
Author
Participants
Timeline (top)
labeled ×2

Root Cause

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.

RAW_BUFFERClick to expand / collapse

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.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix exec_command yield_time_ms is ignored or capped around 30s on initial command [1 participants]