fix(opencode): apply default header timeout to all providers

[tancheng33]

Issue for this PR

Closes #39859

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Only the openai provider gets a default headerTimeout (300s). Every other provider — including the zen/opencode provider from the issue — waits for response headers forever. When a connection is established but silently blackholed, the CLI hangs indefinitely with no error: exactly the symptom in #39859 (log stops after llm runtime selected, nothing ever happens). #36029 root-caused one common trigger on Windows: the CLI connects over an IPv6 path that stays Established but never delivers data, while browsers/Electron retry over IPv4 and work — which is why the Web UI works on the same machine.

This applies the same 300s header-timeout default to all providers at the fetch layer (packages/opencode/src/provider/provider.ts), so a blackholed connection now fails with the existing actionable ProviderHeaderTimeoutError instead of hanging forever. Behavior details:

• config headerTimeout: <ms> still overrides, and headerTimeout: false still disables entirely (?? preserves false);
• the OpenAI loader keeps its explicit default, unchanged;
• the timeout only covers time-to-headers — slow/long streams are unaffected once headers arrive (covered by an existing test).

One existing test was renamed (headerTimeout is opt-in for non-OpenAI providers → default headerTimeout does not abort briefly delayed headers) since it now documents the new default; its assertions are unchanged and still pass. If keeping header timeout opt-in for non-OpenAI providers was a deliberate decision, happy to hear the reasoning — but a silent infinite hang seems strictly worse than a 5-minute failure with a clear error, and anyone with a legitimately slower provider can raise or disable it in config.

How did you verify your code works?

• bun test test/provider/header-timeout.test.ts — 6/6 pass (including headers-never-arrive abort and delayed-SSE-body no-abort).
• bun test test/provider/provider.test.ts — 99/99 pass.
• bun typecheck in packages/opencode passes; full-repo typecheck passes via the pre-push hook.

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found two potentially related PRs:

1. fix(provider): recover stalled model streams #40010 - fix(provider): recover stalled model streams

   • This PR also addresses provider-related connection/streaming issues and may be related to handling stalled or hung connections.

2. fix(provider): apply documented 300s request timeout default #36650 - fix(provider): apply documented 300s request timeout default

   • This is highly relevant as it deals with applying a 300s timeout default to providers, which is similar in scope to the current PR's goal of applying header timeout defaults.

The current PR (#40069) appears to be the primary/newer iteration addressing the header timeout issue across all providers, whereas #36650 may have focused on a different timeout aspect (request timeout vs. header timeout). PR #40010 addresses a related stability concern with stalled streams.

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.