--yolo launch flag swallowed by the pre-auth fail-closed bypass cap, never re-applied once the policy resolves

Describe the bug

On interactive startup the CLI applies the managed-settings fail-closed posture that disables bypass-permissions mode, during the brief pre-auth window before the server policy can be fetched. --yolo / --allow-all are applied inside that window via permissions.setMode({mode:"allow-all", source:"cli_flag"}), so the call is rejected.

Roughly 600 ms later the real policy arrives, the runtime correctly logs that bypass is not restricted, and the cap is lifted. But the launch flag is never re-applied. The session therefore runs with the flag silently inert, and every shell command that falls outside permissions-config.json prompts for the rest of the session.

This is a close relative of #4757, but not the same failure. In #4757 the policy resolves as absent and the restriction is never lifted. Here the policy resolves successfully from the server, the restriction is lifted, and the bug is purely that the cli_flag mode set is not retried afterwards.

Startup log (redacted)

Launched as copilot.exe --resume --yolo on 1.0.83, Windows 11:

19:31:52.530 [managedSettings] device MDM: no policy present on this device
19:31:52.530 [managedSettings] server policy fetch skipped: no authenticated GitHub host available
19:31:52.530 [managedSettings] effective policy resolved: source=none, bypassDisabled=false,
                               serverFetchFailed=false, policyHelperFailed=false, policyHelperFailClosed=false
19:31:52.552 [managedSettings] applied: no bypass restriction in force (managed policy absent)
19:31:52.553 [managedSettings] applied: bypass-permissions mode DISABLED by enterprise policy
                               (fail-closed: policy could not be determined)
                               - /allow-all and permission escalation are now blocked
19:31:53.084 [managed_policy]  managed permission policy now caps bypass-permissions escalation
                               (approve-all, unrestricted paths/URLs) {"bypass_blocked":true}
19:31:53.104 [managedSettings] server policy served from fresh cache (age 2960413ms) for https://github.com:
                               bypassDisabled=false, keys=[model,permissions]
19:31:53.104 [managedSettings] effective policy resolved: source=server, bypassDisabled=false,
                               serverFetchFailed=false, policyHelperFailed=false, policyHelperFailClosed=false
19:31:53.105 [managed_policy]  managed permission policy no longer caps bypass-permissions escalation
                               (approve-all, unrestricted paths/URLs) {"bypass_blocked":false}
19:31:53.105 [managedSettings] applied: no bypass restriction in force
                               (managed policy present but does not disable bypass)

The policy on this account explicitly does not disable bypass (bypassDisabled=false). The block is entirely self-inflicted by the pre-auth window, and it lasts 575 ms, which is long enough to swallow the launch flag.

The same flip-flop repeats on every launch. A second process in the same log shows it again at 19:33:38.437 through 19:33:38.899.

Observed effect

In a session started with --yolo, the event log still records permission.requested for shell commands. Only commands matching the location allowlist in permissions-config.json run unprompted, which is the pre---yolo behaviour. Commands the PowerShell parser cannot statically classify prompt every time, including:

• the call operator, logged as "identifier": "<command with expression as name>"
• multi-line scripts with assignments or loops, where the whole script collapses into a single identifier
• anything with hasWriteFileRedirection: true

Those requests also carry "canOfferSessionApproval": false, so there is not even an "approve for session" escape hatch.

Expected behaviour

Either of:

1. Do not apply the fail-closed cap when the policy is merely undetermined because auth has not resolved yet. server policy fetch skipped: no authenticated GitHub host available is not a failure, and the resolver itself reports serverFetchFailed=false with no failure flag set.
2. Re-apply pending source:"cli_flag" permission modes once the policy resolves and the cap is lifted.

Option 2 alone fixes this report. Option 1 additionally covers #4757.

Version history

This became reachable in 1.0.60: "Enforce bypass permissions policy for --allow-all-tools, --allow-all-paths, and --allow-all-urls flags". Before that the launch flags skipped the policy check, so the startup race was harmless. permissions.disableBypassPermissionsMode itself landed in 1.0.55, and 1.0.81 tightened handling further.

Workaround

Running /allow-all on after the session is up works, because by then bypass_blocked is false. It has to be repeated on every launch.

Environment

• CLI 1.0.83, Windows 11 Enterprise x64
• Corporate-managed device behind a TLS-inspecting proxy, which plausibly widens the pre-auth window
• Account has a server-side managed policy covering [model, permissions] that does not set disableBypassPermissionsMode

Related

• #4757 - same fail-closed posture, but policy absent and never lifted. Closed as completed; the reporter notes it still reproduces on 1.0.84-1.
• #4522 - 1.0.81 forces sandbox while managed policy is undetermined, same undetermined-window class, also Windows.
• #4819 - default model choice fails when org policy loads after CLI load, same race class.
• #4618 - /yolo stops working after the machine wakes from sleep, possibly the same re-resolve path.

Start at permissions.setMode({mode:"allow-all", source:"cli_flag"}) and trace managed-settings policy resolution through the bypass_blocked cap being lifted. Reproduce with --yolo or --allow-all, then verify that commands outside permissions-config.json no longer prompt after the server policy resolves successfully.