Guide

The Task Needed One More Folder. Grant It for This Session, Then Check the Policy.

By · 18 Oct 2026

Guide illustration for “The Task Needed One More Folder. Grant It for This Session, Then Check the Policy.”

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-dir grants sandboxed commands read and write access to a directory for the current session only.
  • Every session: /sandbox config saves lasting filesystem, network and credential rules to your settings.
  • Always verify: /sandbox policy shows 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-dir is 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 config is for access you want every time. Entering /sandbox on 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 policy is 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

  1. Check your version. Run the first two commands in the script below. You need v1.0.96 or later for /add-dir to reach into the sandbox.
  2. 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.
  3. Grant a folder for this session. Run /add-dir followed by the directory path. When the session ends, the grant ends with it, which suits reaching into another checkout for one task.
  4. Read the effective policy. Run /sandbox policy from the directory you will work in, because grants are resolved per directory. Check its Notes for configured paths that could not be included.
  5. 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.
  6. 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 config once you notice you grant it every day. That tab takes read and write paths, read only paths and denied paths.
  7. 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.envVars with an injectHosts list 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-dir access 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 config if 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 config also 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 policy preview 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-dir is 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 policy reflects them.
  • Bypass is an admin choice. When the policy permits it, a user can run /sandbox disable to turn sandboxing off for the rest of the current session only. Setting sandbox.allowBypass to 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.

Prompt

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.