GitHub Copilot: Local sandbox available, how it limits files, network and credentials

GitHub Copilot's local sandbox limits the perimeter where the agent's tools can operate; it does not mean that the model is automatically local. General availability announced on October 7, 2026 is about Copilot CLI, the app and Agent Host in VS Code in the supported paths. The date and products involved are reported in the GitHub changelog.

For an SME developing software or entrusting changes to an assistant, the point is to make objective and access consistent. An agent tasked with correcting a component does not necessarily need to read all computer folders, use any credential, or reach every destination. The technical perimeter must reflect the assigned work, with proof that it also verifies forbidden accesses.

What controls does GitHub describe for the local sandbox?

The GitHub documentation on cloud and local sandboxes describes MXC technology on Windows, macOS, and Linux to limit tools, files, network, and credentials, with organizational policies where supported. The concrete behavior depends on the client and the path used. The name of the function is not enough to establish that every tool opened on the computer is included in the same boundary.

The project must then identify where the agent is running and which commands cross the sandbox. Even the organizational configuration should be read in its perimeter, without attributing it a universal effect on different clients or modes. A policy is useful when the team knows who it applies to and can observe what happens in front of an unauthorized access.

The announcement indicates that the function is included at no additional cost, while the Copilot plan retains its own conditions: the reference is the official release. This does not make the entire development environment or the work necessary to configure and maintain it free of charge.

Are authorization of action and isolation the same thing?

A request for permission asks if an operation can be performed. The sandbox limits the resources attainable by the process. If the approved operation is performed in a too large environment, it can have unnecessary access even when the initial intent is correct. If the perimeter is too narrow, the task may freeze. The controls must therefore be consistent, not interchangeable.

The team must avoid vague approvals, such as access to the entire computer to solve a single block. The exception should relate to a recognizable need and maintain the project boundary. Otherwise, the configuration loses meaning just during the most difficult tasks, when the agent encounters unexpected data or commands.

What folders should a development agent be able to read?

The starting point is the task repository and what it really takes to run it. Other customers' folders, personal documents, and administrative archives are not automatically relevant. Even within the project there may be files that require different management, such as production data or exported material for diagnosis. Availability on disk is not equivalent to a read permission.

The team should create a simple map: sources, tests, dependencies, and results generated. Each area has a purpose. An agent that needs to modify the interface may need the components and tests, but not a complete archive of customer data. Preparing an environment with minimized input makes it easier to verify accesses and errors without exposing foreign material.

The Guide on AI and Data Security connects this perimeter to the business process. The control must include the result: generated files, logs and screenshots can contain information from the environment. Limiting reading is useful, but you also need to know where the outcomes are saved and who can consult them.

How to delimit network and credentials for code work?

Development may require access to dependencies, documentation, and testing services. It doesn't mean the process has to use production credentials or reach any endpoint. The company should choose dedicated accounts and test environments, leaving authorized people with external effects. A key available to the process can extend its power beyond the repository files.

Network destinations should be motivated with respect to the task. When a command attempts to reach a new service, the team verifies what it is doing and why. It is not advisable to approve a wide aperture only to eliminate an installation error or a failed test. First you read the outcome, then you decide whether the need is legitimate and proportionate.

The theme links to Claude Managed Agents network restrictions, which concern another product and a different environment. The common principle is to document the actual boundary; the settings do not automatically transfer from one system to another.

Can a software house work on a proprietary CRM?

Hypothetical scenario. An Italian software house uses Copilot to prepare a change to a customer's CRM search. The environment contains minimized sources and test data, while the production database remains out of mandate. The agent proposes the code, performs the authorized checks and returns a diff. Review and release maintain the team's planned process.

The pilot checks that the agent can read the affected component and does not access a foreign folder. You also test a command that requires an unexpected destination, using harmless material and a test environment. The goal is not to demonstrate invulnerability, but to gather evidence that the configuration respects the boundaries chosen for that path.

The manager checks that the tests do not require real credentials for convenience. If the project depends on an external service, an appropriate test mode is prepared or that step is left to the authorized procedure. The assistant can reduce repetitive work without becoming the point where all customer access is collected.

Can an e-commerce agent be entrusted with a theme change?

Second hypothetical scenario. An SME wants to correct the filter of a category in its e-commerce. The task is about code and dummy data, with a separate preview from the live store. The agent does not automatically have the orders panel or permissions to publish. The sandbox is configured around the repository and the tools needed for local verification.

The test includes reading the expected files, writing to the assigned component, and generating test results. It is checked that an error does not prompt the agent to use a different folder or an already open administrative session. The operator must be able to understand why a request for additional access is necessary before granting it.

The value is measured on the correct and verified modification. The speed at which a diff is produced is not enough: you need behavior in preview, absence of relevant regressions and a readable release path. The sandbox limits some operational possibilities, while the quality of the result still requires interface review and testing.

Does local sandbox mean you can work offline?

No: Local isolation and place of execution of the model are different plans. The novelty on Ollama models in the Copilot CLI addresses local model detection and explicit offline mode. You must not attribute that function to the sandbox or assume that isolation alone prevents any network connection.

The distinction helps to choose the configuration by reserved code. The team needs to know which model receives the content, where the tools spin and which data comes out of the environment. A complete response requires reading provider, authentication, network, and client settings. A single label as a locale does not describe the entire route.

The Guide to Copilot AI It also helps to distinguish GitHub Copilot from products with the same name aimed at other tasks. In this article the context is software development. The conditions of an assistant for business documents should not be automatically transferred to an agent running tools in the repository.

What to try before extending the configuration to the team?

Testing must verify permitted and prohibited routes with harmless files. Read, write, network, and use of credentials in the supported path are observed. The person in charge also controls the request for exception and behavior after a rejection. A block that is bypassed through another tool does not represent the desired control from the project.

Tests should be repeated when changing the client or the way the agent is started. A verified configuration in one path does not automatically demonstrate the effect in another. The register should indicate version, environment and result, without becoming an archive of secrets. This evidence allows the team to determine whether a change altered the operational perimeter.

The Management of errors of agents in production with Aqua concerns a related theme: a useful flow must make even failures and abnormal conditions readable. For development, blocking an action must produce enough explanation to decide the next step, without requiring generic openings.

Can the sandbox certify the product code security?

The sandbox can limit the effects of tools, but written code can still contain errors, vulnerabilities, or incorrect application rules. An agent could produce a modification that passes existing tests and mishandles an uncovered case. The review must read the behavior introduced and compare it with the task, not just verify that the execution took place within a limited environment.

The Program Anthropic OSS Scanner addresses another level, that of reporting on suitable open source projects. Even there a report requires verification and triage. Analysis, isolation, and review tools may complement each other, but none must be presented as universal certification of enterprise software.

The use of ChatGPT for coding follows the same operational criterion: proposal, verification and responsibility remain distinguishable. The team needs to know who accepts the diff and what evidence is needed before a release. The availability of an assistant does not alone change the definition of ready code.

Perimeter check before first modification

Identify repository, client, and execution path. Use test data and minimum permissions. Try one allowed access and one banned, without sensitive material. Verify that the exception requests describe the concrete action. Check where logs and results end. Keep review and release separate from the agent's ability to execute tools.

How to keep controls consistent when the agent uses multiple tools?

A project can combine editor, terminal, browser, and external services. The control must follow the passage between these tools, because a limited operation in the terminal could be attempted from another path. The process map should indicate where each component runs and what resources it can reach. This allows the actual boundary to be observed, rather than giving the sandbox unverified coverage.

The Claude SDK for browsers and computers use represents an example of an environment that the developer must build and control separately. It is not an automatic extension of the Copilot sandbox. If a team uses both in their work, they need to know which identity and configuration apply to each, especially when files or sessions with business data are opened.

The operating rule can remain simple: a new tool requires a perimeter check before receiving access equivalent to those already approved. The person responsible shall decide on the basis of the task and shall retain evidence. In this way the flexibility of the flow does not become a progressive opening of the environment to resources that the project had not planned to use.

What errors should be avoided in the daily setup?

Specific errors are confusing local with offline, using productive credentials to simplify a test, opening all folders after a block, and considering an approval as a permanent waiver of limits. Another error is not updating the team documentation when the execution path changes. The perimeter must remain understandable even to those who have not configured the first pilot.

Each task should also indicate the expected result and the files that can be edited. If the agent proposes an intervention outside that perimeter, the person in charge shall assess the need before extending it. This discipline makes it easier to read the diff and distinguish a relevant correction from collateral changes that require other evidence. The sandbox helps contain operations, while the mandate keeps the purpose of the work clear.

There is no Italian exclusion from the announcement, but clients, versions and conditions remain to be verified in the release and applicable documentation. To integrate a development assistant with consistent access to the project, work on Business Software can start from a test repository, a circumscribed task and a concrete boundary verification.