Summary

What problem does this PR solve?

• Fixes an issue where proxied model streams could fail too early because the client-side proxy read guard always used a hard-coded 120 second idle window, even when the caller configured a longer model/request timeout.
• Root cause: streamProxy introduced a proxy-local idle read guard, but the guard did not consume the existing stream timeoutMs option and the proxy request body did not forward timeoutMs to the proxy server.
• Fix classification: root-cause compatibility fix for the proxy response read boundary.

Why does this matter now?

• Why it matters / User impact: the original PR intentionally made oversized or silent proxy responses fail closed, but a fixed 120 second idle window could still break legitimate slow proxy deployments that explicitly configure a longer request timeout.
• Honoring the configured timeout removes that compatibility risk without weakening the default fail-fast behavior.

What is the intended outcome?

• Maintainer-ready confidence: high for this scoped follow-up; it changes only proxy option forwarding and timeout resolution, with focused regression coverage and local HTTP proxy-style proof.
• Proxy streams with no explicit positive timeout still fail after the existing 120 second idle window.
• Proxy streams with a longer positive timeoutMs use that configured window for SSE chunk reads and bounded non-2xx error-body reads.
• The proxy request body now forwards timeoutMs to the proxy server together with the other serializable stream options.

What is intentionally out of scope?

• What did NOT change: this does not change public config, schema, migration behavior, provider routing, auth behavior, SSE event schema, or the /api/stream endpoint contract.
• Out of scope: tuning the existing 16 MiB byte caps, removing the fail-closed behavior, changing provider-specific streaming code, or adding new user configuration.

What does success look like?

A configured proxied stream can wait beyond 120 seconds when timeoutMs is set higher, while the default path still fails stalled proxy reads after 120 seconds and oversized response bodies remain bounded.

What should reviewers focus on?

• Why this is root-cause fix: the invariant is that proxy-side read idleness should be derived from the same positive stream timeout already used for provider/request timing, not from a second hard-coded constant hidden inside streamProxy. The patch fixes that source boundary by forwarding timeoutMs, resolving it once with resolvePositiveTimerTimeoutMs, and passing the resolved value to both proxy error-body reads and SSE chunk reads.
• Architecture / source-of-truth check: resolvePositiveTimerTimeoutMs remains the canonical positive timer normalization helper; streamProxy owns only proxy response read behavior and does not introduce a new config source, provider-routing rule, schema field, or endpoint contract.
• Related open PR / same-contract scan: fix(runtime/proxy): bound streaming success-body SSE reads at 16 MiB #96768 and fix(proxy): bound SSE parser via complete-line cap at 1 MiB #97191 overlap the same streamProxy hardening area; this follow-up does not compete on their byte-cap policy and only repairs the configured idle-timeout compatibility boundary in fix: proxy streams fail fast on oversized or stalled responses #97235.
• Patch quality notes: the timeout-related code is deliberate root-cause behavior, not a retry or sleep fallback; the catch paths preserve existing proxy error handling while allowing bounded body-read failures to surface; the unknown as ReadableStreamDefaultReader casts are confined to test fixtures that emulate browser reader objects for deterministic pending/cancel behavior.

Linked context

Which issue does this close?

Existing PR update for #97235; no separate linked GitHub issue is resolved by this follow-up.

Which issues, PRs, or discussions are related?

• Related open PR / same-contract scan: fix(runtime/proxy): bound streaming success-body SSE reads at 16 MiB #96768 and fix(proxy): bound SSE parser via complete-line cap at 1 MiB #97191 are open overlapping proxy hardening PRs touching the same streamProxy loop.
• Current PR context: fix: proxy streams fail fast on oversized or stalled responses #97235 adds proxy response bounds for non-2xx bodies, total SSE bytes, pending SSE buffers, and idle SSE reads.

Was this requested by a maintainer or owner?

No maintainer directly requested this exact follow-up. It addresses the ClawSweeper compatibility finding that a legitimate proxied stream silent for more than 120 seconds would otherwise fail before later content arrives.

Real behavior proof

• Behavior or issue addressed: streamProxy now honors a positive configured timeoutMs for proxy read idleness instead of forcing the 120 second default on every proxied SSE/error-body read.

• Real environment tested: local OpenClaw PR worktree with the production streamProxy implementation and a real local HTTP /api/stream server that accepts the proxy request and intentionally leaves the SSE response open without bytes.

• Exact steps or command run after this patch: daily-fix bounded live proof ran a TypeScript harness with corepack [email protected] exec tsx, plus focused proxy runtime tests and focused agents type checking.

• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output):

  configured-proxy-sse-idle-timeout live proof:
  requestOptionsTimeoutMs: 250
  configuredTimeoutMs: 250
  stopReason: error
  errorMessage: Proxy SSE stream stalled: no data received for 250ms
  durationMs: 329
  

  Validation `proxy-runtime-test` (pass, exit_code=0, 14321ms):
  $ node scripts/test-projects.mjs -- src/agents/runtime/proxy.test.ts
  [test] starting test/vitest/vitest.agents.config.ts
  
   RUN  v4.1.8 [local path redacted]
  
   Test Files  1 passed (1)
        Tests  10 passed (10)
     Start at  15:14:56
     Duration  2.50s (transform 2.13s, setup 1.14s, import 172ms, tests 828ms, environment 0ms)
  
  [test] passed 1 Vitest shard in 13.13s
  

  Validation `agents-test-types` (pass, exit_code=0, 28741ms):
  Validation result: pass, exit_code=0, 28741ms
  

• Observed result after fix: the proxy request carried the configured 250ms timeout, and the stalled real HTTP SSE response failed with Proxy SSE stream stalled: no data received for 250ms, proving the proxy idle guard no longer clamps the read to the old default.

• What was not tested: no hosted proxy, external provider, Control UI, or full chat flow was used; the proof uses a local HTTP server because this change is at the client-side streamProxy response boundary and needs deterministic stalled-response control.

• Proof limitations or environment constraints: this follow-up validates the affected proxy boundary directly; maintainer acceptance is still needed for the broader 16 MiB caps and default 120 second fail-closed policy.

Tests and validation

Which commands did you run?

• Target test file: src/agents/runtime/proxy.test.ts.

corepack [email protected] test -- src/agents/runtime/proxy.test.ts
corepack [email protected] exec tsgo -p test/tsconfig/tsconfig.core.test.agents.json --noEmit --pretty false
daily_fix.sh bounded-live-proof -- corepack [email protected] exec tsx proxy-configured-timeout-live-proof.ts

What regression coverage was added or updated?

• Scenario locked in: a streamProxy call with timeoutMs: 180000 remains unresolved after 120 seconds, does not cancel the reader early, and then fails at 180 seconds with Proxy SSE stream stalled: no data received for 180000ms.
• Existing idle-timeout coverage still proves the default path fails after 120 seconds.
• The local HTTP proof locks the real request/response boundary by showing the proxy request carries timeoutMs and the stalled SSE response fails on the configured value.

What failed before this fix, if known?

• Why this is the smallest reliable guardrail: before this follow-up, the new regression test failed at 120 seconds with Proxy SSE stream stalled: no data received for 120000ms even though timeoutMs: 180000 was provided; fixing option forwarding and read-timeout resolution addresses the source of that wrong timer value without adding config or changing byte caps.

If no test was added, why not?

A focused regression test was added in src/agents/runtime/proxy.test.ts, and an additional local HTTP proxy-style proof was captured for the configured-timeout behavior.

Risk checklist

Did user-visible behavior change? (Yes/No)

Yes, but only for proxied streams that set a positive timeoutMs: those streams may now wait longer than the previous hard-coded 120 second proxy read idle window.

Did config, environment, or migration behavior change? (Yes/No)

No. This uses an existing stream option and does not add config, environment variables, migrations, or new user-facing settings.

Did security, auth, secrets, network, or tool execution behavior change? (Yes/No)

No auth, secrets, or tool execution behavior changed. The network read boundary still fails closed for oversized bodies and stalled reads; the idle duration now follows the existing positive timeout option when present.

What is the highest-risk area?

• Risk labels considered: compatibility and message-delivery behavior in the proxied streaming path.
• Risk explanation: the follow-up allows a configured proxy stream to stay open longer than 120 seconds, but only when the caller already supplied a positive timeoutMs; the default 120 second behavior and 16 MiB fail-closed caps remain unchanged.

How is that risk mitigated?

• Why acceptable: positive timeout handling uses the existing resolvePositiveTimerTimeoutMs helper, so non-positive or invalid values still fall back to 120 seconds.
• The timeout is resolved once per streamProxy call and passed to both non-2xx error-body reads and SSE chunk reads, keeping behavior consistent within the proxy response boundary.
• Focused tests cover the default 120 second path and the longer configured timeout path, and local HTTP proof covers the real proxy request/response boundary.

Current review state

What is the next action?

Submit this follow-up through the daily-fix submit-pr flow and let the remote PR checks and labels settle.

What is still waiting on author, maintainer, CI, or external proof?

• Author-side follow-up for RF-002 is addressed by honoring positive configured timeoutMs values; maintainer acceptance is still needed for the default 120 second idle policy.
• Maintainer-side decision remains needed for RF-001, RF-003, and RF-004: accept or tune the 16 MiB fail-closed caps, and sequence this broader proxy guard with fix(runtime/proxy): bound streaming success-body SSE reads at 16 MiB #96768 and fix(proxy): bound SSE parser via complete-line cap at 1 MiB #97191.
• Remote CI and ClawSweeper need to run on the updated head after submission.

Which bot or reviewer comments were addressed?

• RF-001: disclosed as a maintainer policy decision; this follow-up does not change the existing 16 MiB fail-closed cap.
• RF-002: fixed for configured deployments by honoring positive timeoutMs; default 120 second behavior remains unchanged and documented above.
• RF-003: disclosed as related overlap with fix(runtime/proxy): bound streaming success-body SSE reads at 16 MiB #96768 and fix(proxy): bound SSE parser via complete-line cap at 1 MiB #97191 for maintainer sequencing.
• RF-004: disclosed as a maintainer threshold/sequencing decision after the contributor-side compatibility fix.