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

[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.