Copilot CLI 1.0.81 forces sandbox while managed policy is undetermined, overriding sandbox.enabled=false

Describe the bug

Copilot CLI 1.0.81-1 enables the local sandbox while server-managed policy is temporarily undetermined, even when the user explicitly configured "sandbox": { "enabled": false }, device MDM contains no sandbox settings, no file-based managed settings exist, and sandboxing was never enabled interactively.

The provisional managed-policy fail-closed state overrides the local false setting and forces shell, local MCP, and LSP processes into Windows MXC. MXC cannot initialize on this host, so those tools fail. The session does not recover after policy resolution later succeeds. The same machine, account, configuration, repository, and prompt work on 1.0.80-1.

This appears to be a Copilot CLI managed-settings startup/recovery regression, not a request to troubleshoot MXC after intentional sandbox activation.

Affected version

GitHub Copilot CLI 1.0.81-1. The backend failure was also observed in payload 1.0.81-0.

Controlled comparison: 1.0.81-1 versus 1.0.80-1.

Steps to reproduce the behavior

Environment

• Windows 11 Enterprise 25H2 build 26200.9106, x64
• Node.js v24.18.1
• PowerShell / Windows Terminal
• Copilot authenticated through GitHub CLI
• gh auth token --hostname github.com succeeds directly
• Device MDM has unrelated remoteControl settings only; no sandbox.* values
• %ProgramFiles%\GitHubCopilot\managed-settings.json is absent
• User settings include experimental: true and sandbox.enabled: false
• The issue also reproduces with --no-experimental

Reproduction command

copilot --allow-all --no-remote --output-format text -p "Use the shell tool to run: git status --short. Report only SHELL_OK if the command executes, otherwise report the exact failure."

The observed tool label is (sandboxed shell), followed by:

GenericFailure, backend_unavailable: BaseContainer is unavailable; DACL fallback requires write-DAC permission on 'C:\Program Files\nodejs', which the current user lacks (ERROR_ACCESS_DENIED (WRITE_DAC not granted)).

Explicit sandbox.enabled: false does not prevent activation. The same behavior occurs with --no-experimental.

Sanitized startup sequence

[DEBUG] [auth::gh] GitHub CLI authenticated with valid token
[DEBUG] [auth::gh] gh auth token exited non-zero {exit_code: Some(1), stderr: no oauth token found for https://github.com}
[INFO] [managedSettings] device MDM policy loaded: bypassDisabled=false, keys=[remoteControl]
[INFO] [managedSettings] no token available to fetch server policy — failing closed (bypass stays disabled until policy is known)
[INFO] [managedSettings] effective policy resolved: source=mdm, bypassDisabled=false, serverFetchFailed=true
[WARNING] [managedSettings] sandbox floor only partially determined (serverUndetermined=true, deviceLoadFailed=false, deviceSandboxUndetermined=false): no usable token for the selected account
[INFO] [managedSettings] applied: bypass-permissions mode DISABLED by enterprise policy (fail-closed: policy could not be determined) — /allow-all and permission escalation are now blocked
mcp apply_session_settings {sandbox_changed:true, policy_already_applied:true, has_managed_settings:true}
[INFO] [sandbox_spawn] sandbox launch directory: <working-directory>

The local MCP server fails for the same reason: BaseContainer is unavailable, and DACL fallback requires WRITE_DAC on C:\Program Files\nodejs. Its error message states that organization policy requires MCP sandboxing.

Later initialization sees a valid token and confirms that device policy permits bypass, but the existing session remains sandboxed. This exposes an internal inconsistency: the process reports valid GitHub CLI authentication, then the managed-settings lookup claims the GitHub CLI token is unavailable, while the exact gh auth token --hostname github.com command succeeds outside Copilot.

Expected behavior

• sandbox.enabled: false remains effective unless a resolved managed policy requires sandboxing.
• A provisional managed floor is reversible after policy resolution.
• Startup gates shell, MCP, and LSP until managed policy resolution instead of racing their initialization.
• UI and logs describe the state as provisional rather than claiming a real organization requirement.
• An unavailable Windows sandbox backend does not destroy sessions because of a policy that was never configured.

Additional context

1.0.80-1 control

The directly retained 1.0.80-1 payload succeeds:

node "$HOME\.copilot\pkg\win32-x64\1.0.80-1\index.js" --allow-all --no-auto-update --no-remote --output-format text -p "Use the shell tool to run: git status --short. Report only SHELL_OK if the command executes, otherwise report the exact failure."

It displays ordinary (shell) and returns SHELL_OK. Multiple interactive 1.0.80-1 sessions work without BaseContainer failures.

Impact and recovery evidence

All concurrently launched development sessions lost shell, search, MCP, and LSP. --allow-all, --no-experimental, and explicit local false did not help. Pinning 1.0.80-1 was the only reliable recovery.

During an attempted issue filing, /sandbox disable temporarily worked, but a managed-settings refresh re-enabled the sandbox before the next tool invocation.

Related but not duplicates

• #4419: interim managed-settings fail-closed permanently drops MCP servers
• #4433: fail-closed permission revocation; self-closed without resolution
• #3849: MXC failure after intentional sandbox enable; this report concerns involuntary activation

Start by tracing the managedSettings startup and recovery flow around mcp apply_session_settings and sandbox_spawn, then compare the 1.0.81-1 behavior with the retained 1.0.80-1 index.js entry point. Reproduce the command with sandbox.enabled=false and verify that local settings remain effective unless resolved policy requires sandboxing, that policy resolution can recover the session, and that shell, MCP, and LSP initialization no longer races it.