vscode extension does not handle multiple workspace folders
What version of Codex is running?
0.77.0
What subscription do you have?
Plus
Which model were you using?
GPT-5.2-Codex
What platform is your computer?
Linux 6.8.0-90-generic x86_64 x86_64
What issue are you seeing?
The vscode extension handles wrongly the situation where the workspace has multiple folders. It presents only one folder in writable_roots given to codex, apparently the first one.
What steps can reproduce the bug?
To repro:
- start from a test directory, e.g. ~/dm
mkdir x y z- create a xyz.code-workspace with the following content
{
"folders": [
{
"path": "y"
},
{
"path": "x"
},
{
"path": "z"
}
],
"settings": {}
}code xyz.code-workspaceto start vscode- in a new codex extension chat session in vscode ("Ask Codex to do anything"), ask "What workspace folder(s) do you see? What is writable_roots?"
- observe the response that it can see only the y directory, and that writable_roots is only the y directory. similar things can be observed in the codex session log
Notably, y is the first listed folder in the .code-workspace file, not the lexicographically smallest one. Perhaps the extension is erroneously picking out only the first folder in the .code-workspace file.
What is the expected behavior?
Codex should respond that it can see all 3 workspace folders (x, y, z) and that writable_roots includes all 3 folders, and the codex session log should show the same thing about the writable_roots given to codex.
However, I'm not sure about conventions or expectations in codex regarding the current working directory.
Additional information
With this bug, the codex sandbox can access only y but not x & z. It should be able to access x & z also.
2 Comments
We're tracking this feature request in https://github.com/openai/codex/issues/2909. Please upvote if you'd like to see that feature added.
n your setup, Codex may also start in read-only until you explicitly trust the working directory (for example, via an onboarding prompt or /permissions).
The workspace includes the current directory and temporary directories like /tmp. Use the /status command to see which directories are in the workspace.
To accept the defaults, run codex.
You can set these explicitly:
codex --sandbox workspace-write --ask-for-approval on-request
codex --sandbox read-only --ask-for-approval on-request
Protected paths in writable roots
In the default workspace-write sandbox policy, writable roots still include protected paths:
<writable_root>/.git is protected as read-only whether it appears as a directory or file.
If <writable_root>/.git is a pointer file (gitdir: ...), the resolved Git directory path is also protected as read-only.
<writable_root>/.agents is protected as read-only when it exists as a directory.
<writable_root>/.codex is protected as read-only when it exists as a directory.
Protection is recursive, so everything under those paths is read-only.
Deny reads with filesystem profiles
Named permission profiles can also deny reads for exact paths or glob patterns. This is useful when a workspace should stay writable but specific sensitive files, such as local environment files, must stay unreadable:
default_permissions = "workspace"
[permissions.workspace.filesystem]
":project_roots" = { "." = "write", "**/*.env" = "none" }
glob_scan_max_depth = 3
Use "none" for paths or globs that Codex shouldn’t read. The sandbox policy evaluates globs for local macOS and Linux command execution. On platforms that pre-expand glob matches before the sandbox starts, set glob_scan_max_depth for unbounded ** patterns, or list explicit depths such as .env, /.env, and //.env.
Run without approval prompts
You can disable approval prompts with --ask-for-approval never or -a never (shorthand).
This option works with all --sandbox modes, so you still control Codex’s level of autonomy. Codex makes a best effort within the constraints you set.
If you need Codex to read files, make edits, and run commands with network access without approval prompts, use --sandbox danger-full-access (or the --dangerously-bypass-approvals-and-sandbox flag). Use caution before doing so.
For a middle ground, approval_policy = { granular = { ... } } lets you keep specific approval prompt categories interactive while automatically rejecting others. The granular policy covers sandbox approvals, execpolicy-rule prompts, MCP prompts, request_permissions prompts, and skill-script approvals.
Automatic approval reviews
By default, approval requests route to you:
approvals_reviewer = "user"
Automatic approval reviews apply when approvals are interactive, such as approval_policy = "on-request" or a granular approval policy. Set approvals_reviewer = "auto_review" to route eligible approval requests through a reviewer agent before Codex runs the request:
approval_policy = "on-request"
approvals_reviewer = "auto_review"
The reviewer evaluates only actions that already need approval, such as sandbox escalations, network requests, request_permissions prompts, or side-effecting app and MCP tool calls. Actions that stay inside the sandbox continue without an extra review step.
The reviewer policy checks for data exfiltration, credential probing, persistent security weakening, and destructive actions. Low-risk and medium-risk actions can proceed when policy allows them. The p