VS Code extension creates new chats in a stale project from global storage

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

• #34341

Powered by Codex Action

I also am having this issue, and yes I use multiple VSCode windows simultaneously.
So having multiple windows active may well be a trigger for the issue.
Edit: I am running on Windows 11

For windows, the equivalent path is %APPDATA%\Code\User\globalStorage\state.vscdb
You can use any normal SQLite DB editing software to edit the table, such as "DB Browser for SQLite".
But if you use a GUI based SQLite editor then remember to remove the \" escaping in the SQLite command provided above.
If you use this command then it will show you the end result for sanity, you know it worked if it says "extracted_project" is NULL.

UPDATE ItemTable SET value=json_remove(value, '$."selected-project"') WHERE key='openai.chatgpt';
SELECT json_extract(value, '$."selected-project"') AS extracted_project FROM ItemTable WHERE key = 'openai.chatgpt';

I can independently reproduce this on Windows, with a more severe consequence than mixed chat history: new prompts execute against the stale project’s working directory and writable root, not the workspace visibly open in the current VS Code window.

Verified local evidence:

%APPDATA%\Code\User\globalStorage\state.vscdb
key: openai.chatgpt
"selected-project": {"type":"local","projectId":"<redacted stale project path>"}

Observed behavior:

1. Open a different repository in another VS Code window.
2. Create a brand-new Codex chat there.
3. Run a read-only working-directory check such as Get-Location.
4. The result is the stale globally selected project, and the new thread is persisted with that stale cwd/project assignment.
5. File reads and writes are consequently scoped to the unrelated repository.

The normal recovery paths did not fix it:

• changing the project in the Codex project selector;
• fully quitting VS Code and reopening it;
• signing out and back in.

This indicates that the visible selector and the new-thread/execution path may not be using or refreshing the same state consistently. Renaming the affected directory is not a fix because the stale pointer remains in global state.

This should be treated as a cross-project data-integrity and security issue, not only a chat-scoping/UI issue: a user can unknowingly read, modify, or create files in an unrelated repository. A safe behavior would be to derive a new IDE chat’s cwd and writable roots from the active VS Code workspace, or fail closed and require explicit confirmation whenever a stored global project conflicts with the active workspace.

Environment: Windows 11 Pro, VS Code 1.129.1. The latch began while running pre-release extension 26.5715.61943. Updating to stable 26.715.61943 did NOT clear it; the stale selected-project survived the update and continued to capture new chats until the key was removed from global storage.

Additional evidence for the root cause: every misassigned thread on my machine was persisted with "localProjectId": null while its workspaceRoots carried the stale path. This corroborates the fallback theory in the original report from a second independent machine: when workspace-root resolution returns nothing, the extension silently substitutes the global selected-project instead of failing closed.

Resolution steps that worked:

1. Close ALL VS Code windows first. This matters for two reasons: the extension rewrites its global storage from memory on exit, so any edit made while VS Code is running gets clobbered; and the extension's codex.exe app-server processes keep the stale directory as their working directory (this even blocks renaming that directory on Windows).
2. Remove the stale key from %APPDATA%\Code\User\globalStorage\state.vscdb (same SQL @dsisco11 posted above):

UPDATE ItemTable SET value=json_remove(value, '$."selected-project"') WHERE key='openai.chatgpt';

1. Reopen VS Code. New chats now resolve to the active window's workspace, verified with Get-Location in a fresh chat across multiple projects.

Cleanup of already-misassigned threads (optional): removing selected-project fixes new chats only. Threads created during the latch stay bound to the stale project's cwd and writable root forever, and a queued follow-up message in such a thread will still execute against the stale directory when delivered. To fully purge them I had to remove, per thread id: the rollout file in ~\.codex\sessions\, the matching line in ~\.codex\session_index.jsonl, rows referencing the id in ~\.codex\state_5.sqlite, and the thread-project-assignments / thread-writable-roots entries under the openai.chatgpt key in state.vscdb.

I am having simialr issue:

Issue:

1. Open C:\Projects\project-a in the Codex desktop app.
2. Open a different project, C:\Projects\project-b, in VS Code.
3. Confirm that VS Code Explorer and the integrated terminal are using project B.
4. Create a new chat from the Codex VS Code panel.
5. Ask the chat for its working directory or run git rev-parse --show-toplevel.

The VS Code chat incorrectly receives project A—the project selected in the desktop app—as its workspace instead of project B.

I reproduced this after:

• Creating multiple new chats
• Running Developer: Reload Window
• Fully closing all VS Code windows
• Reopening VS Code directly from project B

This appears to be workspace state leaking from the Codex desktop app into the VS Code extension. It is potentially dangerous because commands or edits could target the wrong repository.

Environment:

• Codex VS Code extension: 26.715.61943
• VS Code: 1.130.0
• Windows: 10.0.26200.0 x64

Running into this same issue except it will happen randomly during a session, not just when starting a new session. GPT will then say something like:

The workspace is still absent; /workspaces contains only the [other] repository. This is the second consecutive mount-blocked turn.

I cannot safely inspect, edit, review, or dispatch agents against [current-project] until /workspaces/[current-project] is restored. Please reopen/remount the repository workspace. The last verified commit before disappearance was cb2f256.

Can reproduce on 26.715.31925 and 26.715.61943. Cannot reproduce after downgrading the extension to 26.707.91948. Have not tried any newer versions of the extension due to #35058.

我也遇到了这个问题，我也是觉得自动识别当前的工作项目比较好，我现在是每次在项目里新增一个仓库级规则，后Codex 每轮首次执行项目命令前会：

• 检查 Get-Location
• 检查 git rev-parse --show-toplevel
• 确认根目录是否是当前目录
• 每条项目命令显式指定该工作目录
• 如果目录不符，立即停止，不读取或修改错误项目
• 不允许通过申请沙箱外权限绕过目录检查