GitHub Copilot With Ollama: Going Offline Switches Off Content Exclusion

On 7 October GitHub made it easier to run GitHub Copilot with Ollama. From Copilot CLI 1.0.94-0, the /model picker lists supported models from a running local Ollama instance, and one confirmation adds the model to the session without a restart. The changelog adds a caveat that most readers will skip: choosing a local model does not turn on offline mode or disable GitHub telemetry. Offline mode stays a separate switch, COPILOT_OFFLINE=true.

That caveat is the start of a pattern this site keeps meeting. A local model is not a local data path. Whether the data path is private depends on a handful of settings in other places, and those settings rarely sit next to the model picker.

Instance one: offline mode and content exclusion

GitHub's bring-your-own-model page defines offline mode as stopping the CLI from contacting GitHub's servers, for isolated environments where it should talk only to a local or on-premises provider. The same page warns that offline mode only guarantees isolation if the provider is local too. Point COPILOT_PROVIDER_BASE_URL at a remote endpoint and prompts and code context still go over the network to it.

Now open the content exclusion docs. Exclusion is a Copilot Business and Enterprise feature, and the availability table marks chat and agent support for Copilot CLI as supported. The policy is not stored on the developer's machine. The client sends the current repository URL to GitHub's server, and the server returns the rules that apply.

The CLI's own changelog says what happens when that server cannot be reached. In 1.0.64, dated 23 June, content exclusion stopped blocking every file when the rules service is unreachable, whether the cause is being offline or a transient network error. Access is allowed until the rules can be fetched, which the entry says matches the editor's behavior. Nothing about exclusion in the changelog's later entries, up to 1.0.94 on 8 October, reverses it.

Put the three pages together. The setting that keeps your prompts off GitHub's servers is the setting that stops the CLI from fetching the rules about which files it must not read. By GitHub's stated fallback, those files are then readable.

With a model that really runs on the laptop, that may be acceptable. The excluded file goes into a process on the same machine. The bad case is the one the docs explicitly allow: offline mode plus a base URL on someone else's server. That is a session GitHub's servers never see and no exclusion rule reaches, sending code context to a third party.

This is the central claim, and it can be wrong. Run the CLI with COPILOT_OFFLINE=true in a repository that carries an exclusion rule, ask it to read an excluded file, and watch what happens. If it refuses, because a cached policy applies or the changelog entry is out of date, the claim fails. We have not run that test. Nothing here was reproduced locally, and the claim rests entirely on GitHub's documents.

Instance two: a local daemon that serves cloud models

The second instance is on the Ollama side, and it is independent of GitHub. Ollama's FAQ says the server binds 127.0.0.1 on port 11434 by default, and GitHub's example base URL is http://localhost:11434. So the endpoint looks local by construction.

Ollama's cloud documentation describes a second path through the same app. A signed-in user can run cloud models from the app or CLI under a :cloud name, with nothing to download. The FAQ says Ollama processes cloud prompts and responses to serve them, and does not store them or train on them. Local-only mode is opt-in. You set disable_ollama_cloud in ~/.ollama/server.json, or OLLAMA_NO_CLOUD=1, and restart.

GitHub's changelog does not say whether the Copilot picker filters out models that Ollama serves from its cloud. The CLI's source is not in its public repository, which holds a changelog, a README, a license and an install script, so we could not check. The localhost URL tells you which process receives the prompt. It does not tell you where that process runs inference.

The pattern behind both instances is older than this release. Our September post on GHES 3.22 found the same thing on the server side: the isolation comes from the endpoint you pick, not from the feature.

Why teams keep walking into it

The control for privacy is spread across three owners. The model picker belongs to the CLI, the offline switch is an environment variable that appears on a how-to page but not in the CLI command reference's variable list, and the cloud switch belongs to Ollama. Nobody owns the combination. This is the integration gap that why enterprise AI doesn't ship describes: the model works, and the part around it is nobody's job.

The cheapest way out

The configuration reference has a channel that does not need GitHub: device-managed settings, read at startup from /Library/Application Support/GitHubCopilot/managed-settings.json on macOS, /etc/github-copilot/managed-settings.json on Linux, or the GitHubCopilot policy key on Windows. The CLI also loads server-managed settings, and the reference describes a cached copy as the fallback when that fetch fails. MDM is the layer that is there either way. On POSIX, the CLI rejects a file that is a symlink, not owned by root, or world-writable.

If your organization depends on content exclusion, do this before anyone adds an Ollama model:

1. If sessions authenticated by a provider key rather than a GitHub account should not exist, deploy forceLoginOrgs through the device channel. The reference says it refuses BYOK and API-key authentication and fails closed if the managed policy cannot be read. It does not say whether a signed-in user can still set COPILOT_OFFLINE=true, so check that in the test below.
2. Where local models are allowed, require the provider to be loopback only. Set OLLAMA_NO_CLOUD=1 or disable_ollama_cloud, and check that Ollama's log reports cloud as disabled.
3. Do not count on exclusion in offline sessions. Keep secrets out of the working tree. For shell commands, the managed sandbox key can add deniedPaths, which users can add to but not remove. That covers sandboxed commands, not the CLI's own file tools.
4. Use permissions.limitTo for domain boundaries on agent network requests. The reference says it does not restrict shell, read or write operations by themselves, so it complements step 3 rather than replacing it.

Putting this on a managed baseline across a fleet is what a private LLM deployment actually consists of. The model download is the easy part.

The test that settles all of this is small: one repository with one exclusion rule, one session with COPILOT_OFFLINE=true, and one request to read the excluded file.