fix: enable native web search for DeepSeek models in auto mode

[bxclib2]

Add a thirdPartyNativeSearchModelPatterns list for Anthropic-compatible providers that support web_search_20250305 but whose model IDs don't contain "claude". DeepSeek models (deepseek-*) are the first entry.

Summary

Verification

• I ran the relevant local checks, or explained why they do not apply.

Risk

• This PR does not touch CLI core paths, or it has maintainer approval for allow-cli-core-change.
• User-facing behavior changes include tests or an explanation of why tests are not practical.

@dosubot review this PR for changed-area risk, missing tests, docs impact, desktop startup risk, and CLI core impact.

[github-actions]

PR quality triage

Changed areas: area:cli-core

CLI core policy: Blocked by policy until a maintainer applies allow-cli-core-change and approves the PR.

CLI core files:

• src/tools/WebSearchTool/backend.ts

Expected checks:

• change-policy
• server-checks

Test coverage signals:

• Agent/model runtime path changed: use mock/request-shape tests in PR and maintainer live-model smoke before release.

Risk notes:

• Provider/search behavior changed: PR gate uses mock tests; live-provider tests stay maintainer-only.

Hard merge gates still come from GitHub Actions, not AI review.

Dosu handoff: Dosu can be used as the AI reviewer for risk explanation, missing-test prompts, and maintainer Q&A. If it does not comment automatically from the PR template, ask:

@dosubot review this PR for changed-area risk, missing tests, docs impact, desktop startup risk, and CLI core impact.

[dosubot]

Here's the review of PR #270 across the five requested dimensions:

---

Changed-Area Risk: Low–Medium

This PR modifies a single file — src/tools/WebSearchTool/backend.ts — with two targeted changes:

1. Adds a thirdPartyNativeSearchModelPatterns array containing /^deepseek-/ [1].
2. Refactors canUseAnthropicNativeWebSearch() so it returns false early if the model is in unsupportedNativeModels, then returns true if the model is Claude or matches a third-party pattern [1].

The logic change is small but subtly alters the behavior: previously, the function was isLikelyClaudeModel(model) && (!key || !unsupportedNativeModels.has(key)) [2]. The new version checks unsupportedNativeModels first, then ORs Claude detection with the new pattern list. This means if a model was previously marked unsupported at runtime via markAnthropicNativeUnsupported() [3], it now correctly blocks all models (including third-party ones), which is the right behavior. The risk here is that DeepSeek models will now attempt web_search_20250305 natively in auto mode — if DeepSeek's API doesn't actually support it, users will hit errors until the shouldFallbackFromNativeError → markAnthropicNativeUnsupported fallback path kicks in [4]. That fallback exists and should handle it, but the first request in a session would fail before recovering.

Missing Tests: Yes — this needs test coverage

The existing test file backend.test.ts covers Claude model detection, auto-mode provider resolution, explicit provider modes, and fallback error detection. However, it has no tests for the new third-party pattern matching. Recommended additions:

• resolveWebSearchProvider('deepseek-v4-pro', { mode: 'auto' }).provider should be 'anthropic'
• resolveWebSearchProvider('deepseek-v4-flash', { mode: 'auto', tavilyApiKey: 'key' }).provider should be 'anthropic' (native preferred over Tavily)
• resolveWebSearchProvider('deepseek-chat', { mode: 'auto' }).provider — verify behavior for model names that start with deepseek- but aren't the known v4 models
• isWebSearchEnabledForModel('deepseek-v4-pro', { mode: 'auto' }) should be true
• Verify that markAnthropicNativeUnsupported('deepseek-v4-pro') followed by resolveWebSearchProvider correctly returns 'disabled' (or falls back to Tavily if a key is configured)

Docs Impact: None

This is an internal provider-resolution change. Web search mode documentation (if any) describes user-facing settings (auto, anthropic, tavily, brave, disabled) which haven't changed. No doc updates needed.

Desktop Startup Risk: None

Web search provider resolution happens at runtime during message processing, not during app initialization. The desktop app's Tauri/React startup path [5] [6] is completely unaffected.

CLI Core Impact: Low

The file is flagged as area:cli-core by the triage bot, and it is on the CLI core path — resolveWebSearchProvider is called when the web search tool is invoked during a conversation. However, the change is additive (new pattern list, expanded OR condition) and doesn't alter the existing Claude or fallback flows. The allow-cli-core-change label and maintainer approval are still required per policy.

---

Summary: Small, well-scoped change with correct fallback semantics. Main gap is missing unit tests for the new pattern-matching path. I'd recommend adding those before merge to validate both the happy path (DeepSeek → native) and the failure path (DeepSeek marked unsupported → falls back to Tavily/Brave).

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.