Scope Codex VS Code chats to the current workspace/project

[omry]

What variant of Codex are you using?

IDE Extension

cc @etraut-openai, opening this as a fresh feature request per your guidance in #17185 (comment).

What feature would you like to see?

In the Codex VS Code extension, chat/thread history should be scoped, grouped, or filtered by the current workspace/project.

Right now, chats from different projects appear together in one shared history list. When working across multiple repositories, VS Code windows, remote workspaces, WSL/SSH sessions, or unrelated codebases, it becomes easy to resume the wrong thread or confuse which chat belongs to which project.

This creates a real workflow problem because Codex threads carry project-specific context. Accidentally continuing a thread from another project can lead to irrelevant suggestions, wrong assumptions, and extra mental overhead.

A useful MVP could be:

• Associate each thread with its originating VS Code workspace folder or working directory.
• Show current-workspace threads first in the extension history.
• Hide, collapse, or visually separate threads from other workspaces.
• Provide an “all threads” view or toggle for users who intentionally want global history.
• Preserve existing thread rename/archive behavior.

This does not need to introduce a full project-management system. The most important behavior is that when I am in Project A, I should not have to scan through chats from Projects B, C, and D to find the relevant Codex thread.

Additional information

This is related to the closed issue #17185, but I am opening a new feature request per maintainer guidance here:

#17185 (comment)

There is also related discussion in #12564, where the VS Code extension recently gained thread renaming. Renaming helps, but it is only a mitigation for the broader issue: chats from unrelated projects are still mixed together.

A commenter noted that Codex CLI already appears to have working-directory-based isolation by default, with codex resume --all available for showing all threads:

#17185 (comment)

If that is accurate, the VS Code extension could potentially reuse the same working-directory concept and expose it in the extension history UI.

[github-actions]

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

• Codex Desktop sidebar sort by recent: show project and execution-context metadata in the global recent chat list #24083
• Codex Desktop: new thread from project view is created in global chat section instead of under the project #25252
• Codex Desktop project-created chats do not appear under their project in sidebar #23942

Powered by Codex Action

[whatsupbros]

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.

[daxliniere]

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

[JohnnyBill]

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

[dyunwei]

This is very important for those working across multiple projects.

[max5800]

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:

• Scope Codex VS Code chats to the current workspace/project #25319
• Support for multi-root workspaces #2909
• VS Code extension: Existing chat thread gets stuck only in one workspace until thread receives a new response elsewhere #18963
• Codex context persistence issue after closing folders in VS Code #11794
• Scope Codex chats to VS Code projects/workspaces #3550

[xsjk]

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.

[zsxm1998]

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.

[omry]

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

[xionghaizhi]

+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.