Zen API endpoints return 404 on CORS preflight (OPTIONS) — blocks all browser-based clients

[OHKNO]

Description

All Zen API endpoints (/zen/v1/* and /zen/go/v1/*) return a 404 HTML page on CORS preflight (OPTIONS) requests, which blocks any browser-based client from calling the API. The actual POST endpoints are alive and working — this is purely a CORS preflight routing issue.

Evidence

Direct curl testing confirms the API backend is functional, but OPTIONS requests fall through to the frontend router:

Endpoint	Method	Result
/zen/v1/chat/completions	POST	✅ 401 "Invalid API key" (API is alive)
/zen/go/v1/chat/completions	POST	✅ 401 "Invalid API key" (API is alive)
/zen/v1/models	GET	✅ 200 (full model list returned)
/zen/v1/chat/completions	OPTIONS (preflight)	❌ 404 — returns HTML "Not Found" page, no CORS headers
/zen/go/v1/chat/completions	OPTIONS (preflight)	❌ 404 — same thing

OPTIONS request/response:

curl -X OPTIONS \
  -H "Origin: https://example.com" \
  -H "Access-Control-Request-Method: POST" \
  -H "Access-Control-Request-Headers: authorization,content-type" \
  "https://opencode.ai/zen/v1/chat/completions"

Response: HTTP 404 with full HTML page (<title>Not Found | opencode</title>), zero CORS headers.

Browser console error:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote
resource at https://opencode.ai/zen/v1/chat/completions.
(Reason: CORS header Access-Control-Allow-Origin missing). Status code: 404.

Impact

• All browser-based clients are completely blocked — any web app using the Zen/Go API
• curl/terminal clients work fine (no CORS enforcement outside browsers)
• Both free (/zen/v1/) and paid (/zen/go/v1/) endpoints are affected
• Multiple reports today: After subscribing to OpenCode Go, I encountered the Insufficient balance error when using non-free models such as GLM 5.1 and Kimi v2.6. #30950, Free usage exceeded, subscribe to Go #31008, and other users experiencing the same issue

Root Cause

The API gateway is not handling OPTIONS requests — they fall through to the frontend SPA router, which returns a 404 HTML page. The server needs to respond to OPTIONS preflight requests with:

• Access-Control-Allow-Origin: * (or specific origins)
• Access-Control-Allow-Methods: POST, GET, OPTIONS
• Access-Control-Allow-Headers: Authorization, Content-Type
• Access-Control-Max-Age: 86400

Environment

• Affected endpoints: opencode.ai/zen/v1/*, opencode.ai/zen/go/v1/*
• Reproduced from: Firefox 151, Chrome (any browser)
• Date: June 5, 2026
• Related: After subscribing to OpenCode Go, I encountered the Insufficient balance error when using non-free models such as GLM 5.1 and Kimi v2.6. #30950, Error: 402 Insufficient Balance - opencode-go #27593, OpenCode Go: 11/12 models silently fail with Insufficient Balance - upstream provider accounts depleted, breaks multi-agent orchestration #28129

[github-actions]

This issue might be related to existing issues. Please check:

• Wildcard cors for server not allowed #28927: Similar CORS issue where the opencode server returns missing Access-Control-Allow-Origin headers for browser clients
• Basic Auth breaks the CORS support #10047: Previous bug where Basic Auth broke CORS support (now closed)

If your issue is specifically about the hosted opencode.ai/zen API endpoints (not self-hosted opencode server), please clarify that in your report as it may be handled differently from server-side CORS configuration bugs.

[OHKNO]

Just to clarify per the bot — this is specifically about the hosted endpoints, not a self-hosted server.

Affected:

• (Zen/free)
• (Go/paid)

What I found:

The API backend is alive — only the OPTIONS preflight is broken:

Endpoint	Method	Result
	POST	401 "Invalid API key" (API works)
	POST	401 "Invalid API key" (API works)
	GET	200 (full model list returned)
	OPTIONS (preflight)	❌ 404 — HTML "Not Found" page, no CORS headers
	OPTIONS (preflight)	❌ 404 — same thing

Root cause I traced:
The gateway doesn't route OPTIONS requests to the API handler — they fall through to the frontend SPA router, which returns a 404 HTML page. Needs to respond with:

• Access-Control-Allow-Origin: *
• Access-Control-Allow-Methods: POST, GET, OPTIONS
• Access-Control-Allow-Headers: Authorization, Content-Type
• Access-Control-Max-Age: 86400

Same class of bug as #10047 (basic auth blocking OPTIONS), just at a different layer.

I built a workaround for myself (GM_xmlhttpRequest bridge to bypass CORS entirely) but obviously a real fix would be better.

[monperrus]

Important for our use case also.

[yuru7]

+1

[rudradevpal]

+1

[karmakarmeghdip]

any updates on this? i was experimenting with webcontainers and opencode in the browser. would be nice to have access from any domain like gemini api

[OHKNO]

Hey @kitlangton — any update on this? It's been 16 days since filing and it's still blocking all browser-based clients from using the Zen/Go API entirely.

The fix is straightforward on paper — the gateway isn't responding to OPTIONS preflight requests, so they fall through to the frontend SPA router which returns a 404 HTML page instead of CORS headers. Same root cause as #10047 where basic auth was blocking OPTIONS — just at a different layer in the routing stack. The gateway needs to handle OPTIONS with proper CORS headers (Access-Control-Allow-Origin: *, Access-Control-Allow-Methods: POST, GET, OPTIONS, Access-Control-Allow-Headers: Authorization, Content-Type) before requests hit the SPA router.

I've confirmed this is still reproducible:

OPTIONS /zen/go/v1/chat/completions → HTTP 404 (full SPA HTML page, zero CORS headers)
POST   /zen/go/v1/chat/completions → HTTP 401 ("Model test is not supported" — backend alive)

Happy to test if you push a branch. Until this is fixed, anyone trying to use OpenCode from browser-based clients (web UIs, custom frontends, AI chat platforms, etc.) is completely blocked.

[Pebrd]

Same issue here with ONLYOFFICE Desktop Editors 9.4.0 (Flatpak, Linux).

The desktop app uses a Chromium webview internally, so it enforces CORS just like a browser. When configuring a custom OpenAI-compatible endpoint pointing at /zen/v1/, the GET /v1/models call returns 200 OK but the response is silently discarded because the Access-Control-Allow-Origin header is missing. The CORS preflight (OPTIONS) also gets the same 404 HTML page.

This means ANY Chromium-based desktop app (Electron, CEF, Tauri webview) is affected — not just web browsers.

Reproduced on:

• ONLYOFFICE Desktop Editors 9.4.0 (Flatpak)
• Also confirmed on the web editor (same Chromium CORS behavior)

The proposed fix in the issue description (handling OPTIONS at the gateway level) would solve this for all affected clients.

[MMesch]

Same issue with JupyterLite + JupyterLiteAI

[nilcaream]

Hi. I have the same piece of code handling OpenAI-compatible APIs in browser for OpenRouter and OpenCode. OpenRouter supports OPTIONS while OpenCode Go does not. This is simply a lack of CORS support on OpenCode side. Fix is appreciated.