[Windows] Desktop and npm CLI alternate elevated sandbox marker state, causing repeated setup/UAC prompts

[Cainiaooo]

What version of Codex is running?

• ChatGPT/Codex Windows desktop app package: OpenAI.Codex_26.727.6591.0
• Desktop embedded command runner: 0.146.0-alpha.9.2
• Global npm Codex CLI: codex-cli 0.146.0
• Native Windows sandbox mode: elevated
• Both surfaces use the same user-level Codex state directory.

What happened?

The Windows desktop app and the globally installed npm CLI appear to use incompatible elevated-sandbox marker state while sharing:

%USERPROFILE%\.codex\.sandbox\setup_marker.json

Switching between the two runtimes causes each one to reinitialize the elevated Windows sandbox. This produces repeated sandbox-configuration prompts and Windows UAC prompts, even after setup has completed successfully.

The behavior is reproducible with harmless shell commands and is not specific to a repository or build command.

Steps to reproduce

1. Configure native Windows Codex with:

   approval_policy = "on-request"
   sandbox_mode = "workspace-write"
   
   [windows]
   sandbox = "elevated"

2. Start the Windows desktop app and run a simple tool command.

3. Approve the elevated sandbox setup once.

4. Run several additional desktop tool commands. They work without another full initialization.

5. Run the globally installed npm Codex CLI.

6. The CLI triggers another Windows sandbox initialization.

7. Return to the desktop app and run another simple tool command.

8. The desktop runtime reports that the sandbox marker is missing or incompatible and performs the full elevated setup again.

9. Alternating between the CLI and desktop app repeats the cycle.

Relevant log evidence

The desktop app uses:

codex-command-runner-0.146.0-alpha.9.2.exe

The global npm CLI uses:

codex-command-runner-0.146.0.exe

After completing setup from the desktop runtime, its marker contained schema version 5. Three consecutive desktop tool calls then completed without a marker error.

After running the global CLI once, the very next desktop tool invocation logged:

sandbox setup required: sandbox users missing or incompatible with marker version
ensuring sandbox users offline=CodexSandboxOffline online=CodexSandboxOnline
WFP setup succeeded for CodexSandboxOffline with 12 installed filters

The elevated setup itself reports success:

setup refresh: processed 3 write roots (read roots delegated); errors=[]
setup binary completed

This suggests that setup is not permanently failing. Instead, one runtime writes state that the other runtime rejects.

Expected behavior

The desktop app and CLI should not repeatedly invalidate each other's Windows sandbox setup.

Possible acceptable behaviors include:

• keep the marker schema backward/forward compatible across concurrently supported runtimes;
• namespace sandbox marker state by runtime/schema version;
• migrate the marker atomically and serialize setup with a cross-process lock;
• or give the desktop app and standalone CLI separate sandbox state while retaining shared user configuration where appropriate.

A version transition should require at most one successful administrator-approved migration, not a new UAC/setup cycle whenever the user switches surfaces.

Actual behavior

Each runtime can treat the marker written by the other as incompatible and rerun operations that manage:

• local sandbox users/groups;
• filesystem ACLs;
• Windows firewall/WFP rules;
• the sandbox setup marker.

This results in repeated UAC prompts and makes normal use of both the desktop app and CLI impractical.

Additional context

• The local sandbox users and group already exist.
• Repository write-root ACL application reports errors=[].
• The problem occurs before executing the requested command.
• The unelevated fallback is not an equivalent workaround for this workflow because restricted-token/split-write-root behavior can prevent edit/patch tools from starting correctly.
• Usernames, machine names, project paths, and proxy details have been omitted intentionally.