[rekram1-node]

Problem

Native provider routes send requests through Effect's FetchHttpClient, which calls Bun's fetch. Bun closes a connection after 300s with no data unless the request passes timeout: false. Bun only checks about once a minute, so in practice this fires between 5 and 6 minutes.

That limit sits underneath the route transport's own headerTimeout / chunkTimeout / timeout. So raising those above 5 minutes had no effect: Bun closed the connection first. The AI SDK path (packages/core/src/aisdk.ts) and the CLI event stream already pass timeout: false. The native route executor didn't.

Change

Core wires RequestExecutor to an HTTP client that gives each request FetchHttpClient.RequestInit with { timeout: false }. This is the same transformResponse pattern as packages/sdk/src/effect/opencode.ts.

The fix lives in core because the timeout belongs to the runtime core runs on. @opencode/ai itself is unchanged.

This doesn't change any limits on its own. The route's headerTimeout / chunkTimeout defaults (300s) still apply, but they're now the timeouts that actually take effect and can be raised per provider.

Verification

Ran core's requestExecutor node with BUN_CONFIG_HTTP_IDLE_TIMEOUT=2 against a server that pauses for 10s in the middle of the response body:

• before: Bun cut the body off at 8.0s
• after: the response completed at 10.0s

bun run check passes.

[opencode-agent]

This works as described. I ran one request through RequestExecutor.fetchLayer against a local server that takes 12s to answer, with BUN_CONFIG_HTTP_IDLE_TIMEOUT=4. On the base it failed after 8.0s with Transport error; with this change it succeeded after 12.0s. The executor tests pass and packages/ai type-checks cleanly.

The fetch client reads RequestInit from the request fiber's context, so wrapping the client with transformResponse sets timeout: false on both the plain path and the middleware path. A RequestInit from the caller still wins. The new test is small and covers the fixed behaviour.

Public API: unchanged.

No concerns.

Related: #54865