Scope Codex VS Code chats to the current workspace/project

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

• #24083
• #25252
• #23942

Powered by Codex Action

I agree this is a natural fit for the next step after adding the capability to rename threads.

One important thing though, that if filtration of threads by working directory is added to VS Code extension, there also should be a way to "Show All". Because, for instance, if you move or copy a project to a different directory, there should be a way to resume the old thread about this project in the new location as well.

This has my vote. When I'm working on an Arduino project, I don't need to see web development threads.

That would be so nice, especially for linux users that still don't have the app :)

This is very important for those working across multiple projects.

I want to add a more severe real-world impact case here.

This is not just a history/navigation issue. In my setup, Codex chat sessions appeared to leak across multiple VS Code windows and repositories, and this resulted in unintended changes being applied across multiple repos.

Environment:

• OS: macOS 26.5, arm64
• VS Code: 1.123.0
• Codex IDE extension: openai.chatgpt@26.602.40724
• Variant: Codex IDE Extension in VS Code
• Mode: local Codex agent session in VS Code. I do not have a reliable record anymore of whether this was normal Agent mode or Agent Full Access.

Setup:

• VS Code window A: a multi-root workspace with two repositories.
• VS Code window B: another VS Code window with other repositories open, because I was working on a cross-repo task.
• Codex IDE extension was used in these windows.
• I suddenly saw the same Codex chat sessions in both VS Code windows.
• Later I discovered that Dependabot-related changes that were supposed to happen only in one target repository had also been applied in multiple unrelated local repositories.

Current local evidence, redacted:

• Multiple unrelated repositories currently have unexpected untracked .github/dependabot.yml files.
• The file modification timestamps are all within the same short time window, roughly under one minute.
• Example current git status pattern across affected repos:

repo A:
?? .github/dependabot.yml

repo B:
?? .github/dependabot.yml

repo C:
?? .github/

repo D:
?? .github/

repo E:
?? .github/

Impact:

• The extension did not give me a clear per-workspace/project boundary.
• Chats from unrelated repositories were visible together in multiple VS Code windows.
• Codex threads carry repository-specific context, but the UI did not protect against using that context in the wrong workspace.
• This caused real unintended file changes across multiple repositories, not just confusing suggestions.
• The operation looked like it was scoped to one target repo, but changes appeared in multiple repos.

In my view this should be treated as a bug / safety issue, not only an enhancement request. Other coding assistants such as Claude and GitHub Copilot handle multi-window / multi-repo project separation in a way that does not expose the same kind of cross-repo session confusion.

Expected behavior:

• Threads must be scoped to their originating VS Code workspace folder / working directory by default.
• In a VS Code window for Project A, sessions from Projects B/C/D should be hidden or clearly separated.
• If a user tries to resume a thread from a different workspace, the extension should warn or block by default.
• Multi-root workspaces should show explicit root ownership for each thread.
• Codex should never silently apply changes to repositories outside the intended active workspace/root.
• If the extension cannot safely determine the active workspace/root, it should fall back to read-only or ask for explicit confirmation before editing.

Related issues:

• #25319
• #2909
• #18963
• #11794
• #3550

I think #25319 should be separated from full multi-root workspace support in #2909.

Multi-root is hard because VS Code can have many workspace folders in one window, while a Codex core session still has one effective cwd. That is a real model mismatch, and fixing it properly probably belongs in #2909.

But the common single-root VS Code workspace case is much simpler. Codex already records cwd for each session, and thread/list.cwd already supports filtering by cwd.

So the VS Code extension can fix the main #25319 problem by passing the current workspace folder / effective cwd into its thread/list requests. When no workspace folder is open, it can keep showing the global history; multi-root can keep today's effective behavior for now and leave true multi-root semantics to #2909.

Until there is an official fix, Codex Workspace Filter can be used as a small workaround.

I am curious about why this feature is not supported until now. When open codex in vscode, it is hard to find the thread I want from hundred of my chats.

Because #17185 didn't get enough interest from the community.
Please upvote this one.

+1. I strongly support this request.

I use the Codex VS Code extension across multiple repositories and VS Code windows every day, and the current global mixed history makes the extension much harder to use than it should be.

The main issue is that Codex threads are project-specific by nature. A thread usually contains assumptions about a particular repository, file structure, build system, dependencies, and task context. When threads from unrelated projects all appear in one shared history list, it becomes very easy to reopen or continue the wrong conversation.

This is not just a small navigation inconvenience. It creates real workflow risk:

• It is hard to find the correct thread when many projects have similar task titles.
• It is easy to resume a thread that belongs to a different repository.
• The user has to manually remember which conversation belongs to which workspace.
• Project-specific context can be confused across unrelated codebases.
• In multi-window or multi-repo workflows, the history list becomes noisy very quickly.

The CLI already appears to have a better mental model here by scoping resume behavior around the working directory, with an option to show all sessions. The VS Code extension should follow a similar model.

A good MVP would be:

• Show current-workspace threads by default.
• Clearly display the workspace/project name for each thread.
• Provide an optional “All threads” view for users who want global history.
• Warn or make it explicit when reopening a thread from a different workspace.
• Support multi-root workspaces by showing which root a thread belongs to.

This would make the extension much safer and easier to use for people who work across multiple active projects. Right now, the lack of project/workspace separation is one of the biggest sources of friction in the VS Code extension.

For anyone affected by this before an upstream fix lands, I published a small experimental workaround:

https://github.com/Efs-O/codex-sessions-workspace-patch-kit

Current pre-release:

https://github.com/Efs-O/codex-sessions-workspace-patch-kit/releases/tag/v0.4.0

It patches the shipped openai.chatgpt VS Code extension bundle locally so Codex session history is filtered to the active VS Code workspace roots. It also widens thread/list requests before filtering, so older matching workspace sessions are less likely to be hidden behind newer sessions from unrelated workspaces.

Compatibility note: this has been tested locally against openai.chatgpt 26.616.x extension bundles. It is a pre-release workaround, not an upstream source patch. Because it patches minified shipped extension code, a new Codex/VS Code extension version can overwrite the patch or change the anchors so the patch no longer applies.

Please run the dry-run flow before applying:

npm run scan
npm run apply:dry
npm run apply

To undo it:

npm run restore

Feedback would be very helpful, especially reports about version drift, missing anchors, and workspace-history edge cases.

This is soo usefull! thanks. I just tested a few moments and works like a charm, but I have a question, this fix will only separated just at visual level or will separate at logical level, like you know, codex will not mix context or will do?

<img width="1343" height="298" alt="Image" src="https://github.com/user-attachments/assets/52add731-77e0-4696-bcff-f5c6e2b642cc" />

Thanks for testing it.

This workaround is primarily a history/sidebar filter, not a full logical isolation fix.

What it does:

• filters thread/list results in the VS Code extension host so the visible history only shows sessions whose saved cwd belongs to the current VS Code workspace roots
• widens the thread/list request before filtering so older matching workspace sessions are less likely to be hidden behind newer sessions from other workspaces

What it does not fully solve:

• it does not change Codex core session ownership semantics
• it does not guarantee restore-time blocking if a foreign thread is already active or manually resumed
• it does not provide a complete multi-root workspace model
• it does not enforce tool/file access boundaries by itself

So yes: it should reduce accidental cross-project history selection, but it should be treated as a UI/history workaround, not a complete logical sandbox. The proper upstream fix should scope both history and resume/restore behavior to the workspace, with an explicit "show all / resume from another workspace" flow.

This feature is so needed asap.

Additional concrete reproduction: active IDE workspace and thread cwd can silently diverge

I encountered a concrete instance of the risk described in this issue. This report is intentionally sanitized: repository names, usernames, absolute paths, remotes, commit hashes, prompts, and organization details have been replaced or omitted.

Environment

• Codex IDE extension: openai.chatgpt 26.715.31925
• IDE: VS Code 1.128.1
• Platform: Linux x86_64
• Two unrelated Git repositories, referred to below as Repository A and Repository B
• Each repository has its own remote, history, target files, and AGENTS.md

Observed behavior

The IDE context showed a file from Repository B, and the user supplied a task whose baseline commit, target files, and branch invariants all belonged to Repository B. However, the active Codex thread had retained Repository A as its recorded cwd and writable workspace root. The agent therefore received and followed Repository A's project instructions.

The mismatch was not apparent from the visible editor tab or the task context. It became visible only because the agent ran defensive preflight checks:

pwd                         -> <redacted>/repository-a
git rev-parse --show-toplevel -> <redacted>/repository-a
git remote -v               -> repository-a remote

The requested files and baseline commit did not exist in Repository A. A separate read-only check then confirmed that Repository B contained the expected files, branch, remote, and baseline.

No wrong-repository write occurred because the agent stopped on the baseline mismatch. Without those checks, a plausible outcome would have been creating similarly named files, committing them, or pushing a branch in the wrong repository.

Why this matters

This is more than chat-list clutter. It is a repository-boundary and instruction-boundary risk:

• A resumed thread can retain a stale cwd and writable root from another repository.
• The current editor tab and user-provided IDE context can simultaneously point to the intended repository.
• Repository-specific AGENTS.md instructions are then loaded from the stale thread workspace.
• The agent may have valid write and Git permissions in the unintended repository.
• The user may reasonably assume that the Codex panel follows the current VS Code workspace.

This appears related to #25319 (workspace-scoped thread history) and #11757 (stale cross-workspace project instructions), but this case specifically demonstrates a silent divergence between the active IDE context and the thread's executable/writable workspace.

Reproduction outline

1. Open Repository A in VS Code and create a Codex thread.
2. Open or switch to Repository B in the IDE, where Repository B has a distinct AGENTS.md and Git remote.
3. Resume or continue the Repository A thread while the visible IDE context is Repository B.
4. Provide a task that clearly references files and a commit that exist only in Repository B.
5. Observe that the thread still executes with Repository A as cwd, uses Repository A's project guidance, and has Repository A as its writable root.
6. Note that the mismatch may remain silent unless the agent explicitly runs pwd, git rev-parse --show-toplevel, and git remote -v.

I cannot yet determine whether the triggering action was thread restoration, panel/window restoration, or selection from the global thread list. Please consider checking all three paths.

Expected behavior

At minimum, the extension should make the distinction explicit and prevent silent cross-repository execution. Possible safeguards:

1. Scope or prioritize thread history by the active VS Code workspace, as proposed in this issue.
2. Display the thread's recorded repository root prominently near the composer, not only in hidden session metadata.
3. When the active IDE workspace and thread cwd differ, show a blocking confirmation before sending or executing a task.
4. Offer an explicit action to start a new thread in the active workspace or deliberately continue in the original workspace.
5. Recompute and visibly identify project-instruction sources whenever a thread's workspace changes; enforce that AGENTS.md sources belong to the selected workspace chain.
6. Consider a pre-execution invariant that compares the active VS Code workspace, session cwd, writable sandbox roots, and Git root. A mismatch should fail closed or require confirmation.

Current workaround

Users can reduce the risk by opening the intended repository as the VS Code folder, reloading the window, creating a new Codex thread, and manually checking pwd, the Git root, and the remote before allowing writes. This is useful defensively, but it should not be required for every resumed IDE thread.

I did not attach raw session logs because they can contain private prompts, local paths, repository names, remotes, and configuration details. I can provide additional sanitized diagnostics if maintainers identify the specific extension/app-server fields needed.

Please also include per-workspace active-thread restoration, not only filtering/grouping the history list.

Concrete workflow:

1. Open Workspace A in VS Code and work in Codex Thread A.
2. Save/close the VS Code workspace or window.
3. Reopen the same workspace later.
4. Codex shows the global mixed thread list and does not automatically reopen Thread A.
5. The user must repeatedly search for and select the matching thread manually.

Expected behavior:

• Persist a mapping such as workspace identity -> last active Codex thread.
• When that workspace is reopened, automatically restore its last active thread and conversation position.
• Show current-workspace threads by default; keep an explicit All threads view.
• If the saved thread no longer exists, fall back to the current-workspace thread list rather than the global list.
• For a multi-root workspace, bind to the stable .code-workspace identity plus its roots.
• Never silently restore a thread whose recorded cwd belongs to another workspace.

This is distinct from transcript persistence: the conversations are still present, but the extension does not remember which one was active for each workspace. Claude Code's VS Code workflow already behaves as users expect here: reopening a saved workspace returns directly to the last conversation for that workspace.

I strongly support this feature request.

Project-based conversation filtering is already available in the Claude Code extension, and there is also a third-party extension in the Visual Studio Marketplace called Codex History Viewer that adds similar functionality to Codex. That extension has around 5,000 downloads, which demonstrates clear user demand for this behavior.

Codex already stores the working directory associated with each session, and the CLI already uses that information to filter sessions when running codex resume. It therefore seems reasonable for the VS Code extension to reuse the same metadata.

Ideally, the extension should show only conversations associated with the current workspace by default, while still providing an “All workspaces” option. This would reduce clutter, prevent users from reopening sessions from the wrong project, and make the extension much easier to use across multiple repositories.

Our additional experiment was a read-only catalogue that assigns several dozen sessions to logical projects, then optionally adds a subject, tags, and a lifecycle label. In our setup, that was useful in cases where:

• several logical projects may share one scripts/monorepo workspace;
• one conceptual project may span several repositories or working folders;
• general or planning chats may not begin in their eventual project folder;

That may be outside the intended scope of this issue, but it suggests a possible later layer above workspace filtering: optional logical collections or labels that are not required to match one filesystem path.

The catalogue also displayed counts and latest activity per logical project, which made older sessions easier for us to revisit. I cannot tell from the public interfaces whether comparable metadata is already planned or available elsewhere.

Our prototype currently keeps this classification in a separate TOML file. It would be useful if any future native metadata were readable through a supported interface, but the workspace-filtering request here would still be valuable without the additional taxonomy.

I want to add a strong +1 from the perspective of VS Code .code-workspace users and paid Codex/GPT plan users.

This issue is not new. There is already a long history of related reports and duplicates around the same core problem: Codex chat history in the VS Code extension is effectively global, while real developer work is project/workspace-scoped.

Related issues include at least:

• #3550
• #5386
• #17185
• #4071
• #9087
• #9737
• this issue, #25319

The problem described in #17185 is especially important: this is not just a UI preference or cosmetic organization request. When users work on Project A, switch to Project B, and accidentally continue a thread from Project A, Codex uses the wrong prior context and can produce incorrect or confusing results. That is a correctness problem.

This issue, #25319, also describes the same risk clearly: chats from different projects appear together in one shared list, making it easy to resume the wrong thread or confuse which chat belongs to which project. Codex threads carry project-specific assumptions, file references, decisions, and previous tool context. Even if Codex does not automatically inject context from other workspaces, the current UI creates a practical context-leak hazard: a user can accidentally bring the wrong project context into the current workspace simply by resuming the wrong visible thread.

For VS Code .code-workspace users, this is especially problematic. In my workflow, each real project usually has its own .code-workspace file. That workspace contains everything needed for the project and is the practical project boundary. Sometimes it is a single-folder workspace, and sometimes it is a multi-root workspace with several related folders opened together. In both cases, when I open a specific .code-workspace, I expect Codex to show and prioritize chats belonging to that workspace, not chats from unrelated projects opened earlier.

The current behavior breaks the basic mental model:

• open Project A .code-workspace
• create several Codex chats for Project A topics
• open Project B .code-workspace
• Codex still shows Project A chats in the same list
• user can accidentally resume the wrong thread
• Codex now continues with stale/wrong project assumptions

That is not acceptable for an IDE-integrated coding assistant.

This also has a paid-product impact. Many of us are paying for GPT/Codex-capable plans specifically to use Codex as a serious development tool. Project isolation is a basic expectation in an IDE workflow. Paid users should not need to manually encode project names into every first prompt, rename every thread defensively, archive aggressively, or visually inspect a global mixed history list just to avoid using the wrong project context.

Thread renaming helps, but it is only a workaround. It does not solve the underlying problem.

A reasonable MVP would be:

• associate each Codex thread with its originating VS Code workspace identity
• for .code-workspace, use the workspace file path/name as the primary project identity
• for folder-only windows, use the folder path / working directory
• in multi-root workspaces, preserve the selected root as additional metadata
• show chats from the current workspace first
• hide, collapse, or visually separate chats from other workspaces
• provide an explicit “All chats” / “Global history” view for users who intentionally want cross-project history
• show the originating workspace/project in chat metadata so old threads can be identified safely

My setup:

• OS: Windows
• IDE: VS Code
• Project organization: one .code-workspace per real project
• Workspace style: mostly single-folder .code-workspace files, sometimes multi-root workspaces with related folders opened together
• Codex usage: multiple chats per workspace, each for a separate topic/task

The long history of reports and duplicates suggests this is a recurring workflow problem, not an edge case. It is disappointing that this has remained unresolved for so long despite repeated user reports.

I strongly encourage other users affected by this to comment here with concrete examples, add reactions, and reference their VS Code / Codex extension versions. If this affects your paid Codex workflow, please say so explicitly. The current behavior materially reduces the reliability and value of Codex in real multi-project IDE usage.

Please treat workspace-scoped chat history as a core requirement for the VS Code Codex extension, not as a minor convenience feature.

It’s really annoying to search through the history for the right chat; because of this, it’s sometimes easier to choose Claude for work in vscode.

this feature is already in codex desktop app(chatgpt app).
why not in vscode extention too? just one more side panel on the other side of chat would work perfect for workspace/session list.

Adding another current macOS reproduction from a multi-project workflow.

Environment

• OS: macOS 15.7 (arm64)
• VS Code: 1.131.0 (arm64)
• Codex IDE extension: openai.chatgpt@26.727.40816
• Workflow: multiple repositories maintained in separate VS Code windows

Actual impact

After closing and reopening a VS Code window, the Codex history is still presented as a global mixed list rather than being scoped or grouped by the current project. This makes conversations for the reopened project difficult to recover.

The problem becomes more serious when different projects have similar or identical conversation titles. I have selected the wrong conversation and Codex then executed instructions that were intended for another project. This is therefore not only a navigation or organization issue; it creates a correctness and operational-safety risk for users who maintain multiple repositories.

The Codex desktop client already groups conversations by project, so the absence of equivalent organization in the VS Code extension is also a significant cross-client parity gap.

Expected behavior

• Show conversations for the current workspace/project by default.
• Display the originating project/workspace on every conversation.
• Keep an explicit “All projects” view for cross-project access.
• Warn or require confirmation before resuming a conversation whose originating workspace differs from the current VS Code workspace.

Project-scoped history should be treated as a core reliability boundary for an IDE coding agent, not only as a cosmetic enhancement.

I think there’s a lightweight first step that would already make this much safer: show the session’s originating directory alongside each thread in the history.

The thread title could remain left-aligned, while the folder and timestamp appear together as muted, right-aligned metadata. Conceptually:

Session title project-folder · 3h

If space is limited, showing only the folder name—with the full path available on hover—would probably be enough.

This wouldn’t fully solve workspace scoping or stop someone from opening a thread from another project, but it would provide an important visual cue before they do. Right now, similarly named threads are easy to confuse, and you may not realize you selected one from the wrong workspace until after continuing it.

Proper filtering or grouping would still be valuable, but displaying information the session already has seems like a small, low-risk improvement that addresses the most immediate problem.

Adding a current Windows reproduction with direct local-state evidence.

Environment

• OS: Windows
• IDE: VS Code
• Codex IDE extension: openai.chatgpt@26.803.41515
• Active workspace: a single local repository (<Project A>)
• History filter: Local chats

Observed behavior

The Local chats list contains conversations whose recorded working directories belong to unrelated local projects, including:

• <Project B>
• <Project C>
• <Project D>

The relevant Project A conversation retains the correct recorded working directory for Project A. VS Code also identifies Project A as the active workspace.

This evidence indicates that the conversation metadata and active-workspace metadata are available. The history UI currently applies a host-wide local-execution filter and omits workspace/cwd scoping.

Expected behavior

• Show conversations whose recorded cwd matches the current workspace by default.
• Provide an explicit All local chats view for host-wide history.
• Display the originating workspace or working directory for every conversation.

The current list also mirrors conversations visible under unrelated Codex Desktop projects, which makes the Local chats label especially confusing inside a repository-specific VS Code window.

@etraut-openai, I think we have sufficient evidence of community interest.
This is also a relatively insulated UI fix with existing support in the standalone Codex CLI.
Can we prioritize it or at least clarify if a community PR is welcome for it? I am sure here would be happy to contribute one.

Update on the experimental workaround I posted above: v0.6.1 now filters the visible Codex Local chats sidebar list by the active VS Code workspace root, in addition to the guarded thread/list filtering. I validated it locally with openai.chatgpt@26.803.61601 while switching between unrelated repositories.

It is still a history/navigation safeguard, not complete logical isolation: it does not change Codex core ownership semantics, block a deliberately resumed foreign thread, or enforce tool/file-access boundaries. The upstream solution should cover those paths and offer an explicit All workspaces / cross-workspace-resume flow.

Because this is a local patch against frequently changing minified extension bundles, it is version-sensitive. Keeping automatic extension updates enabled is safer overall; after an update, run npm run scan and npm run apply:dry. If anchors have changed, do not force it—wait for a retargeted release (or report the scan output). Pinning an old extension only avoids patch drift at the cost of missing normal extension updates.

Workaround and v0.6.1: https://github.com/Efs-O/codex-sessions-workspace-patch-kit/releases/tag/v0.6.1

Adding a smaller implementation note for the VS Code extension scope.

From the current openai/codex repo, the app-server side already appears to support this use case:

• codex-rs/app-server-protocol/src/protocol/v2/thread.rs has ThreadListParams.cwd / ThreadListCwdFilter.
• codex-rs/app-server/tests/suite/v2/thread_list.rs has coverage for thread_list_respects_cwd_filters.
• The generated TypeScript schema also exposes ThreadListParams.cwd.

So an MVP for the VS Code extension may only need to pass the active workspace folder path(s) into thread/list:

• default list = current VS Code workspace only, e.g. vscode.workspace.workspaceFolders.map(f => f.uri.fsPath) as the cwd filter;
• multi-root workspace = pass all roots as Many;
• empty/no workspace or explicit “All sessions” mode = omit cwd to preserve the current global view.

I could not find the VS Code extension client source in this public repo, so I’m not sure where an external PR should target. But if that source is available for contribution, this looks like a client-side wiring change rather than a new backend feature.

@etraut-openai you wrongfully closed #3550 as done and already implemented. This here is literally a duplicate of #3550. Maybe, and hopefully, I and lots of others missed the part where it was implemented. Please let us know how this has been implemented and then you could close this here too.

//EDIT: You did NOT say twice that it was closed because it's done, the first was just you saying it has been reported elsewhere but then you closed it as marked as completed. So sorry for that. But imo you still wrongfully closed it this time because you essentially said it's implemented.

I can still reproduce this in the VS Code extension.

Even when I open a specific workspace/project in VS Code, the Codex history / Local chats list still shows sessions from other unrelated projects. The visible behavior is not project-scoped from the user's perspective.

This appears inconsistent with the statement in #3550 that "Per-project scoping was added to the IDE Extension many months ago." If there is a specific setting, filter, or workflow required to enable that behavior, could you clarify it? Otherwise, the current VS Code extension behavior still seems to be a global local-chat list rather than current-workspace scoped history.

Expected behavior:

• When a VS Code workspace is open, show only sessions whose recorded cwd/workspace matches that workspace by default.
• Provide an explicit "All local chats" / "All workspaces" view for cross-project history.
• At minimum, show the originating folder/workspace on each session row to prevent selecting the wrong project session.

@etraut-openai , I am confused by your comments on #3550.
Can you elaborate how to leverage the "Per-project scoping" that was added to the IDE Extension "many months ago"?

Following up on my earlier report: I have published a small unofficial, temporary workaround for the current VS Code extension behavior:

https://github.com/cixiangtao/codex-vscode-project-patch

The reason for this tool is the same workflow problem described in this issue: a global Recent Tasks list mixes unrelated repositories, makes the intended thread harder to find, and increases the chance of resuming a project-specific conversation in the wrong VS Code window.

The workaround is deliberately narrow. The Codex app-server already accepts cwd on thread/list, and the extension bundle already has a helper based on vscode.workspace.workspaceFolders. The tool patches only the Webview-originated thread/list bridge so the current workspace folder paths are included in that request.

One-command use:

npx -y codex-vscode-project-patch

It creates and verifies a backup, checks the extension version and exact bundle SHA-256, refuses unknown or ambiguous bundles, and prints the reload and restore instructions. Restore is also one command:

npx -y codex-vscode-project-patch restore

Important scope and limitations:

• This filters the visible VS Code task history; it is not logical session isolation or a sandbox.
• It does not block a foreign thread that is already active or manually resumed.
• Multi-root matching uses exact workspace-root paths.
• There is currently no “show all” toggle in the patched UI.
• Official extension updates normally replace the modification; unsupported builds are refused until their bundle is reviewed and allowlisted.
• It patches the existing local installation only and does not redistribute the official VSIX or bundle.

The current release is 0.2.1, with a deliberately narrow allowlist documented in the repository. I consider this a proof of concept and stopgap until the extension implements workspace-scoped history and explicit cross-workspace resume behavior upstream.

@etraut-openai , I am confused by your comments on #3550. Can you elaborate how to leverage the "Per-project scoping" that was added to the IDE Extension "many months ago"?

Technically, per-project scoping was indeed implemented as you can now open workspace(s) in VSCode and Codex will recognize files in it/those and refuse to access outside files depending on the security settings. But unfortunately this has nothing to do with Codex chats and these feature requests, as chats/threads remain one big list of chats/threads of all workspaces combined. According to ChatGPT and sources it linked, there are already technical possibilities delivered by OpenAI APIs, so I hope it's just a matter of time that this gets implemented finally. And again, hopefully before the one year anniversary haha 😅

I have the same workflow issue.

I regularly open multiple VS Code windows for different repositories. In the Codex extension, seeing conversations from every repository in one global history makes it easy to resume the wrong thread.

Ideally, the default history view should be scoped to the current VS Code workspace/folder, with an optional “All projects” view.

This would also avoid having to use separate CODEX_HOME directories just to isolate project chat history.

I can confirm this issue in the Codex VS Code extension on Windows.
I opened repository A, but the chat history also showed conversations belonging to repository B. I accidentally opened a repository B thread and continued it, believing it belonged to the active repository.
This is not only an organization problem: it creates a real risk of resuming work with the wrong repository context.
Claude Code in VS Code prevents this by showing only conversations associated with the current folder or repository.
I strongly support:

• current-workspace chats as the default view;
• an explicit “All chats” toggle;
• a visible repository/CWD label for every thread;
• a warning when the thread’s recorded directory differs from the active workspace.

A concrete implementation option that would complement the workspace-scoping/grouping proposal is to automatically prefix each generated session title with its repository or workspace name.

For example, when working in vault_prestige_month_gtm:

[vault_prestige_month_gtm] Check the prefetch logic

Suggested behavior:

• Add a user or workspace setting, for example: chatgpt.sessionTitlePrefix = "[${workspaceFolderBasename}]".
• Support the Git repository name, workspace-folder name, or a configurable template.
• Preserve the generated session title after the prefix.
• Make the prefix searchable.
• For multi-root workspaces, use the repository or folder associated with the active file.
• Keep the feature disabled by default for backward compatibility.

This would be useful even if full grouping/filtering is implemented later, because the repository remains visible in search results and other global Recent Chats views.

中文补充：当前 Session 虽然会关联 VS Code project/workspace，但 Recent Chats 列表中看不到 repo 标识，导致多个仓库的会话混在一起。希望能自动添加 repo 前缀，或支持按 repo/workspace 分组和筛选。

Both windows and wsl in vscode codex
It shows all Chats/Threads from all projects only sorted by date/last activity (windows and wsl are separate of course)
It has been this way for at least the whole 2026, never saw it being any different.
Surprising to see an old issue and @etraut-openai saying that it has been implemented long time ago - https://github.com/openai/codex/issues/3550#issuecomment-5308869527

This is basically the main thing I miss in vscode extension compared to the desktop app, the chats/threads are a mess

This won't address all of the challenges discussed in these threads but I believe this is how we can address ONE challenge:

Issue: Threads from workspace1 display in the list in workspace2

Proposal

Each rollout file has field "cwd".
Add VSCode settings.json option: cross-workspace-threads.
Default to true to maintain currently annoying behavior.
When set to false, a test is performed on list display: If the Current Working Directory does not match a rollout file's "cwd", do not display that item in the list.

That's it. One option, one test.

That will work easily in VSCode because the same setting applies to User, Workspace config, and individual workspaces.

To address another similar pain point, the same can be applied to memory across workspaces with cross-workspace-memory.

If we can get approval on this I'll be happy to create a new ticket for focused effort/PR.