Repository navigation
Trusted folders silently auto-approve shell execution in manual mode, even for commands with unpredictable side effects (scripts, sqlcmd, curl) #5232
Description
Describe the bug
In manual permission mode, any shell command whose referenced file paths all lie inside a trusted folder is executed without any permission prompt. Path-based gating cannot determine what a command will actually do.
Concretely: the agent ran
powershell.exe -NoProfile -ExecutionPolicy Bypass -File scripts\someScript.ps1
from inside a trusted folder. The session event log contains no permission.requested event for this execution - it went straight from tool request to execution.
Affected version
GitHub Copilot CLI 1.0.102.
Steps to reproduce the behavior
- Add a folder to
trustedFoldersin~/.copilot/config.json(or accept the trust prompt with the persistent option). - Start a session in that folder with permission mode
manual. - Ask the agent to run any script in the folder, e.g. a
.ps1that connects to a local database or the network. - Observe: the command executes immediately;
events.jsonlcontains atool.execution_startbut nopermission.requestedevent.
Expected behavior
In manual mode, shell command execution should require approval regardless of folder trust.
At minimum, provide a setting that decouples the two, e.g. "trustedFolderAutoApprovesShell": false, so users can keep folder trust while retaining per-command prompts.
However, neither pure path-based nor pure command-based gating is sufficient on its own. Suggested combination, evaluated in order:
- A built-in read-only tier: provably side-effect-free commands (
git show,git log,Get-Content,ls, ...) never prompt, regardless of path or folder. - Per-folder command-pattern rules:
(folder, command-pattern) -> allow | ask | deny, persisted via the existing per-folder structure ofpermissions-config.jsonand populated through the familiar "allow always (for this folder) / allow for session / deny" prompt choices. - Unclassifiable executions default to ask: invoking scripts or interpreters (
powershell -File *.ps1,cmd /c,bash,python), database clients (sqlcmd,psql), service control (systemctl,Stop-Service), and network tools (curl,Invoke-WebRequestto URLs outside allowedUrls) always prompt unless explicitly allowlisted for that folder — their effect cannot be predicted from the command line.
Prior art: Claude Code uses per-command-pattern allow/ask/deny rules (folder trust does not grant execution); Codex CLI pairs auto-approval with OS-level sandboxing (network off, writes confined to the workspace) so unpredicted effects fail instead of succeeding silently; JetBrains Junie and VS Code agent mode prompt per terminal command with allowlists. Copilot CLI's "trusted folder implies unprompted shell" is the outlier among these.
Additional context
Environment
- Copilot CLI 1.0.83 through 1.0.101 (long-lived session, behavior identical across versions)
- Windows, PowerShell tool
- permissionMode:
manual, agentMode:interactive - No entries for the folder in
permissions-config.json; no/allow-all; no launch flags
Activity
samvallad33 commentedon Oct 22, 2026
Hi Philipp,
What did someScript.ps1 actually touch when it ran, the local database or something out on the network?
The part of your report that stuck with me is events.jsonl showing a tool.execution_start with no permission.requested anywhere before it. You had manual mode set, nothing for that folder in permissions-config.json and no allow-all, yet trusting the folder once quietly became a standing yes for any script launched from inside it, even one started with ExecutionPolicy Bypass. Folder trust says where a command lives, not what it will do, so your idea of having interpreters, database clients and network tools always ask unless they are allowlisted for that folder feels like the right line to me. Until there is a setting for it, have you pulled that folder back out of trustedFolders?
Sam
ph-preis commentedon Oct 22, 2026
The script connects to the local MSSQL server instance (using Windows authentication), and it created a new database there.
No damage was caused as the script is non-destructive, but it was highly unexpected to me that copilot-cli allowed to run this script without requiring confirmation from me.
The LLM (I believe it was Claude) also did not catch this on its own, and just ran the command.
The only safe solution for now would indeed be to remove the "trusted folder" setting. But that reduces usability. For now I just added a comment for the LLM in copilot-instructions.md to always ask before running any script (but such instructions can be ignored, so this is not a fix).
Maybe the easiest fix for now would be to require confirmation for executing any script file with powershell/cmd/bash etc., even when the script file is located in trusted folders.