›_ Codex Issues
Codex Issues / #32419

Codex IDE restores chat history with a stale workspace root and silently edits files in the old project

Open 💬 2 comments Opened Jul 11, 2026 by zplincuhk
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the IDE extension are you using?

Version: 26.707.41301

What subscription do you have?

gpt plus

Which IDE are you using?

vscode

What platform is your computer?

ubuntu20.04

What issue are you seeing?

When I restore an existing Codex conversation after switching projects, the conversation history and current IDE file context are restored, but Codex remains bound to the previous workspace directory.

The IDE showed a file from the current project, while Codex silently resolved its relative path against the old workspace. It then read and modified files in the old project without warning.

This creates a serious risk of silently editing the wrong version of a project. Codex should validate the IDE workspace root when restoring a conversation, block writes when the workspace has changed, and clearly display the target project before modifying files.

What steps can reproduce the bug?

  1. Open Project A in the IDE and start a Codex conversation.
  2. Work with a file that uses a common relative path, such as src/main.cpp.
  3. Close or switch away from Project A.
  4. Open Project B, which contains a file with the same relative path.
  5. Restore or continue the Codex conversation created in Project A.
  6. Ask Codex to inspect or modify the active file shown by the IDE.
  7. Observe that the IDE context refers to Project B, while Codex may still use Project A as its workspace root and modify files there without warning.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #31879
  • #32383

Powered by Codex Action

cixiangtao · 11 days ago

A temporary mitigation is now available for one path into this failure: accidentally selecting a thread that belongs to another workspace from the global VS Code task history.

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

The unofficial CLI patches only the VS Code extension history request, adding the current vscode.workspace.workspaceFolders paths to Webview-originated thread/list calls. This makes Recent Tasks use exact saved-cwd filtering for the current workspace.

npx -y codex-vscode-project-patch

To undo it:

npx -y codex-vscode-project-patch restore

Why this may help here: hiding foreign-workspace threads from the normal Recent Tasks list reduces the likelihood of restoring a Project A conversation while Project B is open.

Why this is not a fix for this bug: it does not validate or rebind the cwd of an already active/restored thread, does not block a manual cross-workspace resume, and does not prevent writes when IDE context and thread workspace diverge. The upstream extension still needs a visible workspace identity plus a blocking mismatch check before execution.

The tool is a version/hash-gated proof of concept: it backs up the official bundle, refuses unknown builds or patch anchors, verifies the result, and never redistributes the VSIX. Official extension updates may remove the patch. It should be treated only as a stopgap until workspace validation is implemented upstream.