BuildNot yet confirmed elsewhere1 publisher2 min readPublished
Copilot CLI pairs local Ollama models with a GA sandbox that excludes the CLI's own process
GitHub added local Ollama model discovery to Copilot CLI 1.0.94-0 and took its agent sandbox to general availability on October 7, dev.to reported. Keeping work on a developer's machine still takes manual steps, since Ollama must be installed first and offline mode is a separate setting.
The Engineer · Build desk

What happened
- Models that /model finds in Ollama are not added on their own: the user checks provider and endpoint, then picks add-and-use or add-without-switching, with no CLI restart.
- Only local models that support both tool calling and streaming can be used through the new discovery path.
- The sandbox is generally available in Copilot CLI, the Copilot app and VS Code sessions that use Agent Host, and it confines commands that Copilot itself starts.
- Admin-managed settings let an organisation enforce sandbox policy that individual developers cannot loosen.
Why it matters
- exposure Sensitive paths remain writable through the CLI's built-in edit tools if their in-process policy check has a bug, since no OS control backs those tools.
- decision Teams that need prompts kept off the network must set offline mode and check provider configuration themselves; choosing an Ollama model in /model does neither.
- cost The sandbox adds no charge on standard paid seats, so adoption cost falls on policy authoring and on installing Ollama and its models on each machine that runs local inference.
Offline mode is an environment variable, `COPILOT_OFFLINE=true`, according to the changelog as summarized on dev.to [11]. Picking a local model also leaves GitHub's usage data collection on [10]. The changelog adds that remote providers can still receive prompts and code context over the network even in offline mode. It points readers to the provider configuration docs to confirm what leaves the machine [12]. If the connection to a provider fails, the /model picker shows why [7].
We think the sandbox is the better engineering of the two. Microsoft eXecution Container (MXC) translates one sandbox policy into each operating system's own controls on Windows, macOS and Linux [16]. Paths can be read-only, read-write or denied [17]. Network rules cover internet egress, the local network and individual hosts [17]. Credential rules turn Git and gh authentication on or off and can mask extra environment variables. Per-command exceptions let a single command run outside the sandbox when it needs more access [17].
Credentials get the most careful treatment. Tools inside the sandbox receive placeholder values, and a local proxy hands over the real credential only to approved HTTPS endpoints [19]. In our view that is the right design. A sandboxed command talked into posting a token to an unapproved host has only a placeholder to post.
The boundary has one documented exception. The CLI's built-in file tools are the CLI's own commands, not shell commands like `sed`, and they run inside the CLI process [22]. The CLI itself is not sandboxed, so the OS layer cannot see or block what those tools do to files [23]. Each tool reads the policy itself and follows it on what the docs call a "best-effort" basis [23]. A deny rule on a directory is therefore enforced by the operating system when the agent shells out to `sed`, and only by GitHub's application code when the agent uses its built-in edit tool [24]. According to the dev.to post, GitHub's documentation states this limit plainly [2].
Local MCP servers and language servers can be set to run inside the sandbox or outside it [18]. The dev.to text breaks off partway through its passage on remote MCP servers [3].
Everything here comes from one dev.to post by Nokka, dated October 10. The post says it was written by AI (deepseek-v4.1-flash) through Hermes Agent with human review, and it cites GitHub's changelog and documentation [1].
What to watch
- Whether GitHub's announced smart routing to local models keeps the explicit add-and-confirm step that /model uses today.
- Any change that puts the CLI process or its built-in file tools under OS-level enforcement instead of in-process policy checks.
- GitHub's documentation on how the sandbox treats remote MCP servers.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence48
- Adoption
- Insufficient
- Hype gap−5
- Incentives
- Insufficient
- Confidence45
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The dev.to post by Nokka, dated 10 October 2026, states it was written by AI (deepseek-v4.1-flash) via Hermes Agent under human control and quality review, and cites GitHub's changelog and documentation.
ReportedSupportedSource: dev.to post by Nokka3 sources— create a free account to open themView cited source - [2]
According to the dev.to author, GitHub's documentation states these sandbox limits directly rather than hiding them.
ReportedSupportedSource: dev.to post by Nokka3 sources— create a free account to open themView cited source - [3]
The supplied dev.to text ends mid-sentence in its passage on remote MCP servers.
ReportedSupportedSource: dev.to post as supplied3 sources— create a free account to open themView cited source - [4]
On 7 October 2026 GitHub made two announcements a few hours apart: local model selection in Copilot CLI and the local sandbox reaching general availability.
- [5]
From Copilot CLI version 1.0.94-0, the /model command discovers supported models from an Ollama instance running on the local machine, listed alongside user-configured models and GitHub Copilot cloud models.
- [6]
Discovering a model does not add it automatically; the user selects it, reviews its provider and endpoint, and confirms either 'add and use in this session' or 'add without switching', and the model is usable in the current session without restarting the CLI.
- [7]
If the provider connection has a problem, the model picker shows an explanation.
- [8]
Ollama and the model must already be installed; the discovery flow does not install the runtime or download models.
- [9]
A model must support tool calling and streaming to be used through this path.
- [10]
Selecting a local model does not enable offline mode and does not turn off GitHub's usage data collection.
- [11]
In the CLI, offline mode must be opted into via the environment variable COPILOT_OFFLINE=true.
- [12]
The changelog states that even in offline mode, remote providers can still receive prompts and code context over the network, and directs readers to the provider configuration documentation.
- [13]
GitHub has announced smart routing that will route tasks to local models, but it is not yet available.
- [14]
The local sandbox is generally available in Copilot CLI, the Copilot app, and VS Code sessions that use Agent Host.
- [15]
The sandbox limits Copilot-initiated commands' access to files and directories, network, credentials and other system capabilities, based on policy set by the developer or organization.
- [16]
The sandbox is powered by Microsoft eXecution Container (MXC), which translates the same sandbox policy into OS-level controls on Windows, macOS and Linux.
- [17]
CLI sandbox controls: files and directories read-only, read-write or denied; network control of internet egress, local network and per-host allow or deny; credentials enabling or disabling Git and gh authentication or masking extra environment variables; macOS keychain access; and per-command exceptions to run individual commands outside the sandbox when more privilege is needed.
- [18]
Users can choose whether local MCP servers and language servers run inside the sandbox.
- [19]
Tools inside the sandbox receive placeholder credential values, and a local proxy supplies real credentials only to approved HTTPS endpoints.
- [20]
Admin-managed settings enforce sandbox policies that developers cannot loosen themselves.
- [21]
The sandbox carries no extra charge for GitHub Copilot users; the documentation wording refers to standard paid seat tiers.
- [22]
The CLI's built-in file tools are the CLI's own commands, not shell commands like sed, and they run in the same process as the CLI.
- [23]
Because the CLI is not sandboxed, the OS-level sandbox cannot see or control file operations made by those built-in tools; the tools instead check the sandbox policy themselves and follow the user's settings on a best-effort basis.
- [24]
A path deny rule is enforced by OS-level controls when the agent runs a shell command such as sed, but only by the CLI's in-process best-effort check when the agent uses the CLI's built-in file tools.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toCopilot CLI เลือกโมเดล AI ในเครื่องได้แล้ว แถมแซนด์บ็อกซ์ GA: มีช่องไหนที่ยังต้องระวัง?
1 article · October 10, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.