Support for multi-root workspaces

I think this is already added in the CLI. I'm not sure why it hasn't yet been added to the extension?
Pls see this https://github.com/openai/codex/issues/2797

It would be so amazing to have that added to the extension!

Eagerly hoping the vscode plugin also supports --add-dir

This is killing me trying to move to using Codex as my primary coding assistant agent. It works so great on my first project/root in my multi-root workspace. However, working with other projects/roots is very painful with worse results and constant lack of permission (it needs to keep asking me, despite autoApprove configuration of **/* which works as expected for the 1st root).

This problem has troubled me for a long time, and I hope it can be resolved.

still waiting ..

This is such an important "feature" to be missing. Makes Codex unusable for those with multiple root folders. Other extensions like Copilot and Claude have no issues with this.

Cursor support just added: https://cursor.com/changelog/04-24-26#multi-root-workspaces-in-agents-window

This is currently the most upvoted open issue affecting the VS Code extension that causes broken behavior (e.g., incorrect paths, broken links, and approval request issues).

Given that this is a confirmed bug impacting core functionality for many users, would it make sense to add the "bug" label for better visibility and triage?

For reference: https://github.com/openai/codex/issues?q=is%3Aissue%20state%3Aopen%20sort%3Areactions-%2B1-desc%20label%3Aextension

I had the exact same issue on Windows. Moved to claude code and it works like a charm.
It's a very basic functionality and is a must have for many of us.

Yes, this absolutely needs to be fixed. It makes no sense that Codex can only work in one of the folder in the workspace.

asked codex about this bug:

Summary
The VS Code extension handles multi-root UI links, but Codex receives paths relative to the first workspace root. Users report broken file lookup, broken links, and approval prompts for non-first roots. Comments confirm this affects Linux and Windows, and users specifically ask for --add-dir / multi-root support.
Proposed Fix
Make the VS Code extension send workspace-root information explicitly.
In the extension, enumerate vscode.workspace.workspaceFolders.
Use absolute folder.uri.fsPath values only.
Pick cwd as:the workspace folder containing the active editor or referenced file;
otherwise the first workspace folder.

Send all workspace folders to Codex:CLI / TypeScript SDK path: workingDirectory = cwd, additionalDirectories = allRootsExceptCwd.
app-server v2 path: send cwd plus runtimeWorkspaceRoots = allRoots.

The backend already supports the required shape:
TS SDK forwards additionalDirectories as repeated --add-dir: [exec.ts (line 22)](/Users/f.lamein/git/openai/codex/sdk/typescript/src/exec.ts:22), [exec.ts (line 114)](/Users/f.lamein/git/openai/codex/sdk/typescript/src/exec.ts:114)
app-server v2 has thread/start.runtimeWorkspaceRoots: [thread.rs (line 112)](/Users/f.lamein/git/openai/codex/codex-rs/app-server-protocol/src/protocol/v2/thread.rs:112)
app-server v2 has turn/start.runtimeWorkspaceRoots: [turn.rs (line 96)](/Users/f.lamein/git/openai/codex/codex-rs/app-server-protocol/src/protocol/v2/turn.rs:96)
backend dedupes runtime roots: [request_processors.rs (line 534)](/Users/f.lamein/git/openai/codex/codex-rs/app-server/src/request_processors.rs:534)
core already tests rebinding permission profiles to runtime workspace roots: [session/tests.rs (line 2495)](/Users/f.lamein/git/openai/codex/codex-rs/core/src/session/tests.rs:2495)
Extra Detail
The extension should also rewrite editor/file mentions to absolute paths before placing them in the prompt context. Relative display labels are fine in the UI, but the payload to Codex needs either absolute paths or a root-qualified form that the backend can resolve.
Tests
Add VS Code extension tests for:
two workspace folders, active file in second root;
prompt references a file in second root;
generated request includes all roots and cwd points at the containing root;
Windows paths round-trip correctly;
approval/auto-approve behavior works for files outside the first root.
This is mainly an extension-side bug. The repo already has most backend/SDK machinery needed.

This suggest to me that this bug is in the wrong repository, and it should be in the vscode extension repository, that I haven't found yet 😅

This suggest to me that this bug is in the wrong repository, and it should be in the vscode extension repository, that I haven't found yet 😅

I did not experience this bug with Claude.

+1 for first-class Codex App support for multi-root workspaces.

My workflow often spans separate repos like frontend, backend, and shared libraries. CLI --add-dir / workspace_roots can grant access, but the App still feels centered on one project root per thread.

I’d love a reusable Codex App workspace with multiple roots where file search, @ mentions, diffs, Git actions, worktrees, and per-repo AGENTS.md context all work naturally across roots.

Main use case: one product change that updates an API, web client, shared types, and tests across multiple repos without splitting the work into separate Codex threads.

As a workaround I place all repos in a folder which is then the only folder added to the workspace. It works well with Codex, but requires you to move repos around if you want a different workspace with some of the same repos, so it's hardly ideal.

> This suggest to me that this bug is in the wrong repository, and it should be in the vscode extension repository, that I haven't found yet 😅 I did not experience this bug with Claude.

Github copilot vscode extension also does not have this problem
My point was that I don't think this codex repo has the source for the vscode-extension

As a workaround I place all repos in a folder which is then the only folder added to the workspace. It works well with Codex, but requires you to move repos around if you want a different workspace with some of the same repos, so it's hardly ideal.

won't this absolutely blow up your IDE context, eating away your input tokens?

> As a workaround I place all repos in a folder which is then the only folder added to the workspace. It works well with Codex, but requires you to move repos around if you want a different workspace with some of the same repos, so it's hardly ideal. won't this absolutely blow up your IDE context, eating away your input tokens?

It works for me, I have maybe 4-5 repos in the workspace. I don't think it would be different from have multiple repos in the workspace root.