Windows: Codex panel renders once, then goes black on every subsequent open (webview never requests React render)

Windows: Codex panel renders once, then goes black on every subsequent open (webview never requests React render)

What version of the IDE extension are you using?

26.727.40816 (bundled Codex CLI 0.146.0-alpha.9.2)

What subscription do you have?

ChatGPT (signed in via codex login — Logged in using ChatGPT)

Which IDE are you using?

VS Code 1.130.0 (commit 1b6a188127eeaf9194f945eb6eb89a657e93c54c, x64)

What platform is your computer?

Windows 11 Pro 10.0.26200, x64

What issue are you seeing?

On Windows, the Codex panel renders correctly on the first open after a window
reload, and then shows a black/blank panel on every subsequent open. The
extension host stays alive and the app-server process keeps running — but the
webview never gets as far as requesting a React render.

This is visible in the Codex output channel. A successful open logs this sequence:

[IpcRouter] I am the router
[IpcClient] Received broadcast but no handler is configured method=client-status-changed
[statsig-refresh-diagnostics] React root render requested windowType=extension
...
[startup][renderer] app routes mounted after 2884ms

A failing (black) open stops after two lines and never continues:

17:08:10.894 [info]    [IpcRouter] I am the router
17:08:10.896 [warning] [IpcClient] Received broadcast but no handler is configured method=client-status-changed
17:08:23.952 [info]    [IpcRouter] I am the router
17:08:23.957 [warning] [IpcClient] Received broadcast but no handler is configured method=client-status-changed

No React root render requested, no app routes mounted, no error, no timeout,
no retry affordance. The panel just stays black.

Note that every webview instance logs [IpcRouter] I am the router. If the
router role is meant to be exclusive, more than one instance claiming it looks
like it could be the point of failure.

What steps can reproduce the bug?

1. Install the extension on Windows 11 / VS Code 1.130.0.
2. Reload the window.
3. Open the Codex panel — it renders correctly.
4. Close the panel and open it again (or open it in a second editor group).
5. The panel is black. It stays black until the next full window reload.

What is the expected behavior?

The panel should render on every open, not only the first one after a reload.
Failing that, it should surface an initialization error or time out with a retry
action instead of showing an indefinitely black webview.

Additional information

Related issues. This looks like the same family as #34184 and #34308, but
both of those are Linux and the #34308 workaround is Linux-specific (editing the
packaged .desktop entry so VS Code launches through the wrapper script that
sets up the environment). This report is Windows, where that workaround has no
equivalent. The shared signature across all three is the [IpcRouter] I am the
router + client-status-changed has no handler pair immediately preceding the
hang.

A second, possibly unrelated error fires on every panel open, including opens
that render successfully — so it may be noise, but it is 100% reproducible:

[error] Request failed conversationId=none durationMs=56
  error={"code":-32603,"message":"The system cannot find the path specified. (os error 3)"}
  method=fs/readFile priority=interactive source=filesystem

On Windows, os error 3 is ERROR_PATH_NOT_FOUND (a directory component of
the path is missing), not ERROR_FILE_NOT_FOUND (os error 2). So something is
reading a file under a directory that does not exist. The request carries
conversationId=none, so it happens before any thread is attached. The log does
not include the path being read, which makes this undiagnosable from the user
side — please consider logging the path on fs/* failures.

I initially suspected a stale Codex Cloud environment persisted in VS Code's
state.vscdb under the openai.chatgpt key, which had workspace_dir:
"/workspace" — a POSIX path that cannot resolve on Windows. Removing that key
did not fix the black panel and did not stop the fs/readFile error, so
that was a dead end, but it may be worth noting that the persisted environment
survives with a POSIX workspace_dir on a Windows host.

Also seen on every open (auth is otherwise healthy —
[chatgpt-account-lookup] completed authenticatedAccountPresent=true
authMethod=chatgpt result=succeeded):

[error]   Error fetching httpStatus=403 statusText=Forbidden url=/settings/user
[warning] sa_server_request_failed attachAuth=false ... status=403 url=/settings/user

Note attachAuth=false — the request to /settings/user goes out without auth
attached, which would explain the 403.

The CLI itself is healthy. Using the CLI bundled with this extension:

$ codex --version
codex-cli 0.146.0-alpha.9.2

$ codex login status
Logged in using ChatGPT

$ codex exec --sandbox read-only --skip-git-repo-check "Reply only with: WORKS"
WORKS

So the backend, auth and app-server all work. The failure is confined to the
VS Code webview layer.

Things tried that did not fix it:

• Reloading the window (fixes it for exactly one open).
• Killing all codex.exe app-server processes so they respawn clean.
• Removing the stale persisted cloud environment from state.vscdb.
• Applying the workaround from #34184 (disabling all plugins plus

apps = false / remote_plugin = false in ~/.codex/config.toml).

Environment note: this machine also has the standalone Codex desktop app
installed, shipping codex-cli 0.144.2, which shares the same CODEX_HOME
(~/.codex) with the extension's 0.146.0-alpha.9.2. I don't have evidence this
is causal, but two CLI versions sharing one CODEX_HOME seems worth flagging.