`--yolo` / `--allow-all` blocked for the whole session by a fail-closed bypass restriction applied on an account with NO managed policy

[jordanms]

Describe the bug

On every interactive start, the CLI applies the managed-settings fail-closed posture that disables bypass-permissions mode — on an account where the policy resolves as absent and where nothing failed. Once applied it is never lifted for the life of the session, so --yolo, --allow-all-* and /allow-all stay blocked.

The startup log contradicts itself within 1 ms:

[managedSettings] device MDM: no policy present on this device
[managedSettings] server policy fetch skipped: no authenticated GitHub host available
[managedSettings] effective policy resolved: source=none, bypassDisabled=false,
                  serverFetchFailed=false, policyHelperFailed=false, policyHelperFailClosed=false
[managedSettings] applied: no bypass restriction in force (managed policy absent)
[managedSettings] applied: bypass-permissions mode DISABLED by enterprise policy
                  (fail-closed: policy could not be determined)
                  — /allow-all and permission escalation are now blocked

The resolver reports source=none, bypassDisabled=false and no failure flag of any kind, and the first applied: line agrees ("no bypass restriction in force"). A second applied: immediately overrides it with the undetermined-policy posture.

The trigger appears to be the pre-auth window: server policy fetch skipped: no authenticated GitHub host available is logged just before, while the CLI still reports Login status unknown. The fetch is not failing — it is skipped because auth has not resolved yet — but it seems to be treated as "policy could not be determined".

There is no managed policy on this account. The managed-settings cache confirms the server answered that there is none:

{"schemaVersion":1,"retrievedAtMs":1788776811105,"account":"<hash>","response":null}

and the same session logs serverResolution=Live.

It is never relaxed. In a full session log the disable is applied 3 times and nothing lifts it — no "relaxed", no "re-enabled". Unlike the MCP interim window, this restriction has no restore path once auth resolves.

Notable asymmetry: non-interactive mode is not affected. copilot -p "..." --yolo runs tools without prompting. Only the interactive startup path ends up with the restriction stuck on.

Likely cause

This area changed in 1.0.81:

"An enterprise managed-settings policy is no longer rejected when permissions.disableBypassPermissionsMode carries an unrecognized value; it is now logged and enforced as disable."

An absent policy looks to be taking the same "unrecognized ⇒ disable" path.

Related

• 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 — same family (interim fail-closed firing on an account with no managed policy), but that one is about MCP server allow lists during the resolve window, and is only reachable from the desktop app. This one is the bypass-permissions/--yolo path and reproduces from a bare terminal invocation.
• Managed settings policy fetch fails closed on valid enum value "enable" for permissions.disableBypassPermissionsMode, blocking ALL local/custom MCP servers #4349 — closed; fail-closed on a valid enum value. Here the policy is absent altogether.

Affected version

1.0.83 (also present in the 1.0.84-0 / 1.0.84-1 prereleases)

Steps to reproduce the behavior

1. Sign in on an account with no enterprise managed policy (~/Library/Caches/copilot/managed-settings/*.json shows "response": null).
2. Start the CLI interactively: copilot --yolo.
3. Observe that permission escalation is blocked.
4. Open the session log in ~/.copilot/logs/process-*.log and see the two contradictory applied: lines quoted above.
5. Grep the same log for any line lifting the restriction later in the session — there is none:

grep -c "bypass-permissions mode DISABLED" ~/.copilot/logs/process-*.log   # 3
grep -iE "relax|re-enabled|restriction lifted" ~/.copilot/logs/process-*.log  # no matches

Counter-check that the flag itself is fine — this one is not blocked and runs the tool without prompting:

copilot -p "Run the shell command 'echo YOLO_OK' and reply with only its output." --yolo

Expected behavior

When the effective policy resolves to source=none with bypassDisabled=false and no failure flags set, bypass-permissions mode must stay enabled, and --yolo must work in interactive mode as it does with -p.

A policy fetch that is skipped pending authentication is not a policy that could not be determined. The restriction should at most be provisional during that window, and must be lifted once auth resolves and the policy comes back absent.

At minimum, the two applied: lines should not be able to disagree about the same resolution — the second one currently wins with the opposite conclusion, 1 ms after the first.

Additional context

• Operating system: macOS
• CPU architecture: ARM (darwin-arm64)
• Node.js: v24.20.0
• Shell: zsh
• No defaultMode / defaultPermissionMode set; ~/.copilot/settings.json contains only showReasoning and model.
• No COPILOT_* permission env vars set (COPILOT_ALLOW_ALL, COPILOT_ASSISTED_APPROVAL both unset).
• --assisted-approval is not in use, so the safety judge is not what is engaging here.

Full startup sequence from ~/.copilot/logs/process-*.log, in order, unedited:

[INFO] [managedSettings] device MDM: no policy present on this device
[INFO] [managedSettings] server policy fetch skipped: no authenticated GitHub host available
[INFO] [managedSettings] effective policy resolved: source=none, bypassDisabled=false, serverFetchFailed=false, policyHelperFailed=false, policyHelperFailClosed=false
[INFO] [managedSettings] applied: no bypass restriction in force (managed policy absent)
[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
[INFO] [managedSettings] self-fetch starting for account (device)
[INFO] [managedSettings] device MDM: no policy present on this device
[INFO] [managedSettings] server policy fetch skipped: no authenticated GitHub host available
[INFO] [managedSettings] effective policy resolved: source=none, bypassDisabled=false, serverFetchFailed=false, policyHelperFailed=false, policyHelperFailClosed=false
[INFO] [managedSettings] applied: no bypass restriction in force (managed policy absent)
[INFO] [managedSettings] self-fetch complete for (device): bypassDisabled=false, serverFetchFailed=false, serverResolution=Live, serverRetryableFailure=false, deviceLoadFailed=false
[INFO] Starting Copilot CLI: 1.0.83
[INFO] Login status unknown

Note that Starting Copilot CLI and Login status unknown come after the restriction has already been applied.

Later in the same session, once the account is authenticated, the policy is confirmed absent again and still nothing lifts the restriction:

[INFO] [managedSettings] self-fetch complete for https://github.com/<user>: bypassDisabled=false, serverFetchFailed=false, serverResolution=FreshCache, serverRetryableFailure=false, deviceLoadFailed=false
[INFO] [managedSettings] effective policy resolved: source=none, bypassDisabled=false, serverFetchFailed=false, policyHelperFailed=false, policyHelperFailClosed=false

[blev8824-ai]

This looks like the effective-policy log and the applied-policy log disagreeing: the first says bypassDisabled=false, serverFetchFailed=false, policyHelperFailed=false, the second says bypass mode is disabled by enterprise policy — yet your account resolves no managed policy. Before the interaction loop itself lifts the restriction, the code path probably re-checks an in-memory (or cached) managed-settings state that was set from an earlier fetch or a default-fail-closed constant, independent of the per-startup fetch. So on THIS start it computes "absent" but somewhere applies a stale/default "disabled". Suggestions: (1) bind the applied bypass resolution to the exact same evaluation object that the log prints (single source of truth — decision and its log should come from the same struct); (2) when bypassDisabled resolves false with no policy and no failure, treat bypass-permissions as allowed and only lock it when either a real policy or a real fetch failure says so; (3) add a state-transition log entry that records WHY bypass got disabled (which branch, what input) so the 1ms contradiction is actually diagnosable. The core symptom — an enforcement decision applied without a matching decision record — is the fail-closed-without-evidence pattern; our runtime binds the decision to the evidence that produced it precisely so a "denied by policy" isn't distinguishable from "denied by default" (https://agentkey.us). Free pre-SOC2. Was the restriction perhaps applied once on an earlier device state and persisted?

[jordanms]

No — it is not persisted state from an earlier device state. Checked on this machine:

• ~/Library/Caches/copilot/managed-settings/*.json → "response": null (server confirms there is no policy).
• ~/.copilot/config.json, settings.json, permissions-config.json → no bypass* key anywhere; grepping every JSON under ~/.copilot for bypass returns nothing.

Still reproduces on 1.0.84-1, and later in the same session, after auth resolves: confirmed no policy served from fresh cache (age 352252ms) from https://github.com → effective policy resolved: source=none, bypassDisabled=false, serverFetchFailed=false — and nothing lifts the restriction.

[blev8824-ai]

Thanks, that rules out persisted state and narrows it to a code-path split: the log resolves source=none, bypassDisabled=false, but the interaction loop still enforces bypass-off, so the applied restriction is being read from a different state than the one being logged. That usually points to a second in-memory managed-settings store(seeded by an earlier fetch or a default-fail-closed constant)that the gate consults independently of this startup's resolution.

Next move: instrument the actual gate that lifts the restriction. Log the resolved bypass value at the branch that denies, plus its source(memcache, fetch, or constant), right when it fires. That one line shows whether it's stale cache or a hardcoded default,and the 1ms contradiction becomes a two-line root cause instead of noise. The cardinal sin here is an enforcement decision applied without a matching decision record; the denial and the evidence that produced it must pair, which is the seam our runtime enforces per tool call: https://agentkey.us. Is the bypass gate maybe two layers(a lazy-loaded settings map + a cold-start default)that can disagree?