[BUG][Mobile] Custom Claude/Anthropic provider ignores "Improve Network Compatibility" (useProxy) toggle → Network Error for custom Anthropic hosts on iOS/Android

[celeste1900]

Environment

• Platform: iOS app (v1.20.x) with a system proxy/VPN active. Same code path on Android (Capacitor WebView).
• Provider: a custom provider using the Claude/Anthropic protocol (CustomClaude), pointed at a self-hosted Anthropic-compatible host that intentionally does not send CORS headers.
• Desktop (Electron) is not affected (webSecurity: false in src/main/main.ts disables CORS in the renderer).

Summary

For custom providers, the "Improve Network Compatibility" (useProxy) toggle is shown and works for the OpenAI protocol, but is silently ignored by the Claude/Anthropic protocol (CustomClaude). As a result, a custom Anthropic host without CORS headers fails with Network Error on mobile even with the toggle ON, because the request still goes through the WebView fetch (CORS-enforced) instead of the native HTTP layer.

Steps to reproduce (iOS)

Using a custom host that does not return Access-Control-Allow-Origin:

1. Add it as a custom OpenAI-compatible provider, enable Improve Network Compatibility → ✅ works.
2. Add it as a custom Claude/Anthropic provider, enable Improve Network Compatibility → ❌ still Network Error.

Same host, same network, toggle ON in both cases — only the Anthropic protocol fails. (Reported to work in an earlier app version, so this appears to be a regression for the user.)

Root cause (verified against current main)

The useProxy toggle is never threaded into CustomClaude, so it can't reach the native-HTTP path:

1. UI — src/renderer/routes/settings/provider/$providerId.tsx: the toggle (<Switch label={t('Improve Network Compatibility')} checked={providerSettings?.useProxy} ...>) is rendered inside {baseInfo.isCustom && (...)}, i.e. for all custom providers, including custom Anthropic.
2. Wiring — src/renderer/packages/model-setting-utils/custom-provider-setting-util.ts:
   • new CustomOpenAI({ ..., useProxy: settings.useProxy }) ✅ and new CustomOpenAIResponses({ ..., useProxy: settings.useProxy }) ✅
   • new CustomClaude({ apiHost, apiKey, model, temperature }) ❌ — useProxy is not passed (the CustomClaude Options interface doesn't even declare it).
3. Model — src/shared/providers/definitions/models/custom-claude.ts: getProvider() calls createAnthropic({ baseURL, apiKey, headers }) with no fetch override, so the AI SDK uses the default global fetch → on mobile this is a WebView fetch, subject to CORS. (It does set anthropic-dangerous-direct-browser-access: true, but that only helps when the host itself returns CORS headers; for hosts that don't, the request is still blocked.)
4. Contrast — src/shared/providers/definitions/models/custom-openai.ts declares useProxy?: boolean and routes its fetch through createFetchWithProxy(this.options.useProxy, ...) → src/shared/models/utils/fetch-proxy.ts → request.apiRequest({ ..., useProxy }) → src/renderer/utils/request.ts, where on mobile if (platform.type === 'mobile' && useProxy) return handleMobileRequest(...) → src/renderer/utils/mobile-request.ts → native CapacitorHttp / StreamHttp, which bypasses WebView CORS. That's exactly why the toggle works for custom OpenAI but not custom Claude.

The custom model classes (CustomOpenAI, CustomClaude, ...) were migrated in the Provider System Refactor (tasks/prd-provider-system-refactor.md); CustomOpenAI got the useProxy → createFetchWithProxy wiring, CustomClaude did not. The built-in Claude provider (definitions/claude.ts) similarly only sets a customFetch for the OAuth branch.

Suggested fix

Add useProxy?: boolean to CustomClaude's Options, pass useProxy: settings.useProxy when constructing it in custom-provider-setting-util.ts, and route createAnthropic({ fetch: createFetchWithProxy(this.options.useProxy, this.dependencies) }) — mirroring CustomOpenAI. (Same gap likely applies to CustomGemini and the built-in Claude provider.)

Related

#1791 (iOS local network / Ollama), #2414 (forced HTTPS on mobile).

[celeste1900]

Same gap confirmed for CustomGemini (custom Gemini protocol)

Following up on my own report — the useProxy ("Improve Network Compatibility") toggle is also silently ignored by the custom Gemini protocol, for the exact same reason as CustomClaude. So a self-hosted Gemini-compatible host without CORS headers fails with Network Error on iOS/Android even with the toggle ON.

Verified against current main:

1. Options doesn't declare it — src/shared/providers/definitions/models/custom-gemini.ts, the Options interface has apiKey / apiHost / model / temperature / topP / maxOutputTokens / stream but no useProxy.
2. Not wired in — src/renderer/packages/model-setting-utils/custom-provider-setting-util.ts, the ModelProviderType.Gemini branch constructs:

   new CustomGemini({ apiHost, apiKey, model, temperature: 0 }, dependencies)  // ❌ no useProxy

   compare the OpenAI / OpenAIResponses branches right below it, which both pass useProxy: settings.useProxy.
3. No fetch override — getProvider() calls:

   createGoogleGenerativeAI({ apiKey: this.options.apiKey, baseURL: normalizeGeminiHost(this.options.apiHost).apiHost })

   with no fetch, so the AI SDK uses the default global fetch → on mobile this is the WebView fetch, subject to CORS — never reaching the native-HTTP path (createFetchWithProxy → handleMobileRequest → CapacitorHttp/StreamHttp).

(Minor related note: CustomGemini.listModels() does go through this.dependencies.request.apiRequest(...), but it doesn't pass useProxy either, so model-list fetching on these hosts has the same limitation.)

Suggested fix (mirror the CustomClaude fix)

• Add useProxy?: boolean to CustomGemini's Options.
• Pass useProxy: settings.useProxy when constructing CustomGemini in custom-provider-setting-util.ts (and in the listModels path too).
• Route createGoogleGenerativeAI({ ..., fetch: createFetchWithProxy(this.options.useProxy, this.dependencies) }), mirroring CustomOpenAI / the proposed CustomClaude fix.

So the title's scope effectively covers both custom Anthropic and custom Gemini protocols on mobile.

[celeste1900]

Additional symptom: model-list fetch fails on mobile, but works on desktop regardless of the toggle

Worth calling out explicitly, because it's the most visible failure during setup: on iOS/Android, for both custom Claude and custom Gemini, fetching the model list fails (and chat fails) — with Improve Network Compatibility either ON or OFF. The same host/key config on desktop (Electron) always works, toggle ON or OFF.

That asymmetry is fully explained by the same root cause:

• listModels() never passes useProxy — both call the native-capable request helper without the flag:
  • custom-claude.ts → this.dependencies.request.apiRequest({ url: \${apiHost}/models?limit=990`, ... }) ❌ nouseProxy`
  • custom-gemini.ts → this.dependencies.request.apiRequest({ url: \${apiHost}/models?key=...`, ... }) ❌ nouseProxy`
• In src/renderer/utils/request.ts the native path is gated on the flag: if (platform.type === 'mobile' && useProxy) return handleMobileRequest(...). With useProxy undefined, mobile falls back to WebView fetch (CORS-enforced) → a CORS-less host is blocked → empty/failed model list. This is why the toggle appears to do nothing for Claude/Gemini on mobile — it's never threaded through.
• Desktop is immune because webSecurity: false in src/main/main.ts disables CORS in the renderer, so WebView fetch succeeds whether or not the toggle is on — matching the user's observation.

So the fix needs to thread useProxy through two places for Claude/Gemini, not just chat:

1. getProvider() → fetch: createFetchWithProxy(this.options.useProxy, this.dependencies) (chat path)
2. listModels() → this.dependencies.request.apiRequest({ ..., useProxy: this.options.useProxy }) (model-list path)

(Plus declaring useProxy?: boolean on the Options interface and passing useProxy: settings.useProxy in custom-provider-setting-util.ts, as noted above.)