What happened
GitHub updated Copilot for JetBrains IDEs on August 11. IDEs are coding applications such as IntelliJ and PyCharm. The update adds memory between chats and support for local Ollama models.
The first is Copilot memory. Copilot can now “retain and recall useful information across agent chat sessions,” so you stop re-explaining the same project details or preferences every time you open a new chat. It’s controlled by a Copilot Memory toggle in the Copilot settings portal, meaning you can turn it off. Check memory retention and project scope before using it for client work.
The second is Ollama as a BYOK (bring your own key) provider. BYOK means you connect a model you run or pay for yourself instead of only using GitHub’s built-in options. With Ollama, that model can be running locally on your own machine rather than in the cloud. GitHub confirms “provider configuration and model selection throughout the JetBrains experience.” Follow its BYOK provider documentation to configure the local address and model name.
The same update adds enterprise managed settings, giving organization admins centralized control over which plugins are allowed, which outside tools Copilot can connect to, when it can skip asking for permission, and what usage data gets sent back to GitHub. That part is aimed at IT admins, not individual developers. The update also makes Codex sessions show up in Copilot’s own activity logs and lets Copilot’s command-line tool install itself automatically from JetBrains’ built-in terminal on macOS, Linux, and Windows. Note that this specific rollout is for JetBrains IDEs (IntelliJ, PyCharm, and similar), not VS Code.
Why it matters
Persistent memory solves a real daily annoyance: repeating your stack, conventions, and preferences at the start of every chat. Before using memory for client work, confirm whether it stays within one project or is shared across your account. If it is shared, a preference, naming convention, or detail from one codebase could surface in chats about another client project.
Ollama lets you run a local model inside Copilot’s interface. Open-weight models provide downloadable files you can run yourself.
A local setup may help control cost or where code goes. Confirm the provider address and data path before assuming the setup keeps code on your machine.
Who should care
Check memory scope if you use JetBrains Copilot for several clients or codebases on one account. It also matters if you’ve wanted to test a local model through Copilot’s own chat instead of a separate tool. This specific update does not cover VS Code. Cross-project memory scope matters less when you work on a single project.
What builders should do next
Before trusting memory with sensitive work, check its documented scope and try a non-sensitive, fabricated project fact. In one disposable project, tell Copilot that the test service is named Bluebird-47. Start a new chat in that project and check whether it recalls the fact. Then ask about the service name in a different disposable project without supplying it.
If the fact appears in the unrelated project, investigate the memory scope before using the same account for client work. If it does not appear, that single check does not prove project isolation. You can turn memory off with the Copilot Memory toggle while you confirm the behavior.
To try Ollama, install it and confirm it is running locally. Then look for BYOK in Copilot’s settings inside your JetBrains IDE. Use GitHub’s BYOK documentation to confirm the local address and model-name format before using it for real work.
End of article