fix(websearch): remove provider whitelist - enable websearch for all providers by default

[4ebuRushka]

Issue for this PR

Closes #44307

Type of change

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

What does this PR do?

websearch is a client-side tool backed by the public Exa/Parallel MCP endpoints, so its availability should not depend on the identity of the model provider. Today it is hidden for every provider except opencode/opencode-go unless undocumented env vars are set.

• Remove the webSearchEnabled(providerID, ...) whitelist from ToolRegistry. The tool is now included for every provider unless explicitly disabled via config (websearch.enabled: false); consent stays on the existing permission.websearch layer (ask/deny per call), which is untouched.

• Add a documented config section:

  {
    "websearch": {
      "enabled": true,   // default true; false hides the tool everywhere
      "provider": "auto" // "auto" | "exa" | "parallel"
    }
  }

• Backend selection priority becomes: websearch.provider -> OPENCODE_WEBSEARCH_PROVIDER -> legacy OPENCODE_ENABLE_EXA / OPENCODE_ENABLE_PARALLEL pins -> per-session checksum split (unchanged).

• OPENCODE_ENABLE_EXA / _PARALLEL no longer gate availability; they keep pin semantics and log a one-shot deprecation warning.

• Docs: rewrite the websearch section in tools.mdx; mark the env flags deprecated in cli.mdx.

Why this instead of #44343: #44343 keeps the hardcoded whitelist, so custom/local providers stay broken out of the box and every new managed provider needs another additive line (#40568, #42378, PR #42630). The whitelist is also not enforcement: the bypass is a client-side env var, and the backends are public keyless endpoints that both vendors offer for free (Parallel explicitly targets OpenCode users). Removing the mechanism removes the bug class, matches webfetch (already shipped to all providers unfiltered), and matches the V2 core tool, which registers websearch unconditionally (packages/core/src/tool/builtins.ts).

Compatibility:

• Zen/Go users: no behavior change.
• Custom-provider users without any config: tool appears (this is the fix; refs Add websearch provider selection to settings UI / config instead of only env var #40028, tools: websearch unexpectedly switches between Exa and Parallel providers #39121).
• Users with legacy env flags: keep working as backend pins, plus a deprecation warning.
• Air-gapped / privacy-sensitive setups: websearch.enabled: false or permission.websearch: deny.

How did you verify your code works?

• Unit matrix in packages/opencode/test/tool/websearch.test.ts: 18/18 pass — default-on for arbitrary providers without config; websearch.enabled: false hides the tool (also for managed providers); pin priority config > env > legacy flags; invalid OPENCODE_WEBSEARCH_PROVIDER value falls back to the checksum split without crashing; one-shot deprecation warning for legacy flags. Together with test/tool/registry.test.ts: 33/33 pass.
• bun test test/tool/ in packages/opencode: ~392 pass across runs (391–393, timing-flaky tool.glob on slow Windows hosts) / persistent fail only tool.shell abort > preserves output when aborted, which reproduces on pristine dev on this machine; pre-existing Windows-only issue, unrelated to this change.
• tsgo --noEmit: 0 errors in packages/core; packages/opencode has 1 pre-existing error in the untouched test/provider/transform.test.ts (broken by upstream fix(opencode): let config opt out of Anthropic thinking blockBinding #46820 on the new base, unrelated to this change); oxlint on changed files: 0 errors. Rebased onto upstream/dev@c0f09afe (from c2eacd72); merge simulation shows 0 conflicts.
• Manual E2E on a local build against a custom OpenAI-compatible provider and a managed opencode/* control (config injected inline via OPENCODE_CONFIG_CONTENT, legacy env vars stripped per process): the tool appears with no env vars configured; enabled: false removes it; websearch.provider: "exa" shows "exa" in tool-call metadata and wins over OPENCODE_WEBSEARCH_PROVIDER=parallel; a legacy OPENCODE_ENABLE_EXA=1 run logs the deprecation warning.

Screenshots / recordings

N/A - no UI changes.

Checklist

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

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

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

Potential Related PR Found:

#44343 - fix(opencode): let a pinned websearch provider enable the tool for any provider

• Why related: This PR is explicitly mentioned in the current PR (45472) description as an alternative approach. PR fix(opencode): let a pinned websearch provider enable the tool for any provider #44343 keeps the hardcoded whitelist and adds a third env var, whereas PR fix(websearch): remove provider whitelist - enable websearch for all providers by default #45472 removes the whitelist entirely. These are competing solutions to the same issue (websearch tool is never exposed to custom/local providers (hardcoded provider whitelist in ToolRegistry) #44307).

However, #45472 (the current PR) is not a duplicate — it's the preferred approach that replaces #44343's strategy.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[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.