This site does not allow itself to be embedded. You can still read it on the original site — the toolbar below keeps your place in the directory.
The August 11 JetBrains plugin release adds Copilot memory across chat sessions, Ollama as a bring-your-own-key provider, and enterprise managed settings for MCP access and permission bypass. Here is what each feature actually does and why the IDE just became the control point for agent tooling.
GitHub's August 11, 2026 update to Copilot for JetBrains turns the plugin into a much closer relative of the Copilot desktop app and CLI: persistent memory across chat sessions, Ollama as a bring-your-own-key provider, server-side enterprise managed settings, and expanded Codex workflows. JetBrains was the last major IDE family to lag the full agent treatment, and this release closes most of that gap in one pass.
For developers who live in IntelliJ IDEA, PyCharm, or WebStorm, the practical question is which of these features changes how you actually work. Here is what shipped, what the underlying mechanics are, and where the release fits.
## What shipped
Four changes carry the release:
1. **Copilot memory across chat sessions.** The plugin can now retain and recall useful information between agent conversations, so you stop re-explaining project conventions in every session. It is managed with a Copilot Memory toggle in the settings portal.
2. **Ollama as a BYOK provider.** You can configure Ollama as a provider and select models throughout the JetBrains experience, which means local models can serve Copilot features in your IDE alongside hosted models.
3. **Enterprise managed settings.** Administrators get server-based controls for plugin availability, MCP server access, permission bypass behavior, and OpenTelemetry settings across their organization.
4. **Expanded Codex workflows.** Codex sessions appear in agent debug logs, and Codex supports updated permission modes plus customizations through instructions and skills. Copilot CLI also auto-installs from integrated terminals on macOS, Linux, and Windows.
There is also a round of quality fixes: chat references (`#` file and folder references) restored in Copilot, Claude, and Codex chat inputs, more reliable MCP execution and approvals, and terminal rendering fixes.
## What Copilot memory actually is
The memory feature is worth more than the changelog line suggests. Per the GitHub docs, Copilot memory stores two kinds of entries: repository-level facts (coding conventions, architectural decisions, build commands, project-specific rules) and user-level preferences (implied or stated personal preferences about how you interact with Copilot). Both are created only in response to user-initiated Copilot activity, and both are scoped: repository facts apply only to that repository, and user preferences apply only to the user who created them.
Two mechanics matter for trust. First, repository facts are stored with citations to the code that supports them, and Copilot re-validates those citations against the current branch before using a fact. Second, entries that go unused are deleted automatically after 28 days, with the timer resetting when Copilot successfully validates and uses an entry. That is a deliberate answer to the stale-context problem: memory is a living cache with an expiry, not an archive.
The feature is in public preview, and it now spans Copilot cloud agent, code review, CLI, and the JetBrains plugin. Facts captured in one surface can be applied by another, which is how the system compounds: a convention learned while reviewing a PR in one repo can inform later cloud agent work in the same repo.
## Ollama BYOK: local models inside the managed IDE
The Ollama integration is the other headline. BYOK (bring your own key) has been the pattern for routing Copilot through third-party gateways and providers, but Ollama is different: there is no key at all, because the models run on your machine. Putting Ollama behind the provider configuration in JetBrains means you can now mix a local model for some tasks and a hosted frontier model for others inside the same IDE session.
The practical use case is privacy and cost control: code that never leaves your laptop, for the portions of work where a small local model is good enough, with the hosted model reserved for the hard parts. It is also the first mainstream IDE-level example of the agent-tooling pattern where the IDE becomes a router between local and hosted inference rather than a client to one vendor.
One honest caveat: this does not mean your whole Copilot workflow runs offline. The BYOK path covers provider configuration and model selection, and Copilot's agentic features still depend on the hosted service. Treat Ollama as a complement to hosted models, not a replacement for them.
## The governance thread
The enterprise managed settings slot into a pattern GitHub has been building all summer. The August 6 release added MCP allowlists to enterprise managed settings, and the effort-level controls for code review went GA on August 7. This release extends the same controls - MCP server access, permission bypass behavior, OpenTelemetry settings - to the JetBrains plugin, which matters because IDE-attached agents touch the most privileged surfaces: your local filesystem, terminals, and now your local inference runtime.
The bigger take: the IDE is where agent governance actually has to work, because it is where the agent has the most access. Server-side policy that reaches into the plugin, rather than relying on each developer's local config, is the difference between an organization saying it has controls and an organization enforcing them.
## Where it fits
This is the second release in a week aimed at making Copilot behave more like a durable teammate than a chat pane: the SDK already lets teams build their own Copilot-powered agent harnesses, and persistent memory is the other half of that story, the state that survives between sessions. Claude Code shipped cross-session messaging on the same timeline, so the frontier is converging on the same answer: sessions should be cheap, but the context you build should carry over.
The release also keeps the price of switching in mind. JetBrains developers who were weighing a move to a different editor for better agent support now have less reason to leave, and the BYOK path means they are not locked to GitHub's model lineup either. That combination - durable memory plus your choice of local models plus server-side policy - is a credible argument that the managed-IDE route is not dead, it was just waiting on the agent layer to mature.
## Continue Reading
- [The GitHub Copilot guide](/blog/github-copilot-guide) - how the whole Copilot surface fits together, from chat to agents
- [Copilot CLI BYOK and AI credits](/blog/github-copilot-cli-byok-ai-credits) - how bring-your-own-key works across Copilot surfaces
- [Why skills beat prompts for coding agents](/blog/why-skills-beat-prompts-for-coding-agents-2026) - the instructions-and-skills pattern now in Codex workflows
- [Enterprise team model policy targeting in Copilot](/blog/github-copilot-enterprise-team-model-policy-2026) - the other half of the governance story
- [Claude Code cross-session messaging](/blog/claude-code-cross-session-messaging-2026) - how the competition handles persistent context between sessions
- [Program-as-Weights Turns Prompts Into Local Fuzzy Functions](/blog/program-as-weights-fuzzy-functions)
## Sources
- [Copilot memory and Ollama in GitHub Copilot for JetBrains - GitHub Changelog, August 11, 2026](https://github.blog/changelog/2026-08-11-copilot-memory-and-ollama-in-github-copilot-for-jetbrains)
- [About Copilot memory - GitHub Docs](https://docs.github.com/copilot/concepts/agents/copilot-memory)
- [GitHub Copilot for JetBrains plugin versions - JetBrains Marketplace](https://plugins.jetbrains.com/plugin/17718-github-copilot--your-ai-pair-programmer/versions)Read on developersdigest.tech ↗
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.