Skip to content

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

Open
Open
Windows: Codex desktop loses VS Code connection after first message, main "New chat" button stops working, app-server exits after plugin 403#17244
Labels
appIssues related to the Codex desktop appbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@DorukG
DorukG
opened on Apr 9, 2026

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.

Activity

  1. DorukG
    added
    appIssues related to the Codex desktop app
    on Apr 9, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    on Apr 9, 2026

  3. github-actions commented on Apr 9, 2026

    @github-actions
    github-actionsbot
    on Apr 9, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. DorukG commented on Apr 9, 2026

    @DorukG
    DorukG
    on Apr 9, 2026
    Author

    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.

  5. kristof-toth-wuerth-hu commented on Apr 10, 2026

    @kristof-toth-wuerth-hu
    kristof-toth-wuerth-hu
    on Apr 10, 2026

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

  6. kristof-toth-wuerth-hu commented on Apr 10, 2026

    @kristof-toth-wuerth-hu
    kristof-toth-wuerth-hu
    on Apr 10, 2026

    @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..

  7. Sahil170595 commented on Apr 16, 2026

    @Sahil170595
    Sahil170595
    on Apr 16, 2026 – with ChatGPT Codex Connector

    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.

  8. BaggyG-AU commented on May 30, 2026

    @BaggyG-AU
    BaggyG-AU
    on May 30, 2026

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions