Copilot CLI now finds local Ollama models: what stays on the machine

Running a coding agent against a model on your own machine is an attractive idea for teams with sensitive code: the prompts and the code context never need to reach a model provider. On 7 October 2026 GitHub made that easier to set up in Copilot CLI, which can now discover models from a local Ollama instance. The change is useful, but GitHub's own wording is careful about what it does not do. Choosing a local model is not the same as working offline, and it does not by itself keep everything on the machine.

What changed

According to the GitHub changelog, from CLI version 1.0.94-0 the /model command can discover supported models from a running local Ollama instance, listed alongside configured models and the cloud models GitHub provides.

The flow is deliberately explicit:

• Discovery does not add models automatically.
• You choose a discovered model, review its provider and endpoint, and then pick either "Add and use for this session" or "Add without switching".
• The model can be used in the current session without restarting the CLI.
• Ollama and the model must already be installed; the CLI does not install a runtime or download models.
• Models must support tool calling and streaming.
• Provider connection failures appear in the model picker with an explanation.

Before this, the same result needed environment variables. The Copilot CLI documentation on bring-your-own-key models still describes that route: Ollama is used through the default openai provider type, with COPILOT_PROVIDER_BASE_URL set to http://localhost:11434 and no API key needed. The documentation recommends a context window of at least 128k tokens for best results.

What a local model does not change

The most important sentence in the changelog is this one: "Choosing a local model doesn't turn on offline mode or disable GitHub telemetry." Three separate things are in play, and they are controlled separately.

Where the model runs. With a local Ollama model, inference happens on the machine. Prompts and code context sent to that model stay local.

Whether the CLI contacts GitHub. That is controlled by offline mode, which remains an explicit choice through COPILOT_OFFLINE=true. The documentation describes offline mode as designed for isolated environments where the CLI should talk only to a local or on-premises model provider.

Whether any remote provider is configured. The documentation warns that offline mode "only guarantees full network isolation if your provider is also local or within the same isolated environment". If the provider base URL points to a remote endpoint, prompts and code context still go over the network to that provider, offline mode or not.

So a developer who picks a local model in /model but leaves offline mode off still has a CLI that talks to GitHub. A developer who turns on offline mode but configures a remote provider still sends code to that provider. Only the combination of a local provider and offline mode gives the isolation many teams have in mind.

What is announced but not available

The same changelog announces intelligent routing with local models, linking to a Microsoft blog post, and asks readers to "stay tuned for availability". It is not available yet, and nothing about how it will choose between local and cloud models should be assumed until GitHub documents it.

The sandbox is a separate control

Also on 7 October, GitHub made local sandboxing for Copilot generally available in Copilot CLI, the Copilot app and VS Code sessions using Agent Host. It restricts what tools and commands started by Copilot can do with the filesystem, network and credentials, and it is included with Copilot at no extra cost. GitHub is explicit that "model execution and tool isolation are separate concerns": sandbox policies apply to tool execution whichever model is in use.

That matters for local models. Running the model locally keeps prompts on the machine, but it does nothing to limit what the commands an agent runs can reach. The sandbox is still needed. For an overview of how coding-agent sandboxes compare, see the article on sandboxing coding agents.

What it means for engineering and security leaders

For teams that want some work to stay entirely on developer machines, this change lowers the setup cost, but the policy still has to be written down. A useful framing is three questions per team: which model provider is allowed, whether offline mode is required, and which sandbox policy applies. Each is a separate setting, and answering one does not answer the others.

Local models also bring a quality trade-off. A model small enough to run on a laptop is usually better suited to narrow tasks than to long agent sessions. The article on small open-weight models for coding sub-agents looks at where they fit. The 128k context recommendation is also a practical constraint worth checking for each model and runtime configuration before rollout.

Finally, telemetry is its own decision. Whether the CLI reports usage to GitHub, and what your own observability stack captures, are separate from where the model runs. The article on content capture in AI telemetry covers that choice.

Practical takeaways

• Update to Copilot CLI 1.0.94-0 or later before trying local model discovery.
• Check that local models support tool calling and streaming, and prefer ones with at least 128k tokens of context.
• Set COPILOT_OFFLINE=true where work must not contact GitHub, and confirm that no remote provider is configured.
• Keep local sandboxing on regardless of the model; it limits what tools can do, not what the model sees.
• Treat intelligent routing with local models as announced, not available, until GitHub documents it.
• Write down, per team, which providers are allowed and whether offline mode is required.

Where SpanDock fits

If you also want to see what Copilot CLI does without sending that data to a third party, SpanDock lists GitHub Copilot CLI among the tools it shows the exact configuration lines for in getting started. As the privacy page explains, that telemetry is received and stored on your own machines and leaves your network only for destinations you add.