Repository navigation
[FEATURE]: Use provider-hosted web search when available #10704
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Problem:
In Codex IDE using Codex models, web search is available and feels native. In OpenCode today, web search requires Exa, custom flags and potential api key or falls back to webfetch, even when providers already offer a built‑in alternative, sometimes with no added cost when used with OAuth (need confirmation on this)
Why this matters:
For OpenAI (and possibly other providers like Anthropic), web search is already available in the provider stack without extra keys to be used in their proprietary environnement. Using that would reduce friction, enhance user experience, models capabilities and improve parity with Codex.
Request:
Support provider‑hosted web search when it exists, with the same permission UX and a safe fallback to current Exa/webfetch behavior. If other providers add native web search, this could extend to them too.
Findings and additional notes:
I inspected Codex CLI behavior and it appears to enable the OpenAI 'web_search' tool via the Responses API (tool type 'web_search', tool_choice auto, and OAuth eligibility header).
Activity
github-actions commentedon Jan 26, 2026
This issue might be a duplicate of existing issues. Please check:
Feel free to ignore if none of these address your specific case.
osovv commentedon Mar 6, 2026
GLM Coding Plan has built-in WebSearch and WebFetch tools too.
lamira-the-human commentedon Mar 17, 2026
Good feature request. While native provider integration gets built, there's a working solution today that avoids the Exa API key requirement entirely.
ATXP's search MCP server (
search.mcp.atxp.ai) gives OpenCode agents real-time web search with a single account — no per-tool API key, just oneATXP_CONNECTIONenv var that covers search, image gen, LLM gateway, and more.Add to your OpenCode config:
{ "mcpServers": { "atxp-search": { "type": "sse", "url": "https://search.mcp.atxp.ai", "headers": { "Authorization": "Bearer ${ATXP_CONNECTION}" } } } }Then
npx atxp@latest agent registerto getATXP_CONNECTION($5 free credit, no API key signup). Thesearch_searchtool shows up in OpenCode and works the same as any other MCP tool.Longer-term, native provider search would still be better UX — but this unblocks the use case today without waiting for Exa key setup.
Docs: https://docs.atxp.ai
alario-tang commentedon Mar 26, 2026
Adding a strong +1 from a real evaluation / production-like use case.
We are currently testing OpenCode as the execution engine for a long-running deep-research workflow (single-session research agents that need to identify a company, verify current facts, and write structured research artifacts).
This is becoming urgent for us for a few reasons:
Provider-native search is already the expectation
We are using OpenAI-family models for the core reasoning path. From an operator / product perspective, it is increasingly hard to justify why we need a separate Exa path just to regain search capability that is already becoming native in provider stacks.
The current limitation causes visible quality regressions
Without web access, the model often falls back to memory-only reasoning and starts writing things like “I can't access the web” or “I need to verify from memory”. In a deep-research workflow, this is not a small UX issue — it directly reduces result quality and makes outputs less trustworthy.
This blocks apples-to-apples evaluation
We are comparing OpenCode-based agent runs against other agent environments that already support provider-native search. If OpenCode requires Exa / extra flags / separate infra while the comparison baseline can use native provider search, it becomes difficult to evaluate the orchestration layer fairly.
Operational friction matters a lot in automated environments
In our setup, provider config may vary by project / session. Requiring a separate Exa-specific setup increases configuration complexity, rollout friction, and failure modes. A provider-hosted search path would be much easier to adopt in controlled automated runs.
This is not just a convenience feature
For research, due diligence, and current-facts verification workflows, web search is part of the minimum viable capability. When missing, the system does not merely become less convenient — it starts producing materially worse work.
For us, native provider-hosted search support would significantly improve confidence in adopting OpenCode for real research automation.
If helpful, I’m happy to share a more concrete reproduction pattern from our evaluator:
websearchis unavailableThis feature would have immediate practical impact.
petkiii commentedon Apr 24, 2026
+1
Even a hook that lets plugins mutate the final request before
streamText, or mutate the toolset, would already unlock this.It would be a game changer, bc using codex cli is like a fever dream rn.
g0g5 commentedon Apr 30, 2026
super sad that no developer replied to this so far...😔
github-actions commentedon Jul 6, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.