VSCode Plugin bug: Could not open multiple windows via `Codex: New Codex Agent`

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

• #15552
• #15397
• #14812

Powered by Codex Action

I checked the repo and found some similar community reports.

The closest one is #15552. It reports that after version 26.5318.11754, Codex: New Codex Agent could only open 1 window, which is very close to what I am seeing here.

Also looks related:

• #11727: Codex: New Codex Agent failed with Failed to resume task
• #13182: new Codex conversation creation failed
• #13684: failed to create a new thread / conversation
• #14179: existing chat worked, but creating a new local conversation failed with Conversation not found / no rollout found

For the side symptoms in this issue:

• #14812 may be related to the history / thread state problem
• #15397, #14917, and #13343 may be related to abnormal CPU / extension state behavior

So from my side, this may not be an isolated bug. It looks more like the same extension regression family around New Codex Agent, conversation creation, and thread/history state management.

Leaving these issue links here for triage.

Yes, I also found this problem

This is open since March without any attention? I can have only one Codex agent open at a time, that's a big hit on productivity. I guess it's affecting only a small subset of users, otherwise it would have been fixed for sure.

I dug into the shipped VS Code extension bundle on macOS and this looks like an extension implementation issue rather than a keybinding/config issue.

Environment I checked:

• VS Code extension: openai.chatgpt 26.513.21555
• VS Code user keybinding bound cmd+n to chatgpt.newCodexPanel when a Codex custom editor is focused

What I found in the installed extension:

• The docs say chatgpt.newCodexPanel is “Create a new Codex panel”: https://developers.openai.com/codex/ide/commands
• The extension registers the custom editor with supportsMultipleEditorsPerDocument: false
• createNewPanel() always opens the same custom-editor URI: __('/extension/panel/new')
• Conversation/history tabs are separate because their URIs include /local/:conversationId (or /remote/:taskId), while the “new panel” URI is effectively a singleton
• chatgpt.newChat is sidebar-oriented in this build: the command title is “New Thread in Codex Sidebar”, its menu contribution is restricted to sidebar webviews, and the runtime sends { type: 'new-chat' } to sidebarView.webview

Relevant bundled-code snippets from the installed extension:

1. Custom editor registration disables multi-editor docs:

registerCustomEditorProvider(wl.customEditorViewType, tt, {
  webviewOptions: { retainContextWhenHidden: !0 },
  supportsMultipleEditorsPerDocument: !1
})

1. New Codex Agent always opens the same URI:

async createNewPanel() {
  let e = __("/extension/panel/new"),
      r = Ie.window.activeTextEditor?.viewColumn ?? Ie.ViewColumn.Active;
  await Ie.commands.executeCommand("vscode.openWith", e, t.customEditorViewType, {
    viewColumn: r,
    preserveFocus: !1,
    preview: !1
  })
}

1. URI parsing only treats local/remote conversation routes as unique conversations:

function S_(t) {
  let { scheme: e, authority: r, path: n } = t;
  if (e !== Bu) return null;
  if (r !== Mee) return null;
  let i = (n.startsWith("/") ? n.slice(1) : n).split("/"), s = null;
  return i.length >= 2 && (i[0] === "local" || i[0] === "remote") && (s = i[1]),
    { path: t.fsPath, conversationId: s };
}

1. newChat targets the sidebar webview:

triggerNewChatViaWebview() {
  this.sidebarView && this.sidebarWebviewReady &&
    this.postMessageToWebview(this.sidebarView.webview, { type: "new-chat" })
}

This matches the user-visible behavior exactly:

1. Cmd+Shift+P -> Codex: New Codex Agent or cmd+n on a Codex tab does not create another fresh tab; it reuses/focuses the existing /extension/panel/new tab.
2. Historical chats can open in separate tabs because they have distinct conversation URIs.
3. Clicking New chat from a task tab routes back toward the singleton “new” panel/sidebar flow instead of spawning another independent tab.

Likely fixes:

• Give each new panel a unique URI (for example the same route plus a unique query/hash/token), and/or
• Register the custom editor with supportsMultipleEditorsPerDocument: true

Right now the docs wording and the shipped extension behavior do not line up for users expecting multiple Codex tabs/panels in VS Code.

I appear to be seeing the same user-visible behaviour with a newer VS Code extension on Windows using a Remote SSH extension host:

• VS Code extension: openai.chatgpt 26.721.41059
• Codex: New Codex Agent opens or focuses the singleton new-agent editor.
• Running the command again does not create another independent fresh editor.

Separately, we built a small local-only VS Code bridge for a Markdown session catalogue. Unlike approaches that patch the installed Codex extension, this helper leaves the official extension unchanged and asks VS Code to open the observed local-conversation resource for a supplied session ID. It worked in our environment, including opening several different established sessions as editor tabs.

This does not establish that the observed resource is intended for third-party use. It may suggest that a small public open existing session command could support catalogue and task-tracker integrations without relying on the observed private resource. The narrower API request was submitted as https://github.com/openai/codex/issues/35694.

There is a built-in workaround for opening multiple existing Codex sessions, without patching the extension:

1. Open VS Code's built-in Chat / Agent Chat view.
2. Open the Sessions list (or Session History).
3. Select an existing Codex session.
4. Repeat with other sessions. They open as separate editor tabs and can coexist.

This matches the implementation detail noted above: established conversations have distinct conversation IDs, so VS Code can open them as separate editor resources.

Important limitation: this does not fix the reported bug in Codex: New Codex Agent. That command still reuses/focuses the singleton new-agent panel instead of creating multiple fresh panels. It is only a practical workaround for established sessions.

A similar workaround with screenshots was also documented in #20951: https://github.com/openai/codex/issues/20951#issuecomment-4517980706

Still reproducible in the current stable extension:

• Extension: openai.chatgpt 26.803.41515
• IDE: VS Code 1.132.0
• Platform: macOS
• The toolbar New Chat control does nothing.
• Running Codex: New Codex Agent again only focuses the existing Codex session; it does not create a new independent conversation/tab.

I also checked the installed extension bundle and can confirm the implementation described above is still present: the custom editor is registered with supportsMultipleEditorsPerDocument: false, and createNewPanel() opens the same /extension/panel/new URI each time. That makes the panel behave as a singleton.

The required workflow is multiple independently switchable Codex sessions, each with separate conversation context, inside one VS Code workspace/window. Using separate CLI terminals provides context isolation, but loses the panel's native inline-diff/review UX.

Still reproducible in the current VS Code extension, with a more precise description of the tab/session behavior below.

Scope

This concerns Codex opened as VS Code editor tabs, not the Codex sidebar.

Environment

• OS: Windows 11 x64 (build 26200)
• VS Code: 1.134.0
• Codex IDE extension: openai.chatgpt 26.820.60940

Reproduction and actual behavior

1. Open Codex: New Codex Agent. This creates the initial "new session" editor tab.
2. Start a session in that tab.
3. Select another session from History. Codex opens that session in a separate editor tab.
4. Click New Session in the original tab: nothing happens.
5. Click New Session in another session tab: VS Code only focuses the original tab; no new session is created.
6. Close the original tab, then click New Session from another session tab: only now can a new session be opened.
7. Selecting sessions from History always opens another editor tab rather than navigating the current tab.

Primary expected behavior

The initial tab may begin as a temporary "new session" placeholder. Once a session is started successfully, that tab should become bound to the created session and be treated as that session's normal editor tab.

After that conversion, invoking New Session should create or open a fresh placeholder tab for the next session. It should not keep routing every later New Session action to the original, already-used tab.

Opening History sessions in separate tabs may be an intentional UX choice or preference. The primary defect is that the original placeholder never stops being treated as the singleton "new session" target, which blocks later session creation.

Implementation observation

Local inspection of the shipped bundle shows that createNewPanel() always opens the same /extension/panel/new custom-editor URI, while the provider is registered with supportsMultipleEditorsPerDocument: false. This is consistent with VS Code repeatedly focusing the stale singleton placeholder instead of creating a usable new-session tab.

No project files, credentials, or private logs are included.