VS Code extension: clicking native Chat Sessions item should open a Codex Agent panel and route to /local/<conversationId>
Summary
In the Codex VS Code extension, clicking a session from VS Code's native Chat Sessions / Agent Sessions UI should automatically open a Codex Agent panel and pass the selected session into it.
Expected behavior:
- User clicks an existing Codex session in the native VS Code sessions UI.
- A new Codex Agent editor panel opens.
- The panel loads the selected local conversation route:
/local/<conversationId>.
Current behavior observed:
- After VS Code window reload, clicking a session does not reliably open a new Codex Agent panel with the selected session.
- The Codex sidebar/webview session list can be patched to open a panel, but the native VS Code Chat Sessions path still depends on the
openai-codex:/local/<conversationId>custom editor resource flow.
Environment
- OS: Windows
- VS Code extension:
openai.chatgpt - Observed installed version:
26.5602.40724-win32-x64 - Extension package command:
chatgpt.newCodexPanel - Custom editor view type:
chatgpt.conversationEditor - Chat session type:
openai-codex
Existing implementation notes
The extension already returns native chat session items with a resource URI similar to:
function Tae(t) {
return ZR(`/local/${t}`)
}
function ZR(t) {
return vscode.Uri.file(t).with({
scheme: 'openai-codex',
authority: 'route',
})
}
toChatSessionItem(summary) {
const resource = Tae(summary.conversationId)
return {
id: String(summary.conversationId),
resource,
label,
timing,
}
}
The custom editor resolver also knows how to parse openai-codex:/local/<conversationId> and map it to a route:
async resolveCustomEditor(document, panel) {
const parsed = KR(document.uri)
const { conversationId } = parsed
// existing route intent:
initialRoute: conversationId == null
? parsed.path
: `/local/${conversationId}`
}
However, native Chat Sessions clicks still rely on opening the custom editor resource. In practice this can fail or not produce the desired Codex Agent panel UX after reload.
Local hotpatch that fixes the behavior
A minimal local patch was tested by bridging resolveCustomEditor() directly to the same panel creation path used for Codex Agent panels:
async resolveCustomEditor(document, panel) {
const parsed = KR(document.uri)
if (parsed == null) {
throw new Error(`Invalid Codex conversation URI: ${document.uri.toString()}`)
}
const { conversationId } = parsed
let preview = null
let modelProvider = null
if (conversationId != null) {
try {
const { summary } =
await this.conversationSummaryProvider.getConversationSummary(conversationId)
preview = summary.preview
modelProvider = summary.modelProvider
} catch (err) {
this.logger.error('Error fetching conversation summary', {
safe: { error: err },
sensitive: {},
})
}
const viewColumn =
panel.viewColumn ??
vscode.window.activeTextEditor?.viewColumn ??
vscode.ViewColumn.Active
await this.createEditorPanel({
initialRoute: `/local/${conversationId}`,
viewColumn,
preserveFocus: false,
title: lue(preview),
})
panel.dispose()
return
}
// keep existing non-conversation custom-editor behavior
}
This preserves the session id handoff and avoids opening a blank or wrong custom editor surface.
Requested product behavior
Please make native VS Code Chat Sessions / Agent Sessions clicks first-class:
- Clicking an existing Codex session should open a Codex Agent panel.
- The panel should receive the selected
conversationId. - The loaded route should be
/local/<conversationId>. - The behavior should survive VS Code reload.
- The behavior should not depend on users first opening the Codex sidebar.
Why this matters
The extension already exposes sessions through VS Code's native session UI, so users expect clicking a session there to restore that Codex conversation. Today the webview/sidebar route and the native Chat Sessions route can diverge.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗