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:
- 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.
- 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
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-allare applied inside that window viapermissions.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.jsonprompts 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_flagmode set is not retried afterwards.Startup log (redacted)
Launched as
copilot.exe --resume --yoloon 1.0.83, Windows 11: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 recordspermission.requestedfor shell commands. Only commands matching the location allowlist inpermissions-config.jsonrun unprompted, which is the pre---yolobehaviour. Commands the PowerShell parser cannot statically classify prompt every time, including:"identifier": "<command with expression as name>"hasWriteFileRedirection: trueThose requests also carry
"canOfferSessionApproval": false, so there is not even an "approve for session" escape hatch.Expected behaviour
Either of:
server policy fetch skipped: no authenticated GitHub host availableis not a failure, and the resolver itself reportsserverFetchFailed=falsewith no failure flag set.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-urlsflags". Before that the launch flags skipped the policy check, so the startup race was harmless.permissions.disableBypassPermissionsModeitself landed in 1.0.55, and 1.0.81 tightened handling further.Workaround
Running
/allow-all onafter the session is up works, because by thenbypass_blockedis false. It has to be repeated on every launch.Environment
[model, permissions]that does not setdisableBypassPermissionsModeRelated
--yolo/--allow-allblocked for the whole session by a fail-closed bypass restriction applied on an account with NO managed policy #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./yolono longer works; have to approve every request until I restart session #4618 -/yolostops working after the machine wakes from sleep, possibly the same re-resolve path.