fix(agents): pass run timeoutMs to OpenAI SDK HTTP client to override 10-min default

[zozo123]

Summary

• Pass httpTimeoutMs derived from the agent run's timeoutMs into the OpenAI, AzureOpenAI, and completions client constructors
• Prevents the SDK's hardcoded 600 s default from silently terminating local inference requests that exceed 10 minutes
• No behavior change for requests completing under 10 minutes

Closes #63663

---

This PR was developed with AI assistance (Claude). Built with islo.dev

[openclaw-barnacle]

Closing this PR because the author has more than 10 active PRs in this repo. Please reduce the active PR queue and reopen or resubmit once it is back under the limit. You can close your own PRs to get back under the limit.

[greptile-apps]

Greptile Summary

This PR threads an httpTimeoutMs option (derived from the agent run's timeoutMs) into the OpenAI, AzureOpenAI, and completions client constructors, overriding the SDK's hardcoded 600 s default that was silently killing local long-running inference requests.

The core logic is sound: timeoutMs is a required run-level field, the conditional spread is correctly guarded on !== undefined, and the wrapWithTimeout helper in stream-resolution.ts cleanly injects the value across the main transport paths. The one small gap is the WebSocket-to-HTTP fallback path (shouldUseWebSocketTransport && !wsApiKey), where currentStreamFn is returned without the timeout wrapper — see inline comment.

Confidence Score: 5/5

Safe to merge — all remaining findings are P2 suggestions and the core fix is correct.

The implementation correctly overrides the SDK default for OpenAI, AzureOpenAI, and completions transports. Using the total run timeoutMs as the per-request HTTP ceiling is consistent with how the runAbortController handles the actual wall-clock abort. The only gap (WebSocket HTTP fallback missing wrapWithTimeout) is pre-existing and does not affect the targeted local-inference use case. No P0/P1 issues.

stream-resolution.ts — minor gap on the WebSocket-to-HTTP fallback path (lines 118–123).

Vulnerabilities

No security concerns identified.

Comments Outside Diff (1)

1. src/agents/pi-embedded-runner/stream-resolution.ts, line 118-123 (link)

   WebSocket HTTP-fallback path skips timeout injection

   When shouldUseWebSocketTransport is true but wsApiKey is falsy, currentStreamFn is returned directly without wrapWithTimeout. If currentStreamFn is an OpenAI HTTP transport (e.g. createOpenAIResponsesTransportStreamFn()), httpTimeoutMs won't be propagated on this code path, leaving the SDK's 10-minute default in effect for the HTTP fallback scenario.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: src/agents/pi-embedded-runner/stream-resolution.ts
   Line: 118-123
   
   Comment:
   **WebSocket HTTP-fallback path skips timeout injection**
   
   When `shouldUseWebSocketTransport` is `true` but `wsApiKey` is falsy, `currentStreamFn` is returned directly without `wrapWithTimeout`. If `currentStreamFn` is an OpenAI HTTP transport (e.g. `createOpenAIResponsesTransportStreamFn()`), `httpTimeoutMs` won't be propagated on this code path, leaving the SDK's 10-minute default in effect for the HTTP fallback scenario.
   
   
   
   How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: src/agents/pi-embedded-runner/stream-resolution.ts
Line: 118-123

Comment:
**WebSocket HTTP-fallback path skips timeout injection**

When `shouldUseWebSocketTransport` is `true` but `wsApiKey` is falsy, `currentStreamFn` is returned directly without `wrapWithTimeout`. If `currentStreamFn` is an OpenAI HTTP transport (e.g. `createOpenAIResponsesTransportStreamFn()`), `httpTimeoutMs` won't be propagated on this code path, leaving the SDK's 10-minute default in effect for the HTTP fallback scenario.

```suggestion
  if (params.shouldUseWebSocketTransport) {
    return params.wsApiKey
      ? createOpenAIWebSocketStreamFn(params.wsApiKey, params.sessionId, {
          signal: params.signal,
        })
      : wrapWithTimeout(currentStreamFn);
  }
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(agents): pass run timeoutMs to OpenA..." | Re-trigger Greptile}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 60f3924da2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Apply HTTP timeout to WebSocket-selected stream path

The new timeout wrapper is defined here but the shouldUseWebSocketTransport branch still returns a raw stream function before wrapWithTimeout is applied, so httpTimeoutMs is never injected for OpenAI WebSocket mode. In practice, when that WebSocket path degrades to HTTP fallback (fallbackToHttp in openai-ws-stream.ts) or when WS is selected but unavailable, the fallback request options still lack httpTimeoutMs, so the OpenAI SDK can continue using its 600s default and terminate long runs early.

Useful? React with 👍 / 👎.