Do not grant Windows sandbox ACLs on USERPROFILE

[efrazer-oai]

Stack

1. This PR: expand and filter USERPROFILE roots.
2. Follow-up: Filter Windows sandbox roots from SSH config dependencies #18493 filters SSH config dependency roots on top of this base.

Bug

On Windows, Codex can grant the sandbox ACL access to the whole user profile directory.

That means the sandbox ACL can be applied under paths like:

C:\Users\me\.ssh
C:\Users\me\.tsh

This breaks SSH. Windows OpenSSH checks permissions on SSH config and key material. If Codex adds a sandbox group ACL to those files, OpenSSH can reject the config or keys.

The bad interaction is:

1. Codex asks the Windows sandbox to grant access to USERPROFILE.
2. The sandbox applies ACLs under that root.
3. SSH-owned files get an extra ACL entry.
4. OpenSSH rejects those files because their permissions are no longer strict enough.

Why this happens more now

Codex now has more flows that naturally start in the user profile:

• a new chat can start in the user directory
• a project can be rooted in the user directory
• a user can start the Codex CLI from the user directory

Those are valid user actions. The bug is that USERPROFILE is too broad a sandbox root.

Change

This PR keeps the useful behavior of starting from the user profile without granting the profile root itself.

The new flow is:

1. collect the normal read and write roots
2. if a root is exactly USERPROFILE, replace it with the direct children of USERPROFILE
3. remove USERPROFILE itself from the final root list
4. apply the existing user-profile read exclusions to both read and write roots
5. add .tsh and .brev to that exclusion list

So this input:

C:\Users\me

becomes roots like:

C:\Users\me\Desktop
C:\Users\me\Documents
C:\Users\me\Downloads

and does not include:

C:\Users\me
C:\Users\me\.ssh
C:\Users\me\.tsh
C:\Users\me\.brev

If USERPROFILE cannot be listed, expansion falls back to the profile root and the later filter removes it. That keeps the failure mode closed for this bug.

Why this shape

The sandbox still gets access to ordinary profile folders when the user starts from home.

The sandbox no longer grants access to the profile root itself.

All filtering happens after expansion, for both read and write roots. That gives us one simple rule: expand broad profile grants first, then remove roots the sandbox must not own.

Tests

• just fmt
• cargo test -p codex-windows-sandbox
• just fix -p codex-windows-sandbox
• git diff --check

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2f71016caf

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve USERPROFILE when it is the working-directory root

build_payload_roots always applies filter_user_profile_root to write roots. If command_cwd == USERPROFILE, gather_write_roots intentionally includes CWD, but this filter removes it. The payload then grants only existing child entries, so writes that require permission on the home root itself (e.g., creating a new top-level file/dir) can fail when running from home.

Useful? React with 👍 / 👎.

[efrazer-oai]

This is intended. Tradeoff is necessary to not break things like SSH as perms granted at top level percolate downward.