Scope Codex chats to VS Code projects/workspaces

What feature would you like to see?

Summary

Currently, Codex chats in the VS Code extension are global. The Recent Tasks list shows chats created in other projects/workspaces, which makes it hard to keep Codex sessions organized.

Proposed behavior

Scope Codex chats to the active VS Code project/workspace. Ideally:

Each project has its own Recent Tasks history.
Optionally, provide a way to switch between “global history” and “per-project history.”

Use case

Example: I worked in project TradeAssist yesterday and had two Codex chats there. Today, when I switched to a different project M1, those same TradeAssist chats still appeared in Recent Tasks. This makes it difficult to separate Codex sessions by project.

Benefits

Clear separation of Codex sessions per project.
Reduced confusion when working across multiple repositories.
Easier context management when returning to a project after time away.

Environment

VS Code version: 1.103.2
Codex extension version: 0.4.6
OS: Xubuntu 20.04

Are you interested in implementing this feature?

No response

Additional information

No response

It's insane this isn't the default behavior, when you have a lot of projects, finding your place again on editor restart is very challenging

I think I'm slightly tripping... this was the case for me; for every project I had separate history of chats in Codex. Until literally yesterday where suddenly every chat appears on every project of mine and I learned (learn?) that it's default behaviour?

Is there any movement on this? There is little to no benefit to having conversations unrelated to the current project showing up and sorting though them (while not being able to name conversations) is quite annoying.

Is there any movement on this? There is little to no benefit to having conversations unrelated to the current project showing up and sorting though them (while not being able to name conversations) is quite annoying.

While you can't name conversations, my make-do solution has has been prepending to the the first prompt message the uppercase repo name and ending it with a dot so that you can easily filter through the list, either at a quick glance from the last shown or via the search feature through "View all"/"Task History".

It shouldn't really be a hindrance to the quality of the response, I reckon, and that plus enough thread archiving makes it bearable for me.

@Nesquik

@Nesquik ah that's a good workaround for now yep. Thanks

@Nesquik

Yeah I also felt the need for this. BTW, I would usually try to write something like "This chat is about backend", thinking it would make the chat name "Backend Chats" or something like it happens in chatgpt ui. It's just pretext I guess like @Nesquik uses. That helped! Good workaround.

Is there any movement on this? There is little to no benefit to having conversations unrelated to the current project showing up and sorting though them (while not being able to name conversations) is quite annoying.

While you can't name conversations, my make-do solution has has been prepending to the the first prompt message the uppercase repo name and ending it with a dot so that you can easily filter through the list, either at a quick glance from the last shown or via the search feature through "View all"/"Task History".

It shouldn't really be a hindrance to the quality of the response, I reckon, and that plus enough thread archiving makes it bearable for me.

Thanks, I´ve started doing the same, it helps.

Noticed that in the latest version, the Chat window is blocked if you´re in the wrong project (which kind of baffles me to put that effort in but still just show all chats)

FYI, in terms of competitor analysis: Antigravity does this; every agent window is scoped to the project.

My project has several repos. In the morning, when I open a particular VSCode workspace, how am I supposed to know which task to reopen? I am guessing Openai would rather we use the Codex app where this is how it works.

FYI, in terms of competitor analysis: Antigravity does this; every agent window is scoped to the project.

As does Claude Code (VSCode Extension)

This is the 1st emergency task of OpenAI, any update on this? All chats are mixed up, it's not usable

I packaged my earlier workaround as a small VS Code Marketplace extension.

It’s still only a workaround; native per-workspace history in Codex would definitely be better. Suggestions are welcome.

I made something out of frustration for this :-) https://github.com/OpenJeDi/codex-control
I just use VS Code for the code now.

^ this is the 3rd workaround solution posted in this thread lol

lol, here's the fourth workaround 😄

Workarounds so far

0. Prompt-prefix naming

Prepending REPO_NAME. to the first prompt is clever because it works immediately. But it is still manual.

1. `codex-session-indexer`

This correctly uses the fact that Codex sessions already record cwd, and it gives a useful per-project index.

But it is an external index. It does not fix the built-in VS Code Recent Tasks UI.

2. `CODEX_HOME` splitting

This was my workaround. It gives real separation by starting Codex with a workspace-specific CODEX_HOME.

The root problem is that it splits CODEX_HOME: VS Code separation works, but codex CLI usage becomes awkward because every terminal needs the matching CODEX_HOME, and old sessions remain under ~/.codex/workspaces. It also used vscode.workspace.name as the split key, which is not reliable: duplicate names, renamed workspaces, Remote-SSH suffixes like [SSH: ...], and multi-root workspaces all make it messy.

3. `codex-control`

This avoids the VS Code UI problem by using a separate control surface.

The simpler native path

Codex sessions already have to be tied to a cwd. The local thread store rejects thread creation without one, and the VS Code extension already sends cwd when starting sessions.

The missing half is listing: thread/list already accepts a cwd filter, but the VS Code extension does not pass it.

cwd?: string | Array<string> | null

The Rust protocol models it as One(String) / Many(Vec<String>), with a test for multiple cwd values. That maps nicely to VS Code workspaces, which can have multiple folders.

So the fix is not new storage or a new index. It is: use the cwd that sessions already have, and pass the VS Code workspace folder list as the thread/list cwd filter.

Suggested patch

There are three thread/list paths in the VS Code extension that should get the same non-empty M0() cwd filter.

1. Main Codex Recent Tasks UI

The Recent Tasks request passes through the extension’s mcp-request bridge:

case"mcp-request":{let{id:n,method:o,params:i}=r.request;this.pendingMcpRequests.set(String(n),e),this.codexMcpConnection.sendRequest(k0,String(n),o,i);break}

That bridge can inject the existing VS Code workspace roots from M0():

case"mcp-request":{let{id:n,method:o,params:i}=r.request;
if(o==="thread/list"&&i&&i.cwd==null){let s=M0();s.length>0&&(i={...i,cwd:s})}
this.pendingMcpRequests.set(String(n),e),this.codexMcpConnection.sendRequest(k0,String(n),o,i);break}

2. Native VS Code ChatSession provider

There is also a direct thread/list call:

return this.codexAppServer.sendRequest(J7,r,"thread/list",{limit:50,cursor:null,sortKey:"created_at",modelProviders:e?[nb]:null,archived:!1,sourceKinds:im}),n

Patch shape:

let s=M0(),a={limit:50,cursor:null,sortKey:"created_at",modelProviders:e?[nb]:null,archived:!1,sourceKinds:im};
return s.length>0&&(a={...a,cwd:s}),this.codexAppServer.sendRequest(J7,r,"thread/list",a),n

3. ConversationPreviewLoader

And another direct thread/list call:

let o={limit:e,cursor:null,sortKey:"created_at",modelProviders:[],archived:!1,sourceKinds:im};
return this.codexMcpConnection.sendRequest(uee,r,"thread/list",o),n

Patch shape:

let o={limit:e,cursor:null,sortKey:"created_at",modelProviders:[],archived:!1,sourceKinds:im},s=M0();
return s.length>0&&(o={...o,cwd:s}),this.codexMcpConnection.sendRequest(uee,r,"thread/list",o),n

With just these three small injections, the extension gets:

Workspace open: show sessions for that workspace folder or folders.
No workspace open: keep showing the normal global ~/.codex history.
No storage split.
No session migration.
No CLI CODEX_HOME mismatch.

The s.length > 0 guard preserves the no-workspace case: an empty cwd array means “match nothing”, so do not inject it.

I also packaged these three insertions as a small VS Code extension so the patch is reapplied after the Codex extension updates and overwrites out/extension.js, and deprecated the old CODEX_HOME splitting extension.

Thanks for reporting. This has already been reported by others. Please search for the feature request and upvote it.

I am experiencing the same issue in the current VS Code Codex extension.

Every VS Code project shows the same 51 conversations. This is not caused by
opening a parent directory or the wrong workspace: I open each repository in
its own pinned VS Code window.

I inspected the local Codex state database:

93 total threads
20 distinct cwd values
only 4 threads belong to the currently opened repository
nevertheless, the extension displays the same 51 conversations in every repository

This confirms that workspace detection and per-thread cwd metadata are
correct, but the VS Code conversation list is not filtering by the active
workspace. The usability problem becomes progressively worse as global
conversation history accumulates.

In-product feedback IDs:

019f6010-c0fc-7031-97b6-d2f6e7c40fd4
019f6e18-144a-7672-9309-a6612fa03193

VS Code Codex extension version: 26.609.30741
Platform: Windows + WSL

Project wise session isolation and other features are nicely implemented in Claude Code VS Extension.
Codex extension looks very primitive when you switch from Claude Code to Codex extension.
Since GPT 5.6 Ultra is bringing back users to Codex from Opus, its the time to upgrade Codex extension with these well deserved feature.

Yeep, it would be great to have this. This is one thing I miss from Copilot (also the way Copilot was showing the agent modifications, but that is another discussion).

Even skills are global to all projects/workspaces, and sometimes, if a project/workspace name looks similar to another where I've specifically created a skill for, upon starting a new conversation, GPT tries to use that skill first, and I have to tell it we are not in that project for which the skill is made.

It's insane that even after almost a year this extremely important feature hasn't been implemented yet. Just make it workspace-based and it would be so much greater to use the VSCode extension. It's time. Don't give this request a chance to celebrate a "still not implemented"-anniversary next month 💀

Can someone from the team explain why this hasn't happened yet? I gave up on this extension ages ago now but I'm confused as to why the devs have also lol

At this point I'm just thinking that they want to push us to the Codex app. It is ridiculous.

Per-project scoping was added to the IDE Extension many months ago, and this issue was closed at that time. If you would like to see a different behavior in the IDE Extension, please comment on an active feature request or open a new one. I'm going to lock this issue since it's closed.

Navigation Menu

Repository navigation

Scope Codex chats to VS Code projects/workspaces #3550

What feature would you like to see?

Are you interested in implementing this feature?

Additional information

12 remaining items

Workarounds so far

0. Prompt-prefix naming

1. `codex-session-indexer`

2. `CODEX_HOME` splitting

3. `codex-control`

The simpler native path

Suggested patch

1. Main Codex Recent Tasks UI

2. Native VS Code ChatSession provider

3. ConversationPreviewLoader

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Scope Codex chats to VS Code projects/workspaces #3550

Description

What feature would you like to see?

Are you interested in implementing this feature?

Additional information

Activity

pbarker commented on Oct 12, 2025

pherkan commented on Dec 18, 2025

thomasf1 commented on Jan 5, 2026

Nesquik commented on Jan 5, 2026

pherkan commented on Jan 5, 2026

iarc13 commented on Jan 10, 2026

thomasf1 commented on Jan 10, 2026

dank-ubiq commented on Feb 2, 2026

paddywills commented on Feb 17, 2026

gmmurray commented on Feb 17, 2026

12 remaining items

Antera commented on May 8, 2026

xsjk commented on May 10, 2026

OpenJeDi commented on May 10, 2026

stephenjoly commented on May 10, 2026

xsjk commented on May 13, 2026

Workarounds so far

0. Prompt-prefix naming

1. codex-session-indexer

2. CODEX_HOME splitting

3. codex-control

The simpler native path

Suggested patch

1. Main Codex Recent Tasks UI

2. Native VS Code ChatSession provider

3. ConversationPreviewLoader

etraut-openai commented on May 13, 2026

lpbjdfx commented on Jul 17, 2026

tejasvih commented on Jul 17, 2026

AlexSoare commented on Aug 2, 2026

kmeierr commented on Aug 15, 2026

maxiedaniels commented on Aug 15, 2026

AlexSoare commented on Aug 15, 2026

etraut-openai commented on Aug 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

1. `codex-session-indexer`

2. `CODEX_HOME` splitting

3. `codex-control`