mirror of
https://github.com/pchuan98/codex.git
synced 2026-07-01 00:31:56 +08:00
efrazer-oaiandGitHub
715fafa23c
## Stack 1. This PR: expand and filter `USERPROFILE` roots. 2. Follow-up: #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: ```text 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: ```text C:\Users\me ``` becomes roots like: ```text C:\Users\me\Desktop C:\Users\me\Documents C:\Users\me\Downloads ``` and does not include: ```text 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`