Repository navigation
Add sandbox mode to restrict Copilot CLI file access to a specified working directory #892
Description
Describe the feature or problem you'd like to solve
Please add a sandbox capability to copilot-cli that constrains the code agent’s filesystem permissions so it can only read/write within a specified working directory (workspace root), and is prevented from accessing or modifying any paths outside that directory. This should be similar in spirit to the sandbox/workspace isolation provided by tools like Codex and Claude Code.
Proposed solution
- Add an opt-in flag and/or config, e.g. --sandbox, --workspace , or sandbox=true
- When enabled:
- All file reads/writes are allowed only under the workspace root (including subdirectories)
- Block path traversal (..), absolute paths, and symlink escapes that would resolve outside the workspace, with a clear error message
- (Optional) Support an allowlist for explicitly permitted additional directories (e.g., temp/cache)
Example prompts or workflows
No response
Activity
qin-guan commentedon Jan 28, 2026
It would be great to have this feature or more documentation from the team about the guardrails available currently to prevent errant LLM access / privileges 🧐 especially when similar products (Codex/CC) have them as well. It is a little unsettling that Copilot has access to my entire drive
rexxiang commentedon Mar 12, 2026
Just checking, any updates on this?
real-or-random commentedon Mar 12, 2026
As for external projects, there's https://github.com/GordonBeeming/copilot_here and https://www.docker.com/products/docker-sandboxes/ but the latter doesn't work on Linux.
mpostelnicu commentedon Apr 1, 2026
any plan to implement this? both gemini cli and claude code support sandboxing. it would be great to have this in copilot too.
Starefossen commentedon Apr 11, 2026
We built cplt to address this. It wraps Copilot CLI in a macOS Seatbelt sandbox (
sandbox-exec) with deny-by-default filesystem rules, enforced by the kernel.What it restricts:
.envfiles blockedbrew install navikt/tap/cplt && cplt --shell-install— then typingcopilotruns the sandboxed version.macOS only (Seatbelt is a kernel feature). Would still love to see this built into Copilot CLI natively for cross-platform support.
JohnLudlow commentedon Apr 13, 2026
What's the plan for those on Windows or Linux?
Starefossen commentedon Apr 13, 2026
For
cpltI do not have a good solution (yet) for Windowns or Linux. Suggestions are welcome.alexwaibel commentedon May 15, 2026
The safety situation with github CLI is very odd. To the best of my knowledge features like sandboxing are only available in vs code: https://code.visualstudio.com/docs/copilot/security#_agent-sandboxing-preview
Coming from Claude Code, this is a pretty big gap. I make use of the claude tool allow/deny list and sandboxing quite a bit so it makes GitHub Copilot a bit frustrating to use by comparison. Of course there are workarounds to each, like using docker for sandboxing and wrapping the copilot CLI in a script or alias that adds all the tool allow/deny args, but that's way less ergonomic than setting some json settings once.
My ideal scenario is that I can set these kinds of things once and vs code, copilot cli, and other tools that use copilot agents all respect them. Ideally using a normal config pattern where for example tool calls can be set at a user level and then extended at a project level.
cosmaioan commentedon May 22, 2026
I use vscode insiders .... when trying to handover to github cli from vscode .... I run that the cli launch cannot access my temp folder.
my temp folder is set to R:\Temp
So the integration is not working for me
magodo commentedon Jun 3, 2026
There is an announcement of local sandbox: https://github.blog/changelog/2026-06-02-cloud-and-local-sandboxes-for-github-copilot-now-in-public-preview/. Whilst I notice it doesn't work as expected: #3653.
caarlos0 commentedon Jun 11, 2026
Hey!
We now have a local sandboxes - which you can enable with
/sandbox enable. You can then use/sandboxto customize your policy (add more dirs, etc).This is still experimental, so you might need to enable experimental mode or set the
SANDBOX=trueenvironment variable.docs
magodo commentedon Jun 11, 2026
@caarlos0 The doc is quite brief about the actual behavior. E.g. when I enable sandbox for the FS, it seems by default everything is rw, unless I explicitly specify some paths to be ro/deny (and the denied path ends up with ENOENT on Linux). Is there a plan to enhance the document for the detailed behaviors?