[BUG] iOS: API key auth fails for custom OpenAI-compatible endpoints

[wjf3121]

Bug Description
On iOS, custom OpenAI-compatible endpoints with API key authentication fail to work. The same configuration (custom base URL + API key) works correctly on desktop. Disabling authentication on the server side makes it work on iOS.

Steps to Reproduce

1. Open Chatbox on iOS
2. Configure a custom OpenAI-compatible provider with a custom endpoint URL and API key (e.g., LM Studio with auth enabled)
3. Send a message
4. Request fails

Expected Results
The request should succeed and return a chat completion, the same as on desktop.

Actual Results
The request fails on iOS. The server (e.g., LM Studio) logs: "Unexpected endpoint or method. (POST /v1/chat/completions). Returning 200 anyway". Disabling auth on the server makes it work on iOS.

Screenshots
N/A

Desktop (please complete the following information):

• Operating System: iOS 26.3
• Application Version: Chatbox v1.19.0

Additional Context

Root Cause Analysis (suggested by Claude, not verified manually)

In src/renderer/utils/request.ts, doRequest only routes mobile requests through handleMobileRequest (which uses CapacitorHttp / native HTTP) when useProxy is true:

// request.ts line 64-66
if (platform.type === 'mobile' && useProxy) {  // BUG: requires useProxy to be true
    return handleMobileRequest(requestUrl, method, headers, body, signal)
}
// Falls through to plain fetch() in WKWebView
const res = await fetch(requestUrl, { method, headers, body, signal })

Why this fails on iOS but works on desktop:

• Desktop (Electron): webSecurity: false is set in src/main/main.ts:266, disabling CORS enforcement entirely. Plain fetch() works without restrictions.
• iOS (Capacitor/WKWebView): CORS is enforced. The Authorization: Bearer <key> header is a non-simple header that triggers a CORS preflight (OPTIONS request). Servers like LM Studio don't handle the OPTIONS preflight properly, causing the request to fail or lose its auth header.

Why disabling auth fixes it: Without the Authorization header, no CORS preflight is triggered and the request goes through as a "simple request".

Why CapacitorHttp fixes it: CapacitorHttp makes native HTTP calls via iOS URLSession, bypassing WKWebView's CORS enforcement entirely — no preflight, no header restrictions.

For custom OpenAI-compatible endpoints, useProxy is typically false/undefined, so on iOS the request falls through to plain fetch() instead of CapacitorHttp.

Suggested Fix (suggested by Claude, not verified manually)

On mobile, always route through handleMobileRequest regardless of useProxy:

// Change from:
if (platform.type === 'mobile' && useProxy) {

// To:
if (platform.type === 'mobile') {

[root-xxx]

this is an important function ,iOS user need it ! waiting fix this bug ~

[HerShin5]

This looks like the right diagnosis to me: for custom OpenAI-compatible endpoints, “mobile + auth header” is a separate transport path, not just a provider config issue.

A couple of implementation details I’d make explicit in the fix:

• On iOS/Capacitor, route custom endpoint requests through native HTTP whenever an auth header or non-simple custom header is present, even if useProxy is false.
• Preserve the exact Authorization: Bearer ... header for custom providers; don’t special-case it only for first-party OpenAI/OpenRouter providers.
• Add a regression fixture with a tiny OpenAI-compatible server that requires bearer auth and intentionally does not answer browser CORS preflight. That would catch the “desktop works, iOS fails” split.
• Keep diagnostics redacted but specific: final host/path, transport used (fetch vs native HTTP), auth-present yes/no, and whether a preflight was attempted.
• For local no-auth endpoints, make “no auth” an explicit mode rather than inferring it from an empty key.

Disclosure: I’m associated with/evaluating KiroForge (https://kiroforge.cloud/v1), which is also an OpenAI-compatible gateway. This exact class of bug shows up a lot when testing gateway endpoints across desktop/mobile clients, especially when the endpoint requires bearer auth or custom headers.