Im run into this issue, were its trying to reconnect

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #17199
• #16532
• #16395

Powered by Codex Action

If you're able to repro, please use /feedback to upload logs and session details, then post the thread ID here.

I have this exact same issue on debian + vscode + vscode codex IDE extension (v 0.119.0-alpha.11) and codex-cli (v 0.118.0)

This only happens on new tasks. Once codex gets past this reconnecting issue it works completely fine.

thread ID: 019d76d3-0559-7330-a5e3-a83ef3283710

Remediations tried without success:

• installing pre-release codex plugin
• restarting vscode
• logging out / in with ChatGPT login in the plugin
• killed any running codex session pkill -f codex
• removed ~/.codex/auth.json and logged back in with chatGPT login in the plugin
• signed out of Github in VSCode (in case that would have somehow stepped on Codex plugins toes)

EDIT: same issue when using codex-cli (v 0.118.0)

I ran the codex-tui.log through Codex (heh), and it pointed out this pattern that is perhaps related:

During startup, Codex gets 403 Forbidden responses on plugin/apps/discoverable-tools bootstrap requests, including Cloudflare challenge HTML for /backend-api//connectors/directory/list, then the responses websocket warmup starts and closes after 15.0s.

75881  2026-04-09T19:57:23.794731Z  WARN codex_core::plugins::manager: failed to warm featured plugin ids cache error=remote plugin sync request to https://chatgpt.com/backend-api/plugins/featured failed with status 403 Forbidden: <html>

75946  2026-04-09T19:57:24.908363Z  WARN codex_core::codex: failed to load discoverable tool suggestions: request failed with status 403 Forbidden: <html>

76064  2026-04-09T19:57:40.205167Z  WARN codex_tui::chatwidget: failed to load full apps list; falling back to installed apps snapshot: Failed to load apps: Request failed with status 403 Forbidden: <html>

76100  2026-04-09T19:57:41.075920Z  INFO model_client.stream_responses_websocket{model=gpt-5.4 wire_api=responses transport="responses_websocket" api.path="responses" turn.has_metadata_header=true websocket.warmup=true}: codex_core::client: new

76101  2026-04-09T19:57:41.076577Z  INFO model_client.stream_responses_websocket{model=gpt-5.4 wire_api=responses transport="responses_websocket" api.path="responses" turn.has_metadata_header=true websocket.warmup=true}:model_client.websocket_connection{provider=OpenAI wire_api=responses transport="responses_websocket" api.path="responses" turn.has_metadata_header=true}: codex_core::client: new

76102  2026-04-09T19:57:56.078014Z  INFO model_client.stream_responses_websocket{model=gpt-5.4 wire_api=responses transport="responses_websocket" api.path="responses" turn.has_metadata_header=true websocket.warmup=true}:model_client.websocket_connection{provider=OpenAI wire_api=responses transport="responses_websocket" api.path="responses" turn.has_metadata_header=true}: codex_core::client: close time.busy=334µs time.idle=15.0s

76103  2026-04-09T19:57:56.078361Z  INFO model_client.stream_responses_websocket{model=gpt-5.4 wire_api=responses transport="responses_websocket" api.path="responses" turn.has_metadata_header=true websocket.warmup=true}: codex_core::client: close time.busy=1.34ms time.idle=15.0s

Current failure mode is not a normal auth failure: startup requests to chatgpt.com/backend-api/plugins/featured and /backend-api//connectors/directory/list receive 403 Forbidden with Cloudflare challenge HTML ("Enable JavaScript and cookies to continue"), followed by the responses websocket warmup timing out after 15.0s.

Double slashes (/backend-api//connectors/) are not a typo.

Observed CF ray IDs include 9e9c15fa8b958d95, 9e9c16017b20b8cb, and 9e9c16611c769a02.

As other similar issues have noted, this issue seems ipv6 related.

So adding this to /etc/hosts is a blunt workaround for now.

104.18.32.47 chatgpt.com
172.64.155.209 chatgpt.com

Additional deterministic Windows reproduction, still present on a current build:

• Codex App: 26.803.5235.0
• Bundled core: 0.147.0-alpha.6.5
• Windows x64
• Thread ID: 019faeb4-bd7f-7351-b491-6e3bf24309da

Reproduction:

1. Keep the Codex desktop app running.
2. Create any new task/thread.
3. Send a trivial first prompt such as test.
4. The first turn always runs through Reconnecting... 1/5 to 5/5, then eventually succeeds.
5. Subsequent turns in that same thread work normally.
6. Creating another new thread reproduces the full 5/5 sequence again.

What I ruled out:

• Rebooted Windows, updated WSL, ran wsl --shutdown, then wsl -e true; no change.
• Tested while using a fixed, stable proxy node rather than auto-select/load balancing; no change.
• Local desktop logs show thread/start succeeding in about 380 ms and turn/start in about 17 ms, so local thread creation completes before the reconnect loop.
• Windows native sandbox setup generally logs errors=[] and read ACL run completed.

Proxy setup (possibly relevant):

• Two proxy applications are installed.
• Clash Verge exposes proxy port 7897, but its system proxy toggle is disabled and it is not the active system proxy.
• The currently active proxy application is “超实惠加速”, using local proxy port 7892.
• There is currently no %USERPROFILE%\.codex\.env file explicitly setting HTTP_PROXY / HTTPS_PROXY for Codex.
• This may mean the desktop shell and the response WebSocket/HTTP fallback are not consistently inheriting the same active proxy path.

One secondary observation:

• I observed one native sandbox launch failure: CreateProcessWithLogonW failed: 1056. Later sandbox commands work, and the reconnect symptom happens on the first plain response before any tool invocation, so this may be unrelated.

This matches the report above exactly: only new tasks trigger the reconnect loop; once Codex gets past it, the thread works normally.