ChatGPT OAuth rejects GPT-5.6 models for an EU-resident workspace, while official Codex CLI succeeds

[lhammingNedap]

Description

• Using the TUI, version 1.18.11
• Last known version is also 1.18.11. This has been broken since last thursday.

My OpenAI workspace has EU data/inference residency enabled.

I am currently authorized using Oauth directly with OpenAI. I am unable to make an API key for my project.

I am able to use the chatGPT / codex application and prompt just fine there.

Just out of curiosity, are EU-resident workspaces supported?
Can other people work just fine with OpenCode with EU data/inference residency enabled?

Would love to get some help with this issue :)

(Also created this issue on discord)

Plugins

None

OpenCode version

1.18.11

Steps to reproduce

1. Create an OpenAI project with EU data/inference residency enabled
2. Start opencode
3. Connect using Oauth
4. Try the GPT 5.6 models (luna, terra and sol)

Screenshot and/or share link

Operating System

MacOs Tahoe 26.4

Terminal

Default MacOS terminal and GhostTTY

[adamtrepka]

I independently hit the same issue and did extensive debugging. Here are detailed findings that may help track down the root cause.

Environment: OpenCode 1.17.9 · Codex CLI 0.146.0 · Windows 11 Enterprise · ChatGPT Business, EU data residency · OAuth auth

Key finding: Codex CLI succeeds with the exact same account and credentials. Tested via:

echo "Say OK" | codex exec -m "gpt-5.5" --dangerously-bypass-approvals-and-sandbox
# → OK

echo "Say OK" | codex exec -m "gpt-5.6-sol" --dangerously-bypass-approvals-and-sandbox
# → OK

opencode run --model "openai/gpt-5.5" --agent plan "Say OK"
# → data_residency_mismatch

Model availability (OpenCode, EU account):

Status	Models
Works	gpt-5.4-mini, gpt-5.4-mini-fast
data_residency_mismatch	gpt-5.4, gpt-5.5, gpt-5.6-luna, gpt-5.6-sol, gpt-5.6-terra and -fast/-pro variants
Not supported on Codex plan	gpt-5.3-codex-spark, gpt-5.5-pro, gpt-5.6, gpt-5.6-pro

Request comparison — OpenCode vs Codex CLI:

Both send identical:

• Endpoint: https://chatgpt.com/backend-api/codex/responses
• Body: model: "gpt-5.5", store: false, stream: true, include: ["reasoning.encrypted_content"]
• Auth: same OAuth token with same JWT claims (chatgpt_data_residency: "eu", chatgpt_compute_residency: "eu")
• Same ChatGPT-Account-Id header

What I tried via OpenCode plugin (all confirmed active via fetch interception logs):

Override	Result
originator: codex_cli_rs (fetch-level, after built-in hook)	Still fails
x-openai-internal-codex-residency: us	Still fails
x-openai-product-sku: codex	Still fails
All three combined	Still fails
OPENCODE_EXPERIMENTAL_WEBSOCKETS=true	Still fails

The OpenAI backend rejects the request regardless of header values. The exemption for Codex CLI appears to be based on something beyond HTTP headers — possibly transport-level (Rust reqwest vs Bun fetch), Cloudflare routing, or server-side client classification.

PR #15844 attempted to add the residency header but even with it applied, the issue persists.

[adamtrepka]

Update: oh-my-pi had the exact same issue and already fixed it — can1357/oh-my-pi#7198.

Root cause confirmed: OpenAI backend enforces data residency on HTTP/SSE transport but not on WebSocket. Their V2 compaction was using direct fetch() (SSE) to chatgpt.com/backend-api/codex/responses, while the official Codex CLI uses WebSocket-first transport. Switching to WebSocket resolved the issue.

The fix was in can1357/oh-my-pi#7202 — routing requests through the WebSocket-capable provider session instead of direct SSE fetch.

OpenCode has OPENCODE_EXPERIMENTAL_WEBSOCKETS support in the Codex plugin, but it does not seem to cover all request paths (I tested with the env var enabled and it still failed — possibly title generation or other requests still go through HTTP).

[lordthorzonus]

I'm hitting the same issue using an enterprise chatgpt license connected through the browser oauth.

• gpt-5.4-mini, gpt-5.4-mini-fast are also the only working models for me. All other models fail with the same "The requested model snapshot is not available for your project's geography. If you need regional processing, consider switching to a model that officially supports it: https://developers.openai.com/api/docs/guides/your-data#which-models-and-features-are-eligible-for-data-residency" error
• official codex cli 0.146.0 works with all the models using the same account
• using opencode tui version 1.18.11
• I'm based in Finland/EU

Happy to provide more info / test things if it helps debugging 🙏

[lhammingNedap]

There is currently a workaround for this issue, but this is no permanent fix.

Someone published a plugin for opencode that fixes this issue by monkey-patching the fetch and appending the required headers to imitate the communication that codex does:
https://github.com/DusKing1/opencode-openai-residency

[adamtrepka]

@nexxeln Is there a chance to fix this problem in the near future?

[rekram1-node]

I will look into this

[rekram1-node]

I'm not too familiar w/ residency configs, in codex do u have enforce_residency specified in your config?

Is this something that used to work in opencode but then stopped? Or has it never worked. If we added support for this enforce_residency config option and sending the header would it fix it?

We have websocket support u can enable but if residency stuff only works via websockets it is probably a bug on openais side.

[lhammingNedap]

No, I don’t have enforce_residency in my Codex config (/debug-config shows no value for it).
I started seeing this last Thursday, but before this Sol, Terra and Luna models worked.

The residency plugin fixes it for me by setting enforce_residency: "eu" and sending the header. So adding native support for that option/header would very likely fix this case.

It’s not WebSocket-only: Sol, Terra and Luna work with the plugin on the normal HTTP path.

[rekram1-node]

@neriousy appears to have a fix here: #42432

I think we will merge and release soon but if anyone wants to test in the meantime