Raise the default wait_agent deadline from 30 seconds to 5 minutes

Resolved 💬 2 comments Opened Jul 31, 2026 by shaswatshah Closed Jul 31, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What feature would you like to see?

Raise the default wait_agent deadline from 30 seconds to 5 minutes:

  • MultiAgentV2: change DEFAULT_MULTI_AGENT_V2_DEFAULT_WAIT_TIMEOUT_MS from 30_000 to 300_000.
  • Legacy multi-agent, while supported: change DEFAULT_WAIT_TIMEOUT_MS from 30_000 to 300_000, or document why its default should intentionally differ.

This is the default used when the model omits timeout_ms; explicit values and the existing configurable min/max bounds should continue to work.

Why?

Thirty seconds is much shorter than many normal delegated coding, research, build, and test tasks. When the child is still running, the timeout returns control to the parent model, which commonly issues another wait. Each expiry can therefore create another model sampling turn over a large parent context.

The timeout is not needed for completion responsiveness. Both implementations already wait on notifications:

  • V1 subscribes to each child status receiver and returns when a terminal status arrives.
  • V2 subscribes to parent mailbox activity and returns when completion, another agent message, or steered user input arrives.

A child that completes after two minutes therefore wakes an active five-minute wait at approximately two minutes. Five minutes is only the no-activity deadline.

This would reduce timeout-only model re-entry by roughly 10x for long subagent tasks while preserving immediate event-driven completion delivery.

Expected behavior

  1. Calling wait_agent without timeout_ms waits for up to 300,000 ms.
  2. Child completion still returns immediately, well before that deadline.
  3. V2 mailbox activity and steered user input still return immediately.
  4. Explicit timeout_ms continues to override the default within configured bounds.
  5. The tool schema, configuration defaults, and documentation report the same five-minute default.

Regression coverage

Please add tests establishing that:

  • a child or mailbox completion before the deadline wakes wait_agent immediately;
  • no activity produces timed_out: true only at the configured/default deadline;
  • a wait timeout does not change or terminate the child status;
  • the model-visible tool schema advertises 300,000 ms as the default.

Tradeoff

A longer deadline delays parent reconsideration when a child is genuinely stuck or a notification is lost. Five minutes remains bounded, explicit shorter waits remain available, and V2 user steering interrupts the wait. The normal successful path should not become slower because it is notification-driven.

Related issues

  • #18394 requests configurability. Current main now exposes features.multi_agent_v2.default_wait_timeout_ms, but the built-in default remains 30 seconds.
  • #34468 and #35259 cover repeated model-mediated status polling and token usage.
  • #33276 reports a wait loop exhausting usage.
  • #35108 covers nested code-mode wait boundaries.

Raising the default is a small defense-in-depth improvement and does not replace the stronger runtime fix proposed in #35259: re-arm unchanged waits inside the harness without returning to the model.

Source version checked

Current main at b7a61066081644e0d8b2c0b4dbfd7408ac1514df.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 27 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #35259

Powered by Codex Action

shaswatshah · 27 days ago

Closing because I filed this against the wrong repository. The intended implementation work belongs in downstream project repositories.