Add opt-in direct Windows launch mode for elevated Codex sessions

[daaimengermengzhu]

Summary

• Add a windowsCodexLaunchMode setting with the existing packaged activation path as the default.
• Add an opt-in directProcess mode that skips IApplicationActivationManager::ActivateApplication for WindowsApps Codex packages.
• When directProcess is enabled for a packaged Codex install, stop existing Codex processes before launching app\Codex.exe directly so Electron single-instance handoff does not reuse a non-elevated process.
• Expose the setting in the manager UI under Codex launch parameters.

Motivation

Codex++ already embeds a requireAdministrator Windows manifest, but the current WindowsApps launch path uses packaged app activation. In practice, that can create the official Codex process through the Windows app model rather than as a child of the elevated Codex++ launcher. The result is that codex-plus-plus.exe is elevated, while the actual Codex.exe, codex.exe app-server, and worker processes are not.

This opt-in mode lets users who need elevated Codex sessions launch the official app\Codex.exe directly from the elevated Codex++ process.

Compatibility

The default remains packagedActivation, so existing users keep the current behavior unless they explicitly enable the new Windows direct launch option.

Verification

• npm run check in apps/codex-plus-manager
• npm run vite:build in apps/codex-plus-manager
• rustfmt --edition 2024 --check on touched Rust files
• cargo test -p codex-plus-core direct_windows
• cargo test -p codex-plus-core settings_deserialize_reads_windows_codex_launch_mode
• cargo test -p codex-plus-core launcher_uses_packaged_activation_by_default_for_windows_packages
• cargo clippy -p codex-plus-core --all-targets --all-features
• cargo build --release
• git diff --check

Notes:

• cargo clippy -p codex-plus-core --all-targets --all-features -- -D warnings reports existing warnings outside the changed code, so the PR does not include unrelated clippy cleanup.
• cargo test --all-features --jobs 1 was attempted on Windows with Git sh.exe added to PATH; suites relevant to this change passed, but one existing upstream_worktree test failed in this local environment.
• Full-repo cargo fmt --check currently reports formatting differences in pre-existing untouched files under crates/codex-plus-data/, so this PR intentionally avoids formatting unrelated files.

Manual Windows Validation

1. Build/install Codex++ from this branch.
2. Start Codex++ Manager as usual.
3. Enable the Windows direct Codex launch option in settings.
4. Restart Codex through Codex++.
5. Verify with:

Get-CimInstance Win32_Process |
  Where-Object { $_.Name -match '^Codex\.exe$|^codex\.exe$|^node_repl\.exe$' } |
  Select-Object ProcessId, ParentProcessId, Name, ExecutablePath, CommandLine

Then inspect the listed processes with Process Explorer's Elevated column, or with a local token probe. Expected result: the official Codex process tree launched by Codex++ is elevated when Codex++ itself is elevated.

Local validation result: launching Codex++ as administrator created the official Codex main process with codex-plus-plus.exe as its parent, and the active codex.exe, node_repl.exe, and PowerShell worker processes were elevated.

[daaimengermengzhu]

Merged the latest upstream \main\ into this branch and resolved conflicts in \�pps/codex-plus-manager/src/App.tsx\ and \crates/codex-plus-core/src/settings.rs\ by preserving both the new upstream goal/context settings and this PR's \windowsCodexLaunchMode\ setting.\n\nPost-merge local checks:\n-
pm run check\ in \�pps/codex-plus-manager: passed\n-
pm run vite:build\ in \�pps/codex-plus-manager: passed\n- \git diff --check: passed\n- conflict marker scan: clean\n\nI attempted to rerun the Rust target tests after the merge, but this Windows machine hit pagefile/resource limits while compiling dependencies after a clean \ arget/\ rebuild. The failure was an OS resource/mmap issue, not a Rust test assertion failure.