If you're nervous about letting an agent run shell commands, that's healthy. GitHub Copilot CLI permissions are the difference between a useful terminal assistant and a tool that can accidentally act with more authority than you intended. The GitHub Copilot CLI permissions model is not complicated, but you need to understand the layers: trusted directories, tool approvals, path checks, URL checks, hooks, secret redaction, and sandboxing.
Heads up: GitHub Copilot CLI moves fast. It went GA in February 2026 and ships updates constantly, so commands, flags, and available models change often. Everything here was verified against the CLI as of July 2026 -- always check the official GitHub Copilot CLI docs for the very latest.
This is a MOFU trust-and-safety guide. I’m not trying to convince you to hand your machine to an agent and hope for the best. I’m showing you how to evaluate the permission surface so you can decide when Copilot CLI is safe enough for your workflow, when it needs tighter constraints, and when you should move the work into a sandbox.
GitHub Copilot CLI Permissions Start With Trusting The Directory
The first boundary in GitHub Copilot CLI permissions is not a flag. It is where you launch the CLI.
GitHub’s configuration documentation says trusted directories control where Copilot CLI can read, modify, and execute files. When you start a session, the CLI asks whether you trust the files in the current directory and below it. You can trust the directory for the current session only, or for this and future sessions. The permanent trust list lives in the automatically managed config.json under your Copilot home directory, such as $HOME.copilotconfig.json on Windows.
That prompt matters because a coding agent is not just reading your prompt. It can inspect project files, run commands, and edit content when you approve those actions. If you start it from your home directory, the blast radius is too broad. If you start it from a repo that contains secrets, scripts you don’t trust, or generated files you don’t understand, the risk goes up.
A practical habit is simple: launch Copilot CLI from the smallest repository folder that contains the work. Not your user profile. Not a parent folder with ten unrelated repos. Not a directory that mixes code, exports, credentials, and personal files.
When the agent needs access outside the current working directory, use an explicit directory grant instead of widening everything. In an interactive session, /add-dir PATH adds a directory to the allowed list for file access. In programmatic mode, --add-dir=DIRECTORY does the same kind of targeted expansion.
# Run from the repo root, but grant one sibling docs folder explicitly.
copilot -p "Update the API examples using the shared docs folder as reference"
--add-dir=..shared-docs
--allow-tool='read'
That example shows the permission mindset I prefer: start narrow, add what is needed, and make the extra access visible in the command. For teams already thinking about agent design and tool boundaries, this maps closely to the broader patterns behind Microsoft Agent Framework in C#, where the agent’s workspace and tools shape its behavior.
One caution: GitHub documents path scoping as heuristic in some cases, especially for shell commands. That means trusted directories and path checks are important guardrails, but they are not a cryptographic security boundary. GitHub Copilot CLI permissions reduce accidental overreach. They do not replace operating system permissions, containers, virtual machines, or sandboxing.
GitHub Copilot CLI Permissions For Tools: Yes, Session Approval, Or No
The second boundary is tool approval. This is the one developers usually notice first.
When Copilot CLI wants to use a tool that may modify or execute files, GitHub documents a three-choice approval UI:
YesYes, and approve TOOL for the rest of the running sessionNo, and tell Copilot what to do differently (Esc)
Use the first option when you want to approve a specific action once. Use the third option when the command is wrong, too broad, or headed in the wrong direction. The interesting one is the second option. It approves the tool for the rest of the currently running session.
That can be convenient, but it is broader than many people assume. GitHub’s docs call out the rm example directly: if Copilot asks to run rm ./this-file.txt and you approve rm for the session, it can later run any rm command in that session, including something much more destructive like rm -rf ./*, without asking again.
That does not mean Copilot is trying to be dangerous. It means blanket tool approval changes the control model. You are no longer approving a command. You are approving a tool category for the session.
For GitHub Copilot CLI permissions, my default posture is:
- approve one-off shell commands when I want to inspect the exact command;
- approve low-risk read-only commands for the session when they are repetitive;
- avoid session-wide approval for destructive commands like
rm,git reset,git clean, deploy scripts, database clients, and credential-management commands; - reject and redirect when the agent reaches for a tool that is technically possible but operationally risky.
This is the same engineering judgment we use with human workflows, and it lines up with the broader agent-evaluation mindset in evaluating AI agents with Microsoft.Extensions.AI.Evaluation in C#. You might let a teammate run tests freely. You probably don’t want a broad, unreviewed path to delete files, push branches, or mutate production data.
Allow And Deny Flags For Copilot CLI Safety
For non-interactive use, or for interactive sessions where you want explicit startup policy, GitHub Copilot CLI permissions can be configured with command-line flags. The core taxonomy verified against the live programmatic and configuration docs is:
--allow-tool=TOOL--deny-tool=TOOL--allow-all-tools--allow-all--yolo--allow-all-paths--allow-all-urls--allow-url=URL--deny-url=URL--secret-env-vars=VAR
The big rule is that deny wins. GitHub documents that --deny-tool takes precedence over both --allow-tool and --allow-all-tools. That makes a useful pattern possible: allow a broad set for a controlled workflow, then deny specific foot-guns.
# Let Copilot run tools, but block risky shell operations.
copilot -p "Inspect this branch and summarize what changed"
--allow-all-tools
--deny-tool='shell(rm)'
--deny-tool='shell(git push)'
--deny-tool='shell(git clean)'
This is not risk-free. --allow-all-tools still skips manual approval for tools. But it is materially better than allowing everything with no exceptions when you already know specific operations should never happen in that workflow.
For tighter copilot cli safety, prefer exact or narrow approvals. The docs show that shell(COMMAND) controls shell command execution. They also document examples like shell(git push) for first-level git and gh subcommands, and the programmatic reference includes filters such as shell(npm test) or shell(git:*).
# A narrower policy for a test-focused .NET task.
copilot -p "Find the failing unit test, explain the cause, and propose a fix"
--allow-tool='read'
--allow-tool='shell(dotnet test)'
--deny-tool='shell(git push)'
--no-ask-user
That command is a better fit for a CI diagnostic or local read-heavy investigation than --allow-all-tools. It allows reading and one validation command, while explicitly denying a push. If the task needs edits later, that should be a separate decision.
The broadest flags are --allow-all and --yolo. GitHub documents them as equivalent aliases that combine --allow-all-tools, --allow-all-paths, and --allow-all-urls. In an interactive session, /allow-all and /yolo can enable the same all-permissions posture, unless blocked by enterprise policy.
I would treat --allow-all and --yolo as high-trust, high-blast-radius switches. They are useful for disposable sandboxes, throwaway prototypes, and controlled automation where the environment is already isolated. They are not the first flag I would reach for in a real repository with credentials, deploy scripts, or production-adjacent tooling.
Path Permissions: What Copilot CLI Can Read Or Write
Tool permissions answer “what can run?” Path permissions answer “where can it operate?” Both are part of GitHub Copilot CLI permissions.
By default, GitHub documents that Copilot CLI can access the current working directory, its subdirectories, and the system temp directory. Path permissions apply to shell commands, file operations such as create, edit, and view, and search tools such as grep and glob patterns. For shell commands, Copilot heuristically extracts paths by tokenizing command text and identifying path-looking tokens.
There are two main ways to expand path access:
- use
/add-dir PATHor--add-dir=DIRECTORYfor specific additional directories; - use
--allow-all-pathsto disable path verification entirely.
Those are very different choices. --add-dir is targeted. --allow-all-paths says path restrictions are not needed for this run.
# Targeted path expansion is usually safer than disabling path checks.
copilot -p "Compare this repo's package metadata with the shared release checklist"
--add-dir=..
elease-checklists
--allow-tool='read'
# Use this only when path restrictions are intentionally unnecessary.
copilot -p "Audit generated files across my workspace"
--allow-all-paths
The first command is easier to reason about. The second may be valid in a dedicated workspace, but it is not what I would run from a personal directory or a repo with unrelated sibling folders.
GitHub also documents --disallow-temp-dir if you want to remove default access to the temp directory. That is a useful hardening option in workflows where temp files could contain sensitive material or where you want all agent-visible data to stay inside the repo boundary.
The practical decision is about blast radius. If an agent makes a mistake, what files can it touch? If the answer includes unrelated repositories, secrets, exports, or local-only scratch work, tighten the path boundary before you ask it to operate.
URL Permissions And Network Access
GitHub Copilot CLI permissions also include URL access. By default, GitHub documents that all URLs require approval before access is granted. URL permissions apply to the web_fetch tool and to a curated list of network-capable shell commands such as curl, wget, and fetch. URLs in shell commands are detected with regex patterns, and GitHub documents limitations around obfuscated URLs, config-file URLs, environment-variable URLs, and protocol differences between HTTP and HTTPS.
That gives you three practical controls:
--allow-url=DOMAINor URL pattern to pre-approve known endpoints;--deny-url=DOMAINto block known endpoints;--allow-all-urlsto disable URL verification.
# Let the agent read official docs, but do not give broad network access.
copilot -p "Check the current Copilot CLI permission flags and summarize changes"
--allow-url=docs.github.com
--allow-url=github.blog
--deny-url=internal.example.com
This matters for more than browsing docs. Network access can leak context if a tool sends data somewhere unexpected. It can also make a run less reproducible if the agent pulls changing external content. For research tasks, pre-approving official domains is usually reasonable. For source-code edits, especially in enterprise repositories, URL access should be intentional.
PreToolUse Hooks For Policy Enforcement
Flags are startup policy. Hooks are runtime policy.
GitHub’s hooks documentation describes hooks as JSON-configured shell commands that run at key points in agent execution. They are supported by Copilot cloud agent and GitHub Copilot CLI. The preToolUse hook is the most relevant for permissions because it runs before the agent uses a tool and can approve or deny tool executions.
That makes preToolUse useful when your team has rules that are too specific for a command-line flag. For example, you might want to block git push, block database clients, prevent edits under a generated-code folder, or require a security scan before a write.
Repository hooks live under .github/hooks/*.json. Personal Copilot CLI hooks can live under ~/.copilot/hooks/*.json. A minimal preToolUse hook points at a short policy script with a timeout, usually in both PowerShell and bash for cross-platform teams. Keep hook scripts small and deterministic. GitHub’s hook guidance warns that hooks run synchronously and block agent execution, so long-running policy scripts can make the CLI feel broken.
Hooks should also be treated as security-sensitive code. They process agent action metadata as input. Validate that input, avoid unsafe shell construction, do not log secrets, and set timeouts. A hook that is supposed to enforce policy but is itself injectable is just another risk surface.
This is the right place to encode organizational rules without relying on every developer to remember the same prompt wording. If a repo has a “no production database writes” rule, a “never push from an agent” rule, or a “generated files are read-only” rule, a preToolUse hook gives you a practical enforcement point.
Sandboxing: Local And Cloud Isolation
Sandboxing is the answer when GitHub Copilot CLI permissions are not enough by themselves.
As of July 2026, GitHub’s live docs still mark cloud and local sandboxes for GitHub Copilot as public preview and subject to change. That preview label matters. I would use the feature, but I would not present it as a settled compliance boundary without verifying the current behavior for your organization, operating system, and installed CLI build.
The documented local sandbox entry point is /sandbox enable inside a Copilot CLI session. GitHub describes it as restricting Copilot’s access to your filesystem, network, and system capabilities. The documented cloud sandbox entry point is copilot --cloud, and GitHub describes cloud sandboxes as isolated, cloud-hosted Linux environments. Because this is preview functionality, check your own copilot --help, /experimental, and organization policy before making it part of a required workflow.
Cloud sandboxes can be useful when you want code to run away from your local machine, preserve session state between uses, continue from another machine, or run multiple tasks in parallel. GitHub also notes that cloud sandbox policies inherit from Copilot cloud agent policies.
The tradeoff is straightforward. Local work is fast, familiar, and close to your environment. Cloud sandboxing gives you more isolation from your machine, but you need to understand what code and context are being moved into the cloud environment and what enterprise policies apply.
For sensitive work, I like a layered approach: narrow trusted directory, narrow tools, narrow paths, URL restrictions, preToolUse policy, secret redaction, and a sandbox when execution risk is high. No single layer is perfect. Multiple layers reduce the chance that one mistake becomes a major incident.
Secret Redaction With --secret-env-vars
Secrets are a separate part of copilot cli safety because they can leak through logs, transcripts, tool output, and pasted context.
The programmatic reference documents --secret-env-vars=VAR for environment variables whose values you want redacted in output. It also says values in GITHUB_TOKEN and COPILOT_GITHUB_TOKEN are redacted by default. Use this when you are running Copilot CLI in scripts, CI, or any workflow where command output could become an artifact.
# Redact custom secrets from agent output and transcripts.
copilot -p "Summarize why the deployment smoke test failed"
--allow-tool='read'
--secret-env-vars='AZURE_CLIENT_SECRET,DATABASE_URL,STRIPE_API_KEY'
Redaction is not permission to be casual with secrets. Do not paste credentials into prompts. Do not give the agent more environment variables than it needs. Be careful with --share and --share-gist, because GitHub’s programmatic reference notes that transcripts may contain sensitive information.
A Practical Permission Profile For Nervous Developers
If you are just starting with GitHub Copilot CLI permissions, do not start with Autopilot plus --yolo. Start with a boring, reviewable profile.
Use Standard or Plan mode. Launch from the repo root. Trust the directory for the session first, not permanently, until you are comfortable. Approve one command at a time. Let the agent read and inspect freely only when the repo does not contain sensitive files. Require it to explain before it edits. Ask it to run tests only after you understand the command.
For a safer first workflow, use prompts like this:
copilot -p "Inspect this repository and explain the permission-sensitive commands you would need before making changes. Do not edit files."
--allow-tool='read'
--deny-tool='shell(rm)'
--deny-tool='shell(git push)'
--no-ask-user
That gets you value without immediately handing over write access. Once you trust the workflow, you can add --allow-tool='write' or a specific test command for bounded implementation tasks.
The decision framework I use is simple. If the command can destroy data, publish something, rotate credentials, charge money, mutate production, or push code, do not blanket-approve it. If the command reads local project files or runs a deterministic test suite, approval is usually lower risk. If the environment is disposable, broader flags are more acceptable. If the environment is your real workstation with real credentials, tighten the model.
This is also why agentic terminal work benefits from strong repo instructions and validation loops. The CLI can help you move faster, but the engineering bar does not move. You still need tests, reviews, and operational boundaries. If you are building similar tooling yourself, Build an AI CLI Developer Tool with GitHub Copilot SDK in C# is a useful companion for thinking about tool design from the builder side.
What This Article Is Not Covering In Depth
I’m intentionally keeping three adjacent areas shallow here: MCP-specific permissions, full headless automation design, and custom-agent tool scoping. They all touch GitHub Copilot CLI permissions, but each needs its own treatment. For MCP background, start with building MCP servers and clients in C# rather than trying to squeeze that whole topic into a permission-model article.
FAQ
What are GitHub Copilot CLI permissions?
GitHub Copilot CLI permissions are the controls that determine what the agent can access and do: trusted directories, tool approvals, path permissions, URL permissions, sandboxing, hooks, and secret redaction. The goal is visible, intentional authority.
Should I approve a tool for the whole session?
Sometimes, but be selective. Session approval is reasonable for repetitive low-risk tools. It is risky for destructive tools. If you approve rm for a session, GitHub documents that other rm commands can run without another prompt.
Is --yolo the same as --allow-all?
Yes. GitHub documents --allow-all and --yolo as aliases combining --allow-all-tools, --allow-all-paths, and --allow-all-urls. Convenient in a disposable sandbox, broad on a real workstation.
Does --deny-tool='shell(rm)' block every dangerous command?
No. It blocks rm according to the documented tool filter, and deny rules take precedence over allow rules. It does not identify every dangerous operation. Higher-risk work still needs policy, review, and sandboxing.
Are trusted directories a complete security boundary?
No. GitHub describes some scoping as heuristic and warns that protection outside trusted directories is not guaranteed in every case. Treat trusted directories as a safety layer, not a complete boundary.
When should I use local or cloud sandboxing?
Use sandboxing when execution risk is too high for your normal machine. GitHub documents /sandbox enable for local sandboxing and copilot --cloud for cloud sandboxing, but as of July 2026 both are public preview. Verify availability in your installed CLI and organization policy before relying on either one.
How do I keep secrets out of Copilot CLI output?
Do not put secrets into prompts or unnecessary environment variables. For scripted runs, use --secret-env-vars to redact custom secret values. GitHub documents that GITHUB_TOKEN and COPILOT_GITHUB_TOKEN are redacted by default.
Wrapping Up: Use The Smallest Permission That Gets The Job Done
The safest way to think about GitHub Copilot CLI permissions is not “agent or no agent.” It is “what specific authority does this task need?”
A documentation lookup may need read access and a couple of official URLs. A test investigation may need read and shell(dotnet test). A refactor may need write, a targeted test command, and denied pushes. A risky prototype may belong in /sandbox enable or copilot --cloud. A high-trust disposable environment may justify --allow-all or --yolo, but that should be a deliberate choice.
For a developer nervous about shell commands, that is the key takeaway: you do not have to choose between total refusal and total trust. GitHub Copilot CLI permissions give you a graduated model. Use it. Keep the blast radius small, make risky commands explicit, and review the work like you would review any other code change.