Scope Codex chats to VS Code projects/workspaces

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 ah that's a good workaround for now yep. Thanks

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)

<img width="393" height="149" alt="Image" src="https://github.com/user-attachments/assets/84d522e1-5725-49ea-923a-23ad30607fa8" />

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)

Would be really helpful if that worked in the extension as well.
Using codex-cli in the terminal, we already get previous sessions scoped to the current cwd when doing codex resume.

How is this not sorted out yet? The Codex app does, and so does the CLI. Hell, there's even a 'filter tasks by environment' button in the dropdown for sessions, but it says failed to load environments.

Yeah, this is quite annoying. Could we please have this resolved?

This is a security violation. It poisons contexts across repos. This should be #1 on OpenAI's backlog. This has already cost me a couple of days thinking I went crazy because Codex made this change without notifying the users adequately about the HUGE SECURITY VIOLATIONS this introduces. They strain a gnat but swallow a camel.

This is affecting me in Codex desktop as a workspace/thread-scoping problem. If a one-off misc thread is started while I’m inside a repo workspace, the thread stays associated with that project in the left sidebar and I can’t find a clean way to move/re-home it later. Archive helps hide it, but doesn’t solve the underlying workspace assignment issue. A move/reassign-thread action would help a lot.

Any update on this?

I ended up building a workaround (tested on macos) for this while waiting on a native fix:

https://github.com/stephenjoly/codex-session-indexer
https://stephenjoly.github.io/codex-session-indexer/

It reads Codex’s local session store (~/.codex/sessions + ~/.codex/session_index.jsonl) and generates a codex-sessions.md file inside each project directory, plus a global recent-session index.

So it does not change the built-in Recent Tasks UI in VS Code, but it does give you a per-project session history based on the recorded cwd, including:

• most recent sessions
• most active sessions
• prompt counts
• session lifetime
• optional watcher / macOS daemon mode

Install:

curl -fsSL https://raw.githubusercontent.com/stephenjoly/codex-session-indexer/main/install.sh | bash

If anyone here tries it and has ideas for improvement, I’d love feedback.

Any updates?

devs, please prioritize this issue. Vscode+codex is barely usable because of the clutter from all threads from all projects without knowing which project they are from.

I hit the same issue and used a small local patch as a workaround.

The idea is to insert the following code at the very top of the Codex VS Code extension’s out/extension.js, before the extension starts the Codex process. This sets process.env.CODEX_HOME according to vscode.workspace.name, so the later spawned codex app-server inherits the workspace-specific CODEX_HOME from its parent extension process.

(() => {
  const fs = require("fs");
  const path = require("path");
  const vscode = require("vscode");  
  const os = require("os");

  const n = vscode.workspace.name;
  const h = os.homedir();
  if (!n || !h) return;

  const src = path.join(h, ".codex");
  const dst = path.join(h, ".codex", "workspaces", n);

  fs.mkdirSync(dst, { recursive: true });

  const link = x => {
    const s = path.join(src, x);
    const t = path.join(dst, x);
    if (!fs.existsSync(s) || fs.existsSync(t)) return;

    const isDir = fs.statSync(s).isDirectory();
    fs.symlinkSync(s, t, isDir && process.platform === "win32" ? "junction" : isDir ? "dir" : "file");
  };

  [
    "auth.json",
    "config.toml",
    "AGENTS.md",
    "rules",
    "skills",
    "plugins",
    "agents",
  ].forEach(link);

  process.env.CODEX_HOME = dst;
})();
````

For Remote-SSH, the file is usually something like:

```text
$HOME/.vscode-server/extensions/openai.chatgpt-*/out/extension.js

For local VS Code, it is usually something like:

$HOME/.vscode/extensions/openai.chatgpt-*/out/extension.js

This creates one Codex home per VS Code workspace:

~/.codex/workspaces/<workspace name>/

auth.json, config.toml, AGENTS.md, rules, skills, plugins, and agents are symlinked from ~/.codex, so each workspace can share configurations and you won’t need to log in again for each workspace. But sessions and session_index.jsonl are not linked, so they stay independent per workspace.

After this patch, new Codex sessions are stored under the workspace-specific CODEX_HOME. Existing sessions under ~/.codex need to be manually copied to the corresponding workspace directory if you want to keep using them.

lol, this is "default behavior"

Strongly agree with this. I usually have multiple VS Code projects open, and all Codex chats end up mixed together in one global history. After a while it becomes really hard to find the right thread or keep conversations tied to the project they belong to.

A per-workspace/project history, plus an optional “all projects” view, would make this much easier to manage.

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.