›_ Codex Issues
Codex Issues / #33029

Codex Desktop should not block custom-provider sessions on chatgpt.com metadata timeouts

Open 💬 0 comments Opened Jul 14, 2026 by zhyuzhyu

Summary

When Codex Desktop is used with a custom OpenAI-compatible model provider, the core model endpoint can be fast and healthy, but the Desktop UI still depends on auxiliary chatgpt.com/backend-api/wham/* requests.

In networks where chatgpt.com is unreachable or DNS-poisoned unless a system proxy/TUN is enabled, Codex Desktop can become very slow or effectively unusable even though the configured custom model provider is reachable. Codex CLI remains fast in the same setup because it mainly uses the configured model provider path.

This became noticeable after the Desktop app moved from the standalone Codex.app behavior to the ChatGPT.app shell.

Environment

  • OS: macOS 26.5.2 (25F84)
  • App: ChatGPT.app / bundle id com.openai.codex
  • App version: 26.707.72221, build 5307
  • Bundled CLI: codex-cli 0.144.2
  • Model provider: custom OpenAI-compatible gateway
  • Wire API: responses
  • supports_websockets = false
  • requires_openai_auth = true
  • Model: gpt-5.6-terra
  • Network: Mainland China network where direct chatgpt.com access is unreliable/unreachable without a system proxy

Relevant config shape:

model = "gpt-5.6-terra"
model_provider = "custom"

[model_providers.custom]
base_url = "https://<custom-openai-compatible-gateway>/v1"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false

Steps to reproduce

  1. Configure Codex Desktop to use a custom OpenAI-compatible provider.
  2. Use a network where the custom provider is reachable, but chatgpt.com is not reachable directly.
  3. Start or resume a Desktop conversation.
  4. Observe that the Desktop UI becomes very slow or appears stuck during planning/reasoning, even though the custom provider endpoint is responsive.
  5. Enable a system proxy/TUN that makes chatgpt.com reachable, then restart the app. The issue is mitigated.

Observed behavior

The custom model endpoint is responsive:

GET https://<custom-openai-compatible-gateway>/v1/models
total ~= 0.10s

Direct chatgpt.com requests from the same machine time out without a system proxy:

GET https://chatgpt.com/backend-api/wham/tasks/list
curl: (28) Connection timed out after 15006 milliseconds

The Desktop log repeatedly shows failing chatgpt.com auxiliary calls:

[electron-fetch-wrapper] desktop_fetch_auth_401 target="GET https://chatgpt.com/backend-api/wham/tasks/list"
[electron-fetch-wrapper] desktop_fetch_auth_401 target="GET https://chatgpt.com/backend-api/wham/usage"

[electron-message-handler] sa_server_request_failed
errorMessage=net::ERR_CONNECTION_RESET
routePattern=/wham/tasks/list
status=500
url=/wham/tasks/list?limit=20&task_filter=current

[electron-message-handler] sa_server_request_failed
errorMessage=net::ERR_CONNECTION_RESET
routePattern=/wham/usage
status=500
url=/wham/usage?supports_rewardless_invites=true

One affected turn showed only this reasoning summary and then appeared stuck:

Reasoning summary item completed
summary=["**Planning network timeout handling**"]

After enabling a system proxy at 127.0.0.1:7897, the same chatgpt.com request becomes responsive:

GET https://chatgpt.com/backend-api/wham/tasks/list
via proxy total ~= 1.02s

Expected behavior

When a custom model provider is configured and reachable:

  1. Core local/custom-provider conversations should not be blocked by chatgpt.com metadata failures.
  2. wham/tasks/list, wham/usage, experiment/config, remote-control, or other auxiliary ChatGPT backend calls should fail fast and degrade gracefully.
  3. The Desktop UI should show a non-blocking warning for unavailable ChatGPT-side features instead of slowing down or stalling the main conversation flow.
  4. Ideally, provide a documented config flag to disable ChatGPT backend metadata/remote-control/background refresh paths for custom-provider/local-only workflows.

Why this matters

For users behind restricted or expensive proxy networks, chatgpt.com availability is a separate condition from custom model provider availability.

In this setup:

  • Codex CLI is fast.
  • The custom model provider is fast.
  • Codex Desktop becomes slow or unusable because the ChatGPT App shell keeps touching chatgpt.com endpoints.

This makes Desktop unreliable for custom-provider workflows even when the actual model backend is healthy.

Related issues

This is related to, but not identical to:

  • #27952: chatgpt.com endpoint overhead / connection volume
  • #30409: Desktop metadata-call failures should not take over the home screen
  • #22466: custom provider workflows still depending on ChatGPT backend paths
  • #29156: Desktop custom-provider UX limitations

The difference here is specifically: custom-provider model calls are healthy, but Desktop turn usability is degraded by unreachable chatgpt.com auxiliary endpoints.

View original on GitHub ↗