windows-sandbox: send permission profiles to elevated runner

[bolinfest]

Why

This is the next PR in the Windows sandbox migration stack after #22896. The bottom PR introduces a Windows-local resolved permissions helper while existing callers still start from legacy SandboxPolicy. This PR moves the elevated runner IPC boundary to PermissionProfile, which makes the direction of the stack visible without changing the public core call sites yet.

Because that changes the CLI-to-command-runner message shape, the framed IPC protocol version is bumped in the same PR so the boundary change is explicit.

What changed

• Replaced elevated IPC policy_json_or_preset/sandbox_policy_cwd fields with permission_profile/permission_profile_cwd.
• Bumped the elevated command-runner IPC protocol to IPC_PROTOCOL_VERSION = 2 and switched parent/runner frames to use the shared constant.
• Converted the parent elevated paths from the parsed legacy policy into a materialized PermissionProfile before sending the runner request.
• Added WindowsSandboxTokenMode resolution for managed PermissionProfile values and made the runner choose read-only vs writable-root capability tokens from that resolved profile.
• Rejected disabled, external, unrestricted, and full-disk-write profiles before token selection.
• Added IPC JSON coverage for tagged PermissionProfile payloads and token-mode unit coverage for the resolved permission helper.

Verification

• cargo test -p codex-windows-sandbox
• just fix -p codex-windows-sandbox
• cargo check -p codex-windows-sandbox --target x86_64-pc-windows-msvc --tests was attempted locally but blocked before crate type-checking because the macOS compiler environment lacks Windows C headers such as windows.h and assert.h; GitHub Windows CI is the required verification for the runner path.

---

Stack created with Sapling. Best reviewed with ReviewStack.

• core: pass permission profiles to Windows runner #23715
• windows-sandbox: add profile-native elevated APIs #23714
• windows-sandbox: feed setup from resolved permissions #23167
• windows-sandbox: drive write roots from resolved permissions #22923
• -> windows-sandbox: send permission profiles to elevated runner #22918

[chatgpt-codex-connector]

💡 Codex Review

codex/codex-rs/windows-sandbox-rs/src/resolved_permissions.rs

Lines 102 to 104 in 7fbefbb

	let mut roots = self
	.file_system
	.get_writable_roots_with_cwd(cwd)

Filter SlashTmp out of Windows writable roots

In the Windows sandbox path this now feeds the generic runtime filesystem policy directly into get_writable_roots_with_cwd, but the default workspace-write profile still contains the Unix-only :slash_tmp write entry (exclude_slash_tmp defaults to false). On Windows, that special path resolves as a rooted \tmp/current-drive path and, when C:\tmp exists, compute_allow_paths/setup will grant the write capability there even though the previous Windows-specific code only added the command cwd, configured roots, and TEMP/TMP. This broadens every default workspace-write Windows sandbox on machines with that directory, so the Windows resolver should ignore FileSystemSpecialPath::SlashTmp (or otherwise preserve the old Windows behavior).

---

codex/codex-rs/windows-sandbox-rs/src/resolved_permissions.rs

Lines 102 to 104 in 7fbefbb

	let mut roots = self
	.file_system
	.get_writable_roots_with_cwd(cwd)

Avoid resolving Unix TMPDIR for Windows tmp grants

For profiles containing :tmpdir (including the default workspace-write profile), this call resolves the generic FileSystemSpecialPath::Tmpdir before the Windows-specific TEMP/TMP handling below. That generic resolver reads the parent process TMPDIR, not the command env, so a Windows run where TMPDIR is set to an existing absolute path will grant write access to that unrelated directory in addition to TEMP/TMP; the old Windows-specific code only considered TEMP and TMP from env_map/process env. Filter the symbolic tmpdir entry out before calling get_writable_roots_with_cwd or make the Windows path resolution use the TEMP/TMP logic exclusively.

ℹ️ 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".

[bolinfest]

Addressed the two Windows temp-root review items in the current stack.

• :slash_tmp and generic :tmpdir entries are filtered before the Windows writable-root resolver calls get_writable_roots_with_cwd, so Windows no longer grants C:\tmp/\tmp or parent-process TMPDIR as a generic path.
• :tmpdir write support now goes through the Windows-specific TEMP/TMP handling only, using the command env map first and then process env.
• Coverage is in permission_profile_workspace_write_uses_windows_temp_env_vars in codex-rs/windows-sandbox-rs/src/resolved_permissions.rs.

Relevant code is in ResolvedWindowsSandboxPermissions::writable_roots_for_cwd and windows_temp_env_roots.

[iceweasel-oai]

approved - couple of nit/comments