GitHub shipped three features to Copilot for JetBrains in a single changelog entry dated August 11: persistent memory across agent chat sessions, Ollama as a local bring-your-own-key (BYOK) model provider, and a set of enterprise managed-settings controls covering plugins, MCP server access, and permission-bypass behavior. Verified directly against GitHub’s own changelog post rather than secondary coverage, since none had appeared yet at time of writing.
Each piece on its own is a reasonable, incremental improvement. Together they tell a familiar story about where Copilot sits in the market: bolting agentic-tool capabilities onto an IDE plugin, one feature at a time, roughly a year after Claude Code shipped most of them as native architecture.
Memory, Again — This Time Scoped to JetBrains#
This isn’t Copilot’s first memory feature. GitHub introduced cross-agent memory across the product back in March, the same release that paired it with a data-training-policy announcement developers weren’t thrilled about. What shipped August 11 is a JetBrains-specific rollout: a toggle in the Copilot settings portal that lets the agent “retain and recall useful information across agent chat sessions” inside IntelliJ, PyCharm, and the rest of the JetBrains lineup specifically — context and preferences persisting between conversations instead of needing to be re-explained turn to turn.
That it needed a second, IDE-specific release five months after the general announcement is itself informative. Memory as a capability doesn’t naturally live at the IDE-plugin layer — it’s a property of the agent’s session model, and every time Copilot extends a capability to a new surface (JetBrains here, VS Code elsewhere, the CLI, the web app), it’s effectively re-implementing the same idea against a different embedding. Claude’s Managed Agents Memory — filesystem-based, API-controlled, shared across sessions and clients by design — didn’t need a JetBrains edition, a VS Code edition, and a CLI edition, because the memory lives with the agent, not with whichever editor happens to be hosting it that day.
Ollama BYOK: A Genuinely Useful Addition#
The more interesting change is Ollama support as a BYOK provider, letting JetBrains users route Copilot’s agent through a locally-run model instead of GitHub’s hosted ones — provider configuration and model selection built into the plugin. For teams with data-residency constraints, air-gapped environments, or just a strong preference for not sending code to a third party, this is a legitimate and useful option, and credit where due: shipping first-class support for an open local-inference runtime is the right call, not a checkbox feature.
It’s also a tell about where the pressure is coming from. Enterprises increasingly want the choice between cloud and local inference built into their tooling rather than assembled from scratch, and Copilot adding it here follows — rather than leads — a trend the open-weight ecosystem (Kimi K3, GLM-5.2, Qwen’s open releases) has been pushing all year. Anthropic’s own local-inference story remains thin by comparison; this is one of the few areas where Copilot’s breadth-first, integrate-everything approach produces a feature this blog would actually recommend using.
MCP Governance: Necessary, and Overdue#
The enterprise managed-settings additions are the most consequential piece, even though they’ll read as boring platform plumbing to most developers: admins now get server-based control over plugin availability, MCP server access, permission-bypass behavior, and OpenTelemetry configuration, enforced centrally rather than left to individual developer settings.
The timing matters. MCP’s rapid adoption across every major coding tool has produced a steady drumbeat of security disclosures this year — the STDIO transport exposure affecting 200,000+ servers, OAuth token hijacking via npm postinstall hooks, and, as recently as late July, a disclosed flaw in Microsoft’s own Azure DevOps MCP server that remains a live concern. An MCP server is, functionally, code an agent can be induced to call with real credentials attached; letting individual developers decide which ones connect without any org-level guardrail was always going to be a liability at enterprise scale. Centralized control over MCP access, plugin availability, and whether an agent can bypass its own permission checks is the kind of control that should have shipped alongside MCP support in the first place, not eight-plus months into the ecosystem’s growth.
It’s also, notably, the same category of control Claude Code has been building out release by release — sandbox credential-masking, deny-rule enforcement, workspace trust prompts — as this week’s own changelog coverage documented. The difference isn’t that Copilot is behind on recognizing the problem; it’s that Copilot is retrofitting governance onto a plugin architecture built for autocomplete, while Claude Code has been iterating permission and sandbox primitives as a core part of an agent-native design from the start. Both approaches can arrive at “admins can lock down MCP access.” Only one of them didn’t need a dedicated engineering effort per IDE to get there.
The Pattern Holds#
None of this is a knock on shipping useful features — Ollama BYOK and MCP governance controls are things Copilot users should actually want, and this release delivers them. But the release itself, scoped to one IDE plugin among several Copilot surfaces, is the clearest illustration yet of the structural gap this blog keeps returning to: Copilot is a strong autocomplete-and-chat layer accumulating agent capabilities piecemeal, IDE by IDE, while Claude Code shipped as an agent first and never had to retrofit the memory, coordination, and governance layers back in. Same destination, different amount of architectural debt to pay down to get there.
Source: GitHub Changelog, fetched directly, August 12, 2026.