Avoid PowerShell profiles in elevated Windows sandbox

[iceweasel-oai]

Why

On Windows, elevated sandboxed commands run under a dedicated sandbox account while HOME / USERPROFILE can still point at the real user's profile directory. For PowerShell login shells, that combination can make the sandbox account try to load the real user's PowerShell profile script. If the sandbox account's execution policy differs from the real user's policy, startup can emit profile-loading errors before the requested command runs.

For this backend, loading the profile is not a faithful user login shell: it is cross-account profile execution. Treating these PowerShell invocations as non-login shells avoids that invalid startup path.

Why This Happens Late

The normal login decision is resolved when shell argv is created, but that point is too early to make this Windows sandbox-specific decision. At argv creation time we do not yet know the actual sandbox attempt that will run the command. A turn can include sandboxed and unsandboxed attempts, and a broad turn-level override would also affect Full Access commands where the user's profile should remain available.

Instead, this change carries the selected ShellType alongside the argv and applies the -NoProfile adjustment in the shell runtimes once the SandboxAttempt is known. That keeps the override scoped to actual WindowsRestrictedToken attempts with WindowsSandboxLevel::Elevated.

The runtime uses the selected shell metadata rather than re-detecting PowerShell from argv. That avoids brittle parsing and covers PowerShell invocation shapes such as -EncodedCommand.

What Changed

• Carry selected shell metadata through exec_command / unified exec requests and shell tool requests.
• Insert -NoProfile for PowerShell commands only when the runtime is about to execute a sandboxed elevated Windows attempt.
• Add focused unit coverage for elevated Windows PowerShell, -EncodedCommand, existing -NoProfile, legacy restricted-token attempts, unsandboxed attempts, and non-PowerShell commands.

Verification

• cargo test -p codex-core disable_powershell_profile_tests
• cargo test -p codex-core test_get_command
• cargo clippy --fix --tests --allow-dirty --allow-no-vcs -p codex-core

A full cargo test -p codex-core run was also attempted during development, but it still hit an unrelated stack overflow in agent::control tests before reaching this area.