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

[dfederm]

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

• Managed-settings interim fail-closed uses an empty allow list ([[]]) and permanently drops user MCP servers that register inside the window — reproduces via the desktop app, on an account with no managed policy #4419: interim managed-settings fail-closed permanently drops MCP servers
• Non-interactive (-p) sessions: tool-call approval silently and permanently revoked mid-session, causing unrecoverable 'Permission denied and could not request permission from user' #4433: fail-closed permission revocation; self-closed without resolution
• Local sandbox on Windows failed to run command with error E_NOTIMPL #3849: MXC failure after intentional sandbox enable; this report concerns involuntary activation

[dfederm]

Additional diagnostic result: explicitly providing GH_TOKEN before launching Copilot CLI 1.0.81-1 avoids the problem.

$env:GH_TOKEN = gh auth token --hostname github.com
try {
    copilot --secret-env-vars=GH_TOKEN
}
finally {
    Remove-Item Env:GH_TOKEN
}

In that session, a git status --short  tool call was labeled shell rather than sandboxed shell and completed successfully. Without GH_TOKEN, the same CLI/configuration labels it sandboxed shell and fails through MXC.

This strongly suggests the trigger is the managed-settings startup path temporarily failing to obtain the GitHub token. The remaining bug is that this transient authentication failure installs a fail-closed sandbox floor that overrides sandbox.enabled: false and is not reliably rolled back.

[JoelMWatson]

fwiw I was able to do a similar thing to dfederm by just running copilot login before actually opening copilot which got me the token.