Codex sessions are shown in Copilot chat for every folder and as unread

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

• #13951

Powered by Codex Action

Is this a duplicate, or at least related to #3550?

@etraut-openai, can you please look into this, and ideally triage? This bug is super annoying, and spams all other Copilot chats for me in VS Code...

I am willing to help with debugging, ...!

I did a closer pass on this (with agentic AI, so take this with a grain of salt) from both the public issues and the open-source openai/codex repo, and I think this is partly a Codex-side source-classification bug and partly a VS Code/Copilot UI bug.

What I found on the Codex side:

• In the current openai/codex repo, codex app-server is wired with session_source: SessionSource::VSCode in codex-rs/app-server/src/lib.rs.
• Codex also defines “interactive sessions” as cli + vscode in codex-rs/core/src/rollout/mod.rs.
• The app-server docs say thread/list defaults to those interactive sources (cli, vscode) unless sourceKinds is specified, in codex-rs/app-server/README.md.
• There is also a related report in #13951 that app sessions can be mislabeled as vscode.

That suggests a plausible root cause here: if the Windows Codex app is using the same app-server path, app-created sessions may be persisted as source: "vscode" (or otherwise treated as VS Code sessions), which would make them show up in the VS Code extension/Copilot session feed.

Separately, the “for every folder” / “always unread again” behavior still looks like a VS Code-side issue (see microsoft/vscode#300191), because VS Code appears to be handling visibility and unread state in a way that is not scoped well for these external sessions.

So my current split is:

• Codex bug: app-originated sessions seem to be classified/surfaced as VS Code sessions.
• VS Code bug: once surfaced, they are shown globally and keep reappearing as unread across folders/workspaces.

Possible Codex-side fix directions:

• Don’t hardcode SessionSource::VSCode for all app-server-backed clients.
• Let the client specify its session source explicitly, or introduce a distinct desktop/app source.
• Avoid feeding desktop-app sessions into the VS Code extension history unless the user explicitly opted into shared history.

@etraut-openai, given that the issue is open now for about two weeks without a response, can you please look into this?

This is severely degrading usability of the chat history in VS Code.

Thank you for your work, making agentic coding better every day!

@etraut-openai another ping, as another week has passed.

Hi @etraut-openai, following up on this because the last repo-side action I can see here was the initial March 10 bot triage, and the related upstream VS Code issue clarified on April 2 that the cross-project and global session behavior likely needs a Codex-side fix. Is there an owner or next step for this on the Codex side? Thank you for improving the product every day.

Just a short info, as there is no reaction from anybody responsible, so far: A workaround is to uninstall/disable the Codex VS Code extension. Then, the Codex chats don't mess up the overall history, anymore (also previous ones disappear from there, so everything is clean again). Might not be a solution for everybody, but for me, it was really worth it!

Hi @etraut-openai, looping in @ambrosino-oai as well because this has stayed quiet despite multiple earlier pings, and it seems related to Codex app/session classification and history behavior. The last Codex-side handling action I can see is still the March 10 bot triage, while the related VS Code thread pointed the global-session behavior back to Codex. I have disabled the Codex extension as a workaround because the session history becomes unusable. Could one of you assign or route this to the right owner? Thank you for improving the Codex/VS Code experience.