Version: rust-v0.164.0; the same code is on main today. Windows 11, [windows] sandbox = "unelevated", sandbox_mode = "workspace-write", approval_policy = "on-request".
What happens
The model calls request_permissions for file_system.write on one file that does not exist yet, outside the writable roots (for example C:\Users\person\Documents\Work\brief.docx, to save a finished document there). The user approves it. The next command, Copy-Item <built file> C:\Users\person\Documents\Work\brief.docx, fails with Access to the path ... is denied (UnauthorizedAccessException). The model then asks again with sandbox_permissions = "require_escalated", and the user has to approve the same write a second time.
The grant reaches the command (apply_granted_turn_permissions merges it and the command runs WithAdditionalPermissions / permissions_preapproved), but the Windows sandbox drops the path before granting anything, because the file does not exist yet:
windows-sandbox-rs/src/allow.rs,compute_allow_paths_for_permissions:add_allow_pathkeeps a path onlyif p.exists().windows-sandbox-rs/src/setup.rs,canonical_existing(feedinggather_write_roots_for_permissions/effective_write_roots_for_permissions):if !p.exists() { return None; }.
So a write grant for a new file never becomes an allow ACE, and the approval the user gave does nothing. A grant for an existing file or a directory works. On macOS and Linux the same approved write succeeds.
Expected
An approved write to a file that does not exist yet lets that file be created, without a second approval.
Suggested fix
For a write grant whose path does not exist, grant creation of that one entry in its nearest existing parent (for example an allow ACE on the parent limited to FILE_ADD_FILE, then the file's own ACE once it exists), or have request_permissions refuse a file path that does not exist so the model asks for what the sandbox can grant. A test that grants write on a not-yet-existing file under a temp directory and then creates it from the sandboxed command would catch this.
Activity
2
84dnnvbdvp-debug8h agoOne least-authority constraint for the proposed fix: FILE_ADD_FILE is a right on a directory, not a named future child. Microsoft's file access-rights table defines it as permission to create a file in the directory. Giving the sandbox principal FILE_ADD_FILE on ...\Work to fulfill a grant for only ...\Work\brief.docx could also permit creation of an unapproved sibling (...\Work\other.txt), subject to other effective controls. This would trade a dropped approval for a broader-than-approved capability.
The current-main filtering is real in both allow.rs (add_allow_path checks p.exists()) and setup.rs (canonical_existing drops missing write roots). But simply substituting the nearest existing parent would change the permission's scope.
I'd include a negative sibling control alongside the suggested positive regression: grant only a missing brief.docx; confirm that it can be created once without a second prompt and that creating other.txt, creating a new directory, or replacing an existing sibling remains denied. Also check path canonicalization/reparse-point changes between approval and creation. If exact future-child enforcement is unavailable with the current sandbox mechanism, explicitly reject the unsupported exact-file grant or request a clearly labeled broader directory grant; don't silently widen it. This is a proposed security regression boundary, not a reproduced exploit or a claim about all effective Windows sandbox defenses.
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action