GitHub Copilot local sandboxing shipped in public preview on September 23, 2026, restricting what an agent session in the Copilot app can touch on a developer's own machine: files, network access, and credentials. A day earlier, on September 22, GitHub also added OpenTelemetry export for the Copilot app, letting enterprise admins route agent-session traces to their own observability backend. Both features live in the same settings surface, and both landed the same week as a string of other Copilot admin controls, so it's worth being precise about what each one actually does before you touch either.
What shipped in the GitHub Copilot app this week
Local sandboxing is a public preview feature, confirmed as such both in GitHub's changelog entry and on its linked docs page. GitHub describes it plainly: local sandboxing "helps reduce the potential impact of unintended commands by limiting access to files, network resources, and credentials on your machine." It's off by default, so nothing changes for a developer who does nothing.
OpenTelemetry export is a different kind of release. GitHub's OpenTelemetry announcement categorizes it only as "Release," with no GA, preview, or beta label attached. Treat it as shipped, not as generally available, until a docs page says otherwise in plain terms. What it does: the Copilot app now supports OTel configuration through enterprise-managed settings, so admins can point agent-session telemetry at a backend they already run.
Same week, same product, two different maturity levels. That distinction matters when you're deciding what to roll out and what to pilot first.
What local sandboxing actually restricts
Sandboxing works by defining three categories of access, each with its own configuration.
Filesystem
Local sandboxing sorts folders into three lists: additional read/write, additional read-only, and denied. GitHub's configuration reference for local sandboxing spells out the precedence rule: "a more-specific denied folder remains denied when a broader parent folder has read or write access." Nest a sensitive directory inside an otherwise-open project folder and the deny still holds.
Network
Two controls apply here: outbound internet access, and local network access, which covers loopback addresses and local dev servers. An agent session that shouldn't be calling out to arbitrary APIs can be blocked from the open internet while still reaching a dev server running on the same machine.
Credentials
Sandboxing can restrict two credential paths specifically: Git credentials used for authenticated HTTPS operations, and GitHub CLI credentials. An agent that doesn't need to push to a remote or call the CLI on your behalf doesn't need standing access to either.
How to turn it on and set an enterprise floor
1. Turn on sandboxing per project in app settings
Local sandboxing is configured per project inside the Copilot app's settings. Since it's off by default, a developer has to opt in explicitly for a given project before any of the filesystem, network, or credential restrictions apply.
2. Use /sandbox on for an already-running session
For a session that's already active, the /sandbox on and /sandbox off commands take effect right away. GitHub says the commands "create a persistent override for that session and apply it immediately." You don't need to restart the session to change its sandbox state mid-work.
3. Set a managed-settings.json floor that can't be loosened locally
Enterprise admins can set a sandbox policy in managed-settings.json that acts as a floor, not just a default. GitHub states plainly that "the effective policy can be more restrictive when enterprise-managed settings apply," meaning local settings can tighten a sandbox further but can't loosen one an admin has locked in. That's the same pattern GitHub already shipped for enterprise agent permissions on September 9.
4. Know what it doesn't cover
Local sandboxing applies only to sessions running on the machine where the Copilot app is installed. GitHub is explicit about the boundary: "local sandboxing does not apply to cloud sandbox sessions or sessions running on a remote host." If your team runs agent work in GitHub's cloud sandbox environment, this feature says nothing about that session's file, network, or credential access.
How this differs from GitHub's other agent controls
Three GitHub agent-control features shipped inside about two weeks of each other, and they answer three different questions. The September 9 release covers what an agent is allowed to do once it acts: a three-state deny, ask, allow framework for shell commands, file edits, and network domains, non-overridable by local settings, running in the Copilot app, Copilot CLI, and VS Code on Agent Host.
The September 8 JetBrains sandbox preview is a separate, IDE-specific feature covering sandbox enablement, filesystem and network access, proxy settings, and macOS Keychain access, scoped to Copilot running inside JetBrains IDEs only.
Local sandboxing, shipped September 23, is the cross-platform version of that same sandboxing idea, built into the Copilot app itself rather than tied to one IDE. It governs what a session can reach. Whether a given action inside that reach is permitted is the deny/ask/allow layer's job. Neither one substitutes for the other, and a JetBrains team running Copilot needs to track all three surfaces separately.
GitHub isn't the only vendor drawing this kind of line. GitLab's own default for agent tool permissions takes a more permissive starting point: read-only tools default to always allow, write and delete tools default to always ask, adjustable locally at the project or group level. GitHub's sandbox floor runs the other way: local settings tighten it, never loosen it.
What OpenTelemetry export gives an enterprise
OTel export lets an admin configure the telemetry property in managed-settings.json "to enable export and specify the endpoint that will receive the data." Once configured, agent-session traces, model calls and tool use, route to whatever observability backend the endpoint points at. Prompt and response content is excluded by default, so the trace shows what the agent called and when, not what it said.
It's the same configuration file that holds the sandbox floor from the previous section, so an admin already editing managed-settings.json for one feature is one new key away from the other.
What still isn't covered
Local sandboxing is a preview, and GitHub can change its behavior before it graduates. Cloud sandbox sessions remain outside its scope entirely, as noted above, so don't assume turning on local sandboxing protects agent work running on GitHub's own infrastructure.
There's also a live contradiction worth flagging rather than resolving. As of September 26, 2026, GitHub's enterprise-managed-settings reference page states that the telemetry property "is supported for Copilot CLI and VS Code" and shows the GitHub Copilot app as not supported on that same row. The September 22 announcement says the opposite: that the Copilot app now supports OTel configuration through enterprise-managed settings. The two pages disagree, and nothing here says which one is stale. Check both again at configuration time before you route telemetry through an endpoint that's expecting Copilot-app traces.
Admins already have their hands in Copilot's settings this quarter for other reasons. Copilot code review's own admin settings sit in the same general area, and Copilot's Business and Enterprise billing changes take effect October 1. Neither overlaps with sandboxing or OTel directly, but both are reasons to check the whole settings surface on a schedule rather than only when something new ships.
FAQ
Is local sandboxing on by default?
No. GitHub states plainly that "local sandboxing is turned off by default." A developer or admin has to turn it on per project, or activate it for a running session with /sandbox on, before any filesystem, network, or credential restriction applies.
Does local sandboxing cover cloud sandbox sessions?
No. Local sandboxing does not apply to cloud sandbox sessions or to sessions running on a remote host. It only governs sessions running locally, on the machine where the Copilot app itself is installed.
Can a developer override an enterprise-managed sandbox floor?
Not to loosen it. Once an enterprise sets a sandbox policy through managed-settings.json, the effective policy can only get more restrictive from local settings, never less. A developer can tighten their own session further. Undoing a floor an admin has already set isn't an option.
What happens if the OS can't enforce the sandbox policy?
The session fails rather than running unprotected. GitHub's own wording is direct on this point: "if your operating system cannot enforce the requested policy, the sandboxed shell fails with an error rather than running without a sandbox." A sandbox that can't be guaranteed doesn't get silently skipped.