›_ Codex Issues
Codex Issues / #17244

Windows: Codex desktop loses VS Code connection after first message, main "New chat" button stops working, app-server exits after plugin 403

Open 💬 6 comments Opened Apr 9, 2026 by DorukG
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.406.31014

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

On Windows, Codex desktop became stuck in a broken state after a VS Code .ipynb / Jupyter-triggered extension host crash.

After that:

  • a brand-new empty chat shows the VS Code button in the top-right
  • the moment I send the first message, the VS Code button disappears
  • the main New chat button does nothing
  • the New chat button next to Threads still works
  • Codex desktop starts with zero discovered connections
  • Codex app-server later exits after plugin bootstrap hits Cloudflare 403 Forbidden
  • When I close Codex and I try opening it from the "Hidden Icons" it doesn't come up. I have to manually close it and reopen the app.

This survives reboot, Codex reinstall/reset, VS Code extension reinstall, deleting Codex local package data, and testing on a different network/hotspot.

Original trigger

The first trigger appears to be VS Code notebook/Jupyter related.

Steps:

  1. Open a .ipynb in VS Code
  2. VS Code starts selecting a kernel
  3. It appears to find one, then loses it and retries
  4. VS Code then shows:

Extension host terminated unexpectedly 3 times within the last 5 minutes

A VS Code extension bisect pointed to Jupyter as the trigger for that original crash.

What steps can reproduce the bug?

  1. Launch Codex desktop
  2. Open a brand-new empty chat
  3. Observe the VS Code button is visible in the top-right
  4. Send the first message
  5. Observe the VS Code button disappears
  6. Try the main New chat button
  7. Observe it does nothing

What is the expected behavior?

  • Codex desktop should keep the VS Code connection available after the first message
  • the main New chat button should create a new chat
  • a VS Code/Jupyter crash should not leave Codex desktop permanently unable to discover connections

Additional information

Actual behavior

  • Codex desktop repeatedly reports zero available connections
  • the VS Code button disappears as soon as the first message is sent
  • the main New chat button is nonfunctional
  • the issue persists across reset/reinstall/reboot
  • testing on a phone hotspot did not resolve it

Diagnostics

1. Codex desktop boots with zero connections

Desktop logs repeatedly show:

  • discoveredConnectionCount=0
  • totalConnectionCount=0
  • shared_object_synced connectionCount=0
  • availableConnectionCount=0
  • selectedRemoteHostId=null

This suggests the app is not starting with a healthy editor connection and then losing it. It already believes there are no attachable connections.

2. VS Code Codex bridge appears to be in a bad IPC state

VS Code Codex logs show warnings like:

  • Received broadcast but no handler is configured method=client-status-changed
  • repeated thread-stream-state-changed
  • repeated thread-read-state-changed

This looks like an internal Codex bridge / event subscription issue, not just a Jupyter kernel failure.

3. Codex plugin bootstrap is failing with Cloudflare 403

Codex logs show plugin bootstrap requests hitting Cloudflare challenge pages:

  • https://chatgpt.com/backend-api/plugins/list
  • https://chatgpt.com/backend-api/plugins/featured

Later the desktop log shows:

  • app-server transport stopping
  • worker exit code=1

A different network/hotspot did not change this.

What I already tried

  • rebooted PC
  • reinstalled VS Code OpenAI extension
  • reinstalled Codex desktop
  • used Windows app Terminate, Repair, and Reset
  • deleted Codex local package data
  • disabled suspect VS Code extensions
  • used a fresh VS Code profile
  • tested on a different network / hotspot

None of these resolved the issue.

The Jupyter/Notebook crash appears to be the original trigger, but the persistent failure afterward looks like a Codex desktop recovery / connection-management / UI-state bug.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 3 months ago

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

  • #16618
  • #16808

Powered by Codex Action

DorukG · 3 months ago

Additional note: Right before the bug triggered, I had 80% weekly usage left. When the bug started and I reinstalled the app, my usage suddenly went back up to 100%. Weirdly enough, my usage shows 100% on the website too.

kristof-toth-wuerth-hu · 3 months ago

On this exact same version if you go to File -> Setting the "Back to app" button does nothing also.

kristof-toth-wuerth-hu · 3 months ago

@DorukG I figured out the usage left. It's not how much you used until now, it's how much you have left. They inverted the number..

Sahil170595 · 3 months ago

Posted this on the wrong issue initially.

This comment was intended for the separate Windows sidebar New Chat / hit-testing problem, not the VS Code connection-loss flow described here.

The specific symptom I meant to report is:

  • the top-left sidebar New chat button does not respond to click
  • Ctrl+N still creates a new chat successfully

That points more toward a UI click / hit-testing bug than a broken new-chat action itself.

BaggyG-AU · 1 month ago

Reproducing on the latest extension (26.527.31454) — with a root-cause trace pointing at the webview↔host RPC bridge

Confirming this on a clean, current setup, and adding diagnostic detail that may explain the availableConnectionCount=0 / dead "New chat" state — same "one New Chat path works, the other doesn't" split described here.

  • IDE extension version: 26.527.31454
  • Subscription: ChatGPT Plus
  • IDE: VS Code 1.119.0 (commit 8b640eef5a), x64
  • Platform: Windows 11 (10.0.26200) x64

What I'm seeing

  • In the agent panel (editor-tab webview), New Chat is a silent no-op — no thread created, and the history list is empty even though ~/.codex/sessions holds saved rollout files and session_index.jsonl lists them.
  • The panel composer still works, and the sidebar "New Thread in Codex Sidebar" works — matching the split reported here.
  • The click dispatches in the renderer (Sentry-wrapped BODY.click fires) but sends no backend request (no Conversation created in the extension host log) and throws no app-level exception.
  • No Jupyter/notebook involvement in my case — so the broken end-state isn't exclusive to the Jupyter-crash trigger.

Root-cause trace (webview DevTools, "pause on caught exceptions", with VS Code core workbench.desktop.main.js ignore-listed). During webview mount the host↔webview RPC bridge aborts:

index.extension-*.js   throw Error(`bad RPC message: ["abort", …]`)
index.extension-*.js   abort(...)  value: Error: no such export ID: 1   → cancelReadLoop
   ↳ unwinds through `await in gl` at app-main-*.js:57

no such export ID: 1 means the root remote-API proxy reference is gone, so the awaited connection loop (gl) aborts — leaving thread create/list inert while the independent composer survives. This is consistent with the discoveredConnectionCount=0 / availableConnectionCount=0 and the Received broadcast but no handler is configured method=client-status-changed / …=thread-stream-state-changed warnings already reported here (I see the same ones).

Ruled out (to save others time)

  • Not the Statsig 403 on chatgpt.com/ces/v1/rgstr (Cloudflare CF-Mitigated: challenge) — those are caught by Statsig's own ErrorBoundary; clicking New Chat and waiting >20s (past the 10s flush timeout) still does nothing.
  • Not local state corruption — reproduced on a freshly-reset ~/.codex; new threads still persist to disk.
  • Not version / blank-panel — latest 26.527.31454; the panel renders fine.
  • Not auth_elicitation — that startup -32600 was fixed between 26.519 and 26.527.

Steps to reproduce

  1. Open the Codex agent panel (editor tab) in VS Code on Windows.
  2. Click New Chat in the panel.
  3. Observe: nothing happens — no new thread, history list stays empty. The sidebar "New Thread in Codex Sidebar" works, and typing in the panel composer works.

Expected behavior
New Chat in the agent panel should create a new thread (as the sidebar does), and the history list should show existing threads from ~/.codex/sessions.

Workaround: use the Codex sidebar ("New Thread in Codex Sidebar") for new chats; the panel composer still works for the current thread.

This looks like the same underlying connection/IPC failure behind the history-loading reports (#18993, #19137). Happy to provide full app-server logs or a complete bridge trace if useful — just let me know what format helps most.