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.