VS Code Codex: central editor panel opens blank on Windows because custom URI route uses fsPath

Open 💬 20 comments Opened May 9, 2026 by lcv-leo

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the IDE extension are you using?

openai.chatgpt / Codex VS Code extension 26.506.31004 (win32-x64)

Installed path observed locally:

C:\Users\leona\.vscode\extensions\openai.chatgpt-26.506.31004-win32-x64

Which IDE are you using?

VS Code on Windows.

What issue are you seeing?

Opening a new Codex central editor panel via the VS Code command chatgpt.newCodexPanel can create a completely blank/white editor area instead of rendering the Codex chat UI.

In my local repro, the official Codex sidebar could be opened, and the command did create an editor tab, but the central webview did not render the chat UI.

Code-level diagnosis

The extension creates the new central panel through a custom URI route:

createNewPanel() {
  let e = g_("/extension/panel/new");
  ...
  vscode.commands.executeCommand("vscode.openWith", e, customEditorViewType, ...)
}

The URI helper builds an openai-codex://route/... URI, and resolveCustomEditor() parses it through h_(uri). In the shipped bundle, the parser destructures uri.path as n, but returns uri.fsPath as the route path:

function h_(t) {
  let { scheme:e, authority:r, path:n } = t;
  ...
  return { path:t.fsPath, conversationId:s };
}

For a custom-scheme URI with an authority on Windows, fsPath is not a web route. It is treated like a filesystem/UNC-style path, while the webview route expected by the React app is the URI path, e.g. /extension/panel/new.

That means the webview can receive an invalid initial-route value for the new panel route. Conversation IDs are handled separately through /local/${id}, so the most visible failure is the new central panel route.

Local hotfix that resolved it

Changing the parser return value from t.fsPath to the already destructured n fixed the blank central panel locally after reloading VS Code:

- { path:t.fsPath, conversationId:s }
+ { path:n,       conversationId:s }

After this local patch, chatgpt.newCodexPanel opened the central Codex chat UI correctly.

Static validation performed locally:

node --check out/extension.js: PASS
old marker {path:t.fsPath,conversationId:s}: 0 after patch
new marker {path:n,conversationId:s}: 1 after patch

Expected behavior

The parser for openai-codex://route/... should use uri.path for route navigation, not uri.fsPath, so the initial webview route remains platform-independent.

Why this matters

This is a Windows-specific footgun because fsPath is intended for filesystem paths and is not safe for custom URI route parsing. The same route parser is responsible for central Codex panels, so one bad route value can leave the editor-area webview blank with little diagnostic surface for the user.

View original on GitHub ↗

20 Comments

lcv-leo · 2 months ago

Adjacent UX suggestion: make the official Activity Bar entry a conversation picker

While investigating this, I built a local companion extension to approximate the Claude Code VS Code behavior. The workflow felt materially better and could be worth adopting directly in the official Codex extension.

Suggested official behavior:

Clicking the Codex Activity Bar icon should open a sidebar/picker, not immediately create a new central editor chat.
The picker should show recent Codex conversations/sessions.
It should expose an explicit New Chat action.
Selecting an existing conversation should open that conversation in the central editor using the existing custom editor route, e.g. openai-codex://route/local/<conversationId> with chatgpt.conversationEditor.
The sidebar should remain open while the central editor tab opens, matching the Claude Code UX pattern.
Opening an existing conversation should warm/activate the app-server path and use a bounded retry or timeout, because resumed sessions can be slow or intermittently blocked by app-server/SQLite startup work.

The local companion implementation used:

~/.codex/session_index.jsonl as a lightweight recent-session index for the picker.
vscode.commands.executeCommand("vscode.openWith", uri, "chatgpt.conversationEditor", ...) for existing sessions.
chatgpt.newCodexPanel only when the user explicitly chooses New Chat.
no hardcoded official extension install path; it resolves openai.chatgpt through the VS Code extension API.

This would also reduce confusion around the current central-panel behavior: the Activity Bar would become a stable navigation surface, and users would choose whether they want a new chat or a previous one.

github-actions[bot] contributor · 2 months ago

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

#20188

Powered by Codex Action

BaggyG-AU · 1 month ago

Confirming this is still happening and that the suggested fix works. I've been chasing this for weeks.

Environment: Windows 11, VS Code, Codex extension openai.chatgpt 26.519.32039.

Symptom: "Codex: New Codex Agent" (chatgpt.newCodexPanel) opened a completely black editor tab — no chat UI, no input field. The Codex sidebar chat worked perfectly the whole time, which made it confusing. Logs showed the webview never mounting its routes and a repeating loadResource listener leak each time the panel opened.

Fix that worked: Applying the change described here — in out/extension.js, swapping {path:t.fsPath,conversationId:s} to use the destructured path ({path:n,conversationId:s}) — then reloading the window. The panel now renders correctly and the agent starts as expected.

Would be great to get this merged, since the only alternatives right now are hand-patching the bundle or using "New Thread in Codex Sidebar" instead of the editor panel. Thanks to whoever traced the fsPath vs path root cause. 👍

lcv-leo · 1 month ago

Thanks @BaggyG-AU for the independent confirmation. The extra environment/version detail is useful, especially the part that the sidebar route works while chatgpt.newCodexPanel opens a blank editor tab. That helps separate this from a generic webview failure and keeps the focus on the editor-panel route construction.

The fact that the same fsPath -> destructured path change fixes it on openai.chatgpt 26.519.32039 suggests the root cause is still present in current extension builds.

One regression-test angle that would catch this cleanly: exercise the sidebar/open-thread path and the central editor-panel path separately on Windows-style URIs, and assert that the route payload keeps the parsed route path rather than recomputing it from Uri.fsPath. The sidebar path can stay healthy while the editor-panel custom URI route is broken, so those need separate coverage.

Stache73 · 1 month ago

I can reproduce a closely related failure on Windows with a newer Codex extension build.

Environment:

VS Code: 1.123.0 (x64)
Codex IDE extension: openai.chatgpt-26.602.40724-win32-x64
OS: Windows x64

Observed behaviour:

The Codex sidebar works and has an input composer.
The central/main editor Codex panel opens.
The central panel does not show an input field/composer, so it is not usable for chat/agent input.
Developer: Reload Window did not fix it.
Reinstalling the Codex extension did not fix it.

DevTools console observations from the broken central panel included webview warnings such as:

Unrecognized feature: 'local-network-access'.
An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can escape its sandboxing.
a blocked data:font/woff2 load due to font-src 'self' https://*.vscode-cdn.net
Statsig telemetry POST requests to https://chatgpt.com/ces/v1/rgstr... failing with 403

Those console entries may be incidental, but the user-visible failure is consistent: the editor-area Codex panel opens, while the composer/input field is missing. The current workaround is to use the sidebar and widen/maximise it.

This looks related to the central editor panel rendering/routing issue reported here, but in this newer version it is not a fully blank panel; it renders enough to open the panel but not enough to expose the input composer.

Stache73 · 1 month ago

Confirmed this local fix worked for my newer Windows repro.

Environment:

VS Code: 1.123.0 (x64)
Codex IDE extension: openai.chatgpt-26.602.40724-win32-x64
OS: Windows x64

Before patch:

Sidebar worked and had an input composer.
Central/main editor Codex panel opened, but the input composer was missing.
Developer: Reload Window did not fix it.
Reinstalling the Codex extension did not fix it.

Applied local patch in:

C:\Users\arvid\.vscode\extensions\openai.chatgpt-26.602.40724-win32-x64\out\extension.js

Changed:

{path:t.fsPath,conversationId:s}

to:

{path:n,conversationId:s}

Verification:

old marker count: 0
new marker count: 1
node --check out/extension.js: passed
after Developer: Reload Window, the central/main Codex panel worked and the input field appeared

So the same fsPath -> path route-parser fix appears to resolve the newer partial-render case too, where the panel is not fully blank but the composer/input field is missing.

Stache73 · 1 month ago

Reconfirmed on Windows after the newest Codex extension update available to me today (2026-06-09).

Environment:

VS Code: 1.123.0 (x64)
Codex IDE extension: openai.chatgpt-26.602.71036-win32-x64
OS: Windows x64

Observed behaviour after the extension update:

The Codex extension in the main/central VS Code panel opened, but the chat input/composer was missing, leaving the panel unusable.
This appears to be the same regression as before: the installed bundle again contained exactly one {path:t.fsPath,conversationId:s} marker and zero {path:n,conversationId:s} markers.

Applied the same local workaround in:

C:\Users\arvid\.vscode\extensions\openai.chatgpt-26.602.71036-win32-x64\out\extension.js

Changed:

{path:t.fsPath,conversationId:s}

to:

{path:n,conversationId:s}

Verification after patch:

old marker count: 0
new marker count: 1
node --check out/extension.js: passed
after reloading VS Code, the main/central Codex panel worked again and the chat input/composer appeared

So the fsPath -> path route-parser issue still appears to be present in 26.602.71036, and the same local patch still fixes the current build.

Stache73 · 1 month ago

Reconfirmed again on Windows after the latest Codex VS Code extension update available to me today (2026-06-20).

Environment:

VS Code: 1.125.1 (x64)
Codex IDE extension: openai.chatgpt-26.616.32156-win32-x64
OS: Windows x64

Observed behaviour after the extension update:

The Codex extension in the main/central VS Code panel opened, but the chat input/composer was missing, leaving the panel unusable.
The Codex sidebar still worked.
The installed bundle again contained exactly one {path:t.fsPath,conversationId:s} marker and zero {path:n,conversationId:s} markers before patching.

Applied the same local workaround in:

C:\Users\arvid\.vscode\extensions\openai.chatgpt-26.616.32156-win32-x64\out\extension.js

Changed:

{path:t.fsPath,conversationId:s}

to:

{path:n,conversationId:s}

Verification after patch:

old/broken marker count: 0
new/fixed marker count: 1
node --check out/extension.js: passed
after reloading VS Code, the main/central Codex panel worked again and the chat input/composer appeared

So the fsPath -> path route-parser issue still appears to be present in 26.616.32156, and the same local patch still fixes the latest build available to me.

Stache73 · 1 month ago

Another data point after today's extension update on Windows:

Affected build: openai.chatgpt-26.616.41845-win32-x64
Symptom: central/main Codex panel opened without the chat field/composer again.
The same local bundle workaround still fixes it: in out/extension.js, replace exactly one {path:t.fsPath,conversationId:s} with {path:n,conversationId:s}.
Verification after patch: broken marker count 0, fixed marker count 1, node --check passed, and after reloading VS Code the main-panel chat field returned.

Stache73 · 28 days ago

The same main-panel composer regression is still present in the latest Windows VS Code extension build I received:

Affected build: openai.chatgpt-26.616.51431-win32-x64
Affected file: out/extension.js
Symptom: the main/central Codex panel opens without the chat entry field/composer, while the sidebar still works.
Local workaround still works: replace exactly one {path:t.fsPath,conversationId:s} with {path:n,conversationId:s}.

Verification after applying the workaround locally:

Broken marker count: 0
Fixed marker count: 1
node --check C:\Users\arvid\.vscode\extensions\openai.chatgpt-26.616.51431-win32-x64\out\extension.js passes.

So this looks like the same regression as before, reintroduced again in 26.616.51431.

Stache73 · 27 days ago

Update for the latest Windows extension build: this bug is still present in openai.chatgpt-26.616.71553-win32-x64.

Observed on Windows after the extension updated again:

Main/central Codex editor panel had no chat input field again.
Installed bundle checked: C:\Users\arvid\.vscode\extensions\openai.chatgpt-26.616.71553-win32-x64\out\extension.js
Broken marker before patch: {path:t.fsPath,conversationId:s} count = 1
Fixed marker before patch: {path:n,conversationId:s} count = 0

The same local workaround still fixes it:

Back up extension.js
Replace exactly one {path:t.fsPath,conversationId:s} with {path:n,conversationId:s}
Verify afterwards that broken marker count is 0 and fixed marker count is 1
Run node --check on the patched extension.js
Reload VS Code

Verification after patch on 26.616.71553:

Broken marker count: 0
Fixed marker count: 1
node --check C:\Users\arvid\.vscode\extensions\openai.chatgpt-26.616.71553-win32-x64\out\extension.js passed
Reloading VS Code restored the main-panel chat input field

Stache73 · 26 days ago

Confirmed this still reproduces on Windows with extension build openai.chatgpt-26.616.81150-win32-x64.

Affected installed bundle:

C:\Users\arvid\.vscode\extensions\openai.chatgpt-26.616.81150-win32-x64\out\extension.js

Applied the same local workaround:

{path:t.fsPath,conversationId:s} -> {path:n,conversationId:s}

Verification:

Before patch: broken marker count 1, fixed marker count 0
After patch: broken marker count 0, fixed marker count 1
Backup created: C:\Users\arvid\.vscode\extensions\openai.chatgpt-26.616.81150-win32-x64\out\extension.js.bak-20260624-222054
node --check C:\Users\arvid\.vscode\extensions\openai.chatgpt-26.616.81150-win32-x64\out\extension.js passed
After reloading VS Code, Arvid confirmed the central Codex panel input field is back

Stache73 · 24 days ago

Confirmed recurrence and workaround for another Windows CEV extension build.

Affected extension build folder:

openai.chatgpt-26.623.31921-win32-x64

Installed bundle path:

C:\Users\arvid\.vscode\extensions\openai.chatgpt-26.623.31921-win32-x64\out\extension.js

Local workaround applied:

Replaced exactly one {path:t.fsPath,conversationId:s} with {path:n,conversationId:s}.

Marker counts:

Before patch:
broken marker {path:t.fsPath,conversationId:s}: 1
fixed marker {path:n,conversationId:s}: 0
After patch:
broken marker {path:t.fsPath,conversationId:s}: 0
fixed marker {path:n,conversationId:s}: 1

Backup created:

C:\Users\arvid\.vscode\extensions\openai.chatgpt-26.623.31921-win32-x64\out\extension.js.bak-20260626-110024

Verification:

node --check passed.
After reloading VS Code, Arvid confirmed that the central/main Codex panel chat input field was restored.

Stache73 · 23 days ago

The Windows main-panel/no-composer bug was reintroduced again in the latest CEV extension update on this machine and the same local marker replacement fixed it after reload.

Affected extension build folder:

openai.chatgpt-26.623.42026-win32-x64

Installed bundle path:

C:\Users\arvid\.vscode\extensions\openai.chatgpt-26.623.42026-win32-x64\out\extension.js

Patch applied:

Replaced exactly one {path:t.fsPath,conversationId:s} with {path:n,conversationId:s}

Marker counts:

Before broken marker count: 1
Before fixed marker count: 0
After broken marker count: 0
After fixed marker count: 1

Backup created:

C:\Users\arvid\.vscode\extensions\openai.chatgpt-26.623.42026-win32-x64\out\extension.js.bak-20260628-012857

Verification:

node --check passed
User reloaded VS Code and confirmed the CEV main-panel chat input field was restored

Stache73 · 21 days ago

Confirmed this still affects the Windows VS Code extension build openai.chatgpt-26.623.70822-win32-x64.

Installed bundle path:
C:\Users\arvid\.vscode\extensions\openai.chatgpt-26.623.70822-win32-x64\out\extension.js

Local workaround applied:

Replaced exactly one {path:t.fsPath,conversationId:s} with {path:n,conversationId:s}
Backup created at:

C:\Users\arvid\.vscode\extensions\openai.chatgpt-26.623.70822-win32-x64\out\extension.js.bak-20260630-003533

Marker counts:

Before patch:
broken marker {path:t.fsPath,conversationId:s}: 1
fixed marker {path:n,conversationId:s}: 0
After patch:
broken marker {path:t.fsPath,conversationId:s}: 0
fixed marker {path:n,conversationId:s}: 1

Verification:

node --check passed for the patched bundle.
After reloading VS Code, the central/main Codex panel chat input was restored.

Stache73 · 19 days ago

Adding another verified Windows data point for the recurring Codex Extension main-panel composer bug.

Affected extension build:

openai.chatgpt-26.623.81905-win32-x64

Installed bundle path:

C:\Users\arvid\.vscode\extensions\openai.chatgpt-26.623.81905-win32-x64\out\extension.js

Local workaround applied:

Replaced exactly one {path:t.fsPath,conversationId:s} with {path:n,conversationId:s}

Marker counts:

Before patch:
broken marker {path:t.fsPath,conversationId:s}: 1
fixed marker {path:n,conversationId:s}: 0
After patch:
broken marker {path:t.fsPath,conversationId:s}: 0
fixed marker {path:n,conversationId:s}: 1

Backup created:

C:\Users\arvid\.vscode\extensions\openai.chatgpt-26.623.81905-win32-x64\out\extension.js.bak-20260701-121751

Verification:

node --check passed.
After reloading VS Code, Arvid confirmed the main-panel chat input was restored: "That fixed it as usual".

This remains an unsupported local workaround and may be overwritten by future extension updates.

Stache73 · 18 days ago

Another confirmed recurrence on Windows after the VS Code Codex extension updated.

Affected extension build folder:

openai.chatgpt-26.623.101652-win32-x64

Installed bundle path:

C:\Users\arvid\.vscode\extensions\openai.chatgpt-26.623.101652-win32-x64\out\extension.js

Local workaround applied:

Replaced exactly one occurrence of:

{path:t.fsPath,conversationId:s}

with:

{path:n,conversationId:s}

Marker counts:

Before patch: broken marker 1, fixed marker 0
After patch: broken marker 0, fixed marker 1

Backup created:

C:\Users\arvid\.vscode\extensions\openai.chatgpt-26.623.101652-win32-x64\out\extension.js.bak-20260703-040411

Verification:

node --check passed.
After reloading VS Code, Arvid confirmed: "That fixed it as usual."

This appears to be the same recurring Windows central/main-panel missing chat input issue.

amato-gianluca · 6 days ago

Just to clarify that the problem also occurs on Linux.

VSCode version: code-1.128.0-1783465449.el8.x86_64
Codex plugin: openai.chatgpt-26.707.71524-linux-x64

The same workaround cited above works.

g33kphr33k · 5 days ago

It's stopped working for me again on Linux:

Version: 1.128.1
Commit: 5264f2156cbcd7aea5fd004d29eaa10209155d66
Date: 2026-07-14T07:19:31-07:00
Electron: 42.5.0
ElectronBuildId: 14525058
Chromium: 148.0.7778.271
Node.js: 24.17.0
V8: 14.8.178.33-electron.0
OS: Linux x64 6.12.95+deb13-amd64

Extension: openai.chatgpt-26.707.71524-linux-x64

SamL-DE · 5 days ago

Same issue for me on linux.

extension: Version 26.707.71524

ive tried the above referenced fix but it did not work for me.
Replaced exactly one occurrence of:
{path:t.fsPath,conversationId:s}
with:
{path:n,conversationId:s}
ls

i downgraded to vs code 1.127.0 and updated to the "prerelease" codex extension and it worked. i checked the extensions.js and it is using the {path:t.fsPath,conversationId:s} and working.