core: pass permission profiles to Windows runner

[bolinfest]

Why

This is the functional handoff PR for the Windows sandbox PermissionProfile migration. After #23714, the Windows elevated backend can accept a profile-native request, but core still sent a compatibility SandboxPolicy into the elevated command-runner path. That meant profile-only details such as deny globs had to be translated through side channels instead of being preserved in the runner SpawnRequest.

Passing the real PermissionProfile completes the command-runner handoff while leaving the unelevated restricted-token fallback on the legacy policy-string API.

What

• Updates one-shot Windows elevated execution in core/src/exec.rs to call run_windows_sandbox_capture_for_permission_profile_elevated.
• Updates unified exec in core/src/unified_exec/process_manager.rs to call spawn_windows_sandbox_session_elevated_for_permission_profile.
• Passes request.permission_profile / exec_request.permission_profile and the stored Windows sandbox policy cwd to the elevated backend.
• Keeps compatibility SandboxPolicy serialization only for the non-elevated restricted-token fallback.

Verification

• cargo test -p codex-core --test all --no-run

[chatgpt-codex-connector]

💡 Codex Review

codex/codex-rs/windows-sandbox-rs/src/unified_exec/backends/elevated.rs

Lines 52 to 57 in c13b4f8

	let permissions =
	ResolvedWindowsSandboxPermissions::try_from_permission_profile(permission_profile)?;
	let elevated = prepare_elevated_spawn_context_for_permissions(
	permissions,
	codex_home,
	cwd,

Resolve managed project roots against profile cwd

This path builds ResolvedWindowsSandboxPermissions from permission_profile without anchoring it to permission_profile_cwd, then immediately prepares ACL/capability roots using the process cwd. For managed profiles that use :project_roots (including legacy workspace-write conversions), this rebinds writable roots when cwd != permission_profile_cwd, so the elevated setup can grant/deny the wrong directories and generate mismatched capability SIDs. A common trigger is running a command in a subdirectory while policy resolution is intentionally anchored to the turn sandbox cwd.

---

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

Lines 94 to 95 in c13b4f8

	let permissions =
	ResolvedWindowsSandboxPermissions::try_from_permission_profile(permission_profile)?;

Anchor elevated capture setup to permission profile cwd

The elevated capture path resolves ResolvedWindowsSandboxPermissions directly from permission_profile and then computes sandbox credentials/roots with the command cwd, never materializing project-root permissions against permission_profile_cwd. When those two directories differ (for example, command execution in a nested subdirectory), the setup ACLs and capability SID roots can be derived from the wrong base, causing the elevated runner to enforce a different filesystem scope than the request intended.

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