Guide
The Task Needed One More Folder. Grant It for This Session, Then Check the Policy.
By Steven Sorensen · 18 Oct 2026

Local sandboxing in GitHub Copilot CLI limits the files sandboxed commands can write to your working directory and a few standard locations, which is what you want until a task needs a sibling repository, a shared fixtures folder or a build output outside your project. This guide covers how to grant that access for the right length of time, how to confirm it took, and what changes when your company manages the sandbox. We reported the change as news in our Oct 13 brief; this page is the how-to you can return to.
- One session: in Copilot CLI v1.0.96 and later,
/add-dirgrants sandboxed commands read and write access to a directory for the current session only. - Every session:
/sandbox configsaves lasting filesystem, network and credential rules to your settings. - Always verify:
/sandbox policyshows the access Copilot will actually enforce, after any managed policy from your organization.
What it is
Before v1.0.96, /add-dir and the sandbox did not agree. A user reported in issue 5076, against v1.0.93, that after /add-dir ../other-folder a sandboxed shell command listing that folder still triggered a permission request, because the folder sat outside the sandbox. The issue was closed at 10:11 AM ET on Friday 9 Oct 2026. The v1.0.96 changelog entry, dated 12 Oct and published to npm at 2:51 PM ET that Monday, says /add-dir now grants sandbox access to added directories for the current session.
So on v1.0.96 or later, adding a directory and sandboxing it are one step. On an older build, sandboxed shell commands are still refused in a folder you added, so update first. As of 10:17 PM ET on Thursday 15 Oct 2026, npm showed latest at v1.0.98 and prerelease at v1.0.99-2, so a current latest install already has the fix.
The three tools answer different questions:
/add-diris for a one off. The Using local sandboxing docs say it grants read and write access to a directory for the current session only, without changing your saved sandbox settings./sandbox configis for access you want every time. Entering/sandboxon its own opens the same interactive settings, with General, Credentials, Filesystem and Network tabs, and your choices are saved so future sessions inherit them./sandbox policyis the check. It prints the effective policy for your current directory, grouped by source, such as user configured paths and dev tools, along with network settings and a Capabilities section. It is the combined result after automatic grants, your settings and managed restrictions, not a copy of your saved file.
How-to
- Check your version. Run the first two commands in the script below. You need v1.0.96 or later for
/add-dirto reach into the sandbox. - Confirm the sandbox is on. In a session, run
/sandbox status. The docs call it the reliable check, because it reflects what the session enforces. - Grant a folder for this session. Run
/add-dirfollowed by the directory path. When the session ends, the grant ends with it, which suits reaching into another checkout for one task. - Read the effective policy. Run
/sandbox policyfrom the directory you will work in, because grants are resolved per directory. Check its Notes for configured paths that could not be included. - Preview one command. Add a command after
policy, as in/sandbox policy npm install, to see the tool access that command would receive without running it. - Promote paths you use daily. Our habit, not a documented rule: start with
/add-dir, and only add a path on the Filesystem tab of/sandbox configonce you notice you grant it every day. That tab takes read and write paths, read only paths and denied paths. - Mask secrets while you are there. Since v1.0.96, the Credentials tab suggests possible environment secrets and lets you add masking hosts before saving. Masking replaces the variable with a placeholder inside sandboxed commands, local MCP servers and language servers, and the sandbox proxy supplies the real value only in HTTPS request headers sent to the hosts you list. The docs say the editor stores only variable names and hosts and never reads or shows the secret. The saved key is
sandbox.credentials.envVarswith aninjectHostslist per variable; use the dialog rather than hand writing it.
# We have not run this script end to end on every platform. Read it before you run it.
# It only prints versions. The sandbox commands run inside a Copilot CLI session.
set -e
copilot --version
npm view @github/copilot dist-tags
# Optional install, left commented. Pick the channel on purpose.
# latest channel, v1.0.98 as of 10:17 PM ET Thu 15 Oct 2026:
# npm install -g @github/copilot@1.0.98
Gotchas
- Session means session. The docs describe
/add-diraccess as current session only with saved settings unchanged. They do not say whether a grant survives a resumed session, so do not count on it; save the path in/sandbox configif you need it every time. - It is read and write, not read only. Grant the narrowest folder that does the job.
- Symbolic links bring their targets. The docs warn that a link added in
/sandbox configalso adds its current target, so check where a link points before you save it. - Missing paths drop out of the report. On Linux, missing denied paths are left out of the
/sandbox policypreview even though they are created before a command launches. Missing read/write and read-only grants are left out of the report too, so check that a configured path exists. If sandboxing is off, the command says so instead of printing a policy. - An inject host is not a network allow. Adding a masking host does not open network access to it, so your network rules must also allow the host.
- Bypass drops masking. Masking only works while sandboxing is on. An approved bypass runs the command outside the sandbox with its ordinary environment.
- Managed policy wins. If you get Copilot through an enterprise owned organization, managed settings form a restrictive baseline. They can require sandboxing, add denied paths and limit which paths users may grant, and the docs say access from
/add-diris still subject to that managed policy. Sources combine in the most restrictive direction, so a required toggle stays on and denied paths from every source add up. Managed values show as locked with a managed label in/sandbox config, and/sandbox policyreflects them. - Bypass is an admin choice. When the policy permits it, a user can run
/sandbox disableto turn sandboxing off for the rest of the current session only. Settingsandbox.allowBypassto false removes that option. Teams that also run Copilot in JetBrains can pair this with the JetBrains MCP startup control we covered on Oct 12.
Recommended AI prompt
Copy this paragraph into ChatGPT, Claude, Gemini, Grok, or whatever AI you use.
Act as my Copilot CLI sandbox reviewer. In Copilot CLI v1.0.96 and later, /add-dir grants a sandboxed session read and write access to a directory for that session only, /sandbox config saves lasting path, network and masked variable rules, and /sandbox policy shows the effective policy after managed restrictions. Ask me which folders outside my project my tasks touch, which API tokens my tools use and whether my company manages Copilot settings. Then tell me which paths to grant per session, which to save, which to deny and which variables to mask, and link the GitHub Docs pages on local sandboxing rather than inventing any keys or command syntax.