GitHub Copilot JetBrains — Ollama BYOK ≠ Private Data

On August 11, GitHub shipped three features into its Copilot ecosystem simultaneously: Ollama as a bring-your-own-key provider for JetBrains IDEs, persistent Copilot memory that retains context across agent chat sessions, and air-gapped Copilot CLI support in the GHES 3.22 release candidate. By next Monday, compliance teams across regulated industries will get a Slack message saying “we now use local models.” That message will be wrong in ways that matter.

TL;DR

• What: Ollama BYOK, persistent memory, and air-gapped CLI shipped for Copilot on the same day
• Problem: Each feature has a different data boundary — local inference does not mean local data
• Gap: Inline completions still route cloud-side, memory is server-stored, air-gap covers CLI only
• Action: Audit all three control surfaces independently before approving for regulated codebases

What Happened

GitHub’s August 11 changelog added Ollama as a BYOK provider in GitHub Copilot for JetBrains. IntelliJ IDEA, PyCharm, WebStorm, and other JetBrains IDEs can now point Copilot at a model running on the developer’s own machine. The integration supports provider configuration and model selection throughout the JetBrains experience — meaning chat and agent sessions can run against your local Ollama instance instead of GitHub’s hosted models.

The same release introduced persistent Copilot memory. Context from agent chat sessions now survives across conversations, managed via the Copilot Memory toggle in the Copilot settings portal. That last detail matters: the settings portal is GitHub’s server-side infrastructure, not a local config file.

Separately, GHES 3.22 RC landed with Copilot CLI support for disconnected and air-gapped environments. Administrators can configure Copilot CLI to work with GHES for enterprises that operate without connectivity to GitHub Cloud. This capability is in technical preview.

Three features. Three different data boundaries. One marketing narrative that will collapse them into “Copilot now runs locally.”

Why This Matters

I’ve watched this pattern repeat for two years: a cloud vendor ships a “local” feature, teams celebrate, and security teams discover six months later that the telemetry layer never moved. The Ollama BYOK integration is genuinely useful — pointing chat and agent sessions at a local model keeps those inference requests off GitHub’s servers. But the official changelog does not specify that inline code completions follow the same path. GitHub’s documentation enumerates Ollama as a BYOK provider for model selection, not as a replacement for the completions pipeline. Until GitHub explicitly confirms that inline completions route through the local Ollama instance, enterprise teams must treat them as cloud-routed.

Ollama BYOK covers chat and agent sessions in JetBrains. Whether inline code completions also route locally is not documented in the official changelog. Treat completions as cloud-routed until GitHub confirms otherwise.

The persistent memory feature introduces a second vector. Memory that “retains useful information across agent chat sessions” is stored server-side and managed through GitHub’s Copilot settings portal. For teams working on proprietary algorithms or regulated IP, this means session context — potentially including code snippets, architectural decisions, and internal naming conventions — persists on GitHub infrastructure. Retention policy and audit log coverage for this memory store are not documented in the GHES 3.22 release notes. If your compliance framework requires data residency guarantees, you have no mechanism to verify where memory data lives or how long it persists.

The air-gap story is the most misleading of the three. GHES 3.22’s air-gapped Copilot CLI lets disconnected enterprises use the command-line interface without GitHub Cloud connectivity. But this capability explicitly covers the CLI surface — and it is still in technical preview, subject to change. The JetBrains plugin, which just shipped Ollama BYOK and persistent memory, operates on a separate network path with separate telemetry settings. “Air-gapped” in the GHES docs does not extend to the IDE plugin. An enterprise that approves Copilot based on “we have air-gapped support” while developers use the JetBrains plugin has approved something they have not evaluated.

What makes August 11 uniquely risky is the simultaneity. Each feature individually is defensible. Ollama BYOK gives model flexibility. Persistent memory improves agent session continuity. Air-gapped CLI serves disconnected environments. But all three landing on the same day, with each having a different data boundary and a different admin control surface, creates a configuration matrix that most enterprise security reviews are not scoped to handle. The expanded enterprise admin controls — covering plugin availability, MCP server access, permission bypass behavior, and OpenTelemetry settings — exist precisely because these boundaries need active management. The controls are there. The question is whether anyone configures them before the approval email goes out.

Enterprise admins: configure the new server-based controls for JetBrains (plugin availability, MCP server access, permission bypass, OpenTelemetry) before rolling out Ollama BYOK. The controls exist — use them proactively, not retroactively.

There is a parallel deadline that compounds the pressure. MAI-Code-1-Flash is being deprecated across all GitHub Copilot experiences on September 10, 2026. The replacement, MAI-Code-1.1-Flash, delivers 73% lower pricing and native vision support, but Enterprise and Business administrators must explicitly enable it — the policy toggle ships disabled by default. Teams distracted by the Ollama BYOK rollout need a parallel migration track, or they hit a forced model cutover under pressure in less than four weeks.

The comparison point here is Continue.dev, which has offered Ollama integration since 2023 with a fundamentally different architecture. Continue runs as a local-first plugin where model configuration, context, and inference all stay on your machine by design. There is no server-side memory store, no cloud completions pipeline, no settings portal — configuration lives in a local JSON file. The tradeoff is obvious: Continue requires more setup effort and lacks GitHub’s native integration depth. But for teams whose primary concern is data boundary clarity, Continue’s architecture makes the audit trivial. With Copilot’s Ollama BYOK, the audit is not trivial — it is three separate audits, one per feature, each with incomplete documentation.

The Take

The approval that gets signed this week will be based on a surface reading: “local models plus air-gap equals private.” It will not account for server-side memory persistence, unclear completions routing, or the fact that GHES air-gap coverage does not extend to the IDE plugin. I am not arguing against the features — Ollama BYOK in JetBrains is a genuine step forward for model flexibility, and the expanded admin controls show GitHub is thinking about enterprise governance. But the marketing narrative and the technical reality are not the same shape, and the gap between them is exactly where compliance failures live.

If you are an enterprise admin, do three things before approving: audit which Copilot features actually route through Ollama versus GitHub’s cloud, disable persistent memory until retention and audit log documentation exists, and treat the GHES air-gap as CLI-only until GitHub explicitly confirms IDE plugin coverage. The features are real. The boundaries are not what they look like.