codex - 💡(How to fix) Fix VS Code Codex: central editor panel opens blank on Windows because custom URI route uses fsPath

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.