Describe the bug
After a long period of no activity (ie 8 hours) the allow-all permissions are dropped. This is not a resumed session - just wake the machine back up and continue using the same cli.
Diagnosis: the session temporarily lost --yolo / allow-all mode.
• At 2026-09-02 14:16:59Z, permissions changed from allow-all to manual .
• Between 14:23:20Z and 14:38:05Z, the CLI generated 137 managed approval requests: 131 reads and 6 shell commands. All were approved.
• At 14:38:26Z, permissions changed back to allow-all ; approval requests then stopped.
• This was not specific to unsafe MCP or subagent tools—the prompts were mostly ordinary file reads.
The reset occurred during a long inactive/resume gap, with no user command recorded. The log does not include process arguments, so it cannot distinguish between resuming the session without --yolo and a Copilot CLI 1.0.83-1 resume bug that dropped the permission mode. If the resumed invocation definitely included --yolo , this is CLI behavior worth reporting.
The recurring hook-telemetry.ps1 five-second timeout is a separate repository-hook issue and did not cause the approval prompts. Use /permissions after resuming to confirm the effective mode; /allow-all restores it immediately.
Stats:
• Version: 1.0.83-1
• Windows environment
• Started/resumed with --yolo
• Permission mode unexpectedly changed from allow-all to manual
• It generated 137 approval prompts until /allow-all restored the mode
• Relevant timestamps: 2026-09-02 14:16:59Z through 14:38:26Z
• Session ID: 592d3c81-8389-480e-90c6-dfb9e296cb6c
Affected version
GitHub Copilot CLI 1.0.83-1
Steps to reproduce the behavior
- Start in --yolo
- Do some things
- Stop doing them and wait several hours (machine hibernates)
- Wake up machine and ask existing CLI (still open) to do something
Expected behavior
yolo mode should be preserved.
Additional context
No response
Describe the bug
After a long period of no activity (ie 8 hours) the allow-all permissions are dropped. This is not a resumed session - just wake the machine back up and continue using the same cli.
Diagnosis: the session temporarily lost --yolo / allow-all mode.
• At 2026-09-02 14:16:59Z, permissions changed from allow-all to manual .
• Between 14:23:20Z and 14:38:05Z, the CLI generated 137 managed approval requests: 131 reads and 6 shell commands. All were approved.
• At 14:38:26Z, permissions changed back to allow-all ; approval requests then stopped.
• This was not specific to unsafe MCP or subagent tools—the prompts were mostly ordinary file reads.
The reset occurred during a long inactive/resume gap, with no user command recorded. The log does not include process arguments, so it cannot distinguish between resuming the session without --yolo and a Copilot CLI 1.0.83-1 resume bug that dropped the permission mode. If the resumed invocation definitely included --yolo , this is CLI behavior worth reporting.
The recurring hook-telemetry.ps1 five-second timeout is a separate repository-hook issue and did not cause the approval prompts. Use /permissions after resuming to confirm the effective mode; /allow-all restores it immediately.
Stats:
• Version: 1.0.83-1
• Windows environment
• Started/resumed with --yolo
• Permission mode unexpectedly changed from allow-all to manual
• It generated 137 approval prompts until /allow-all restored the mode
• Relevant timestamps: 2026-09-02 14:16:59Z through 14:38:26Z
• Session ID: 592d3c81-8389-480e-90c6-dfb9e296cb6c
Affected version
GitHub Copilot CLI 1.0.83-1
Steps to reproduce the behavior
Expected behavior
yolo mode should be preserved.
Additional context
No response