DEV Community

Ahab
Ahab

Posted on • Originally published at indieseek.co

GitHub Copilot for JetBrains: use Ollama without confusing local inference with local memory

#ai #githubcopilot #jetbrains #ollama

GitHub Copilot for JetBrains: use Ollama without confusing local inference with local memory

Quick answer

GitHub Copilot for JetBrains now supports Ollama as a local BYOK provider and can retain Copilot Memory across agent chat sessions. Treat them as two separate controls.

Ollama can keep model inference on your machine when the selected endpoint is loopback and the selected model is local. Copilot Memory stores repository facts and user preferences under GitHub's memory controls. Enabling a local model does not prove that memory, account, session sync, telemetry, MCP calls, or cloud-agent work also stays local.

Roll out in two lanes: first prove the local inference path with Memory disabled, then decide whether to enable Memory and audit what it stores.

Who this is for

This guide is for IntelliJ IDEA, Android Studio, PyCharm, WebStorm, and other JetBrains users who want Copilot's agent workflow with a locally served model, or who need to review the privacy boundary before enabling persistent context.

It is also for organization administrators. GitHub says local BYOK in IDEs can be disabled by organization or enterprise policy, while Copilot Memory has its own policy and user toggle. The existing Copilot managed-settings guide explains why client access and runtime controls must be tested separately.

What changed on August 11

GitHub's release adds four notable JetBrains capabilities: enterprise-managed settings, cross-session Copilot Memory, Ollama as a BYOK provider, and expanded Codex workflows. The release says Ollama provider configuration and model selection are available throughout the JetBrains experience.

GitHub's BYOK documentation distinguishes local BYOK from enterprise BYOK. Local keys and provider configuration are handled client-side, and a local model can remove the dependency on GitHub's Copilot model API. Enterprise BYOK is different: it is handled server-side and still requires a Copilot license and internet access.

Memory is a separate public-preview system. It can store repository-level facts such as build commands and architecture decisions, plus user-level preferences. Repository facts are citation-backed and revalidated against the current branch. Unused entries expire after 28 days, and users or administrators can review and delete them.

Boundary matrix

Surface What the official material confirms What you must verify
Ollama model inference JetBrains supports Ollama as a local BYOK provider Endpoint is 127.0.0.1, local model is selected, and requests reach the local process
Copilot Memory Repository facts and user preferences persist under GitHub controls Policy, billing owner, stored entries, citations, deletion, and whether you need it
JetBrains plugin Provider/model selection and agent chat are integrated Exact plugin and IDE builds, selected provider after restart, and fallback behavior
Other agent paths Release also covers MCP, Codex, terminals, and cloud agents Network destinations, permissions, session sync, and every non-model tool path

The safe claim is narrow: the model request was served by local Ollama. Do not upgrade that claim to “Copilot is fully offline” without separate network and feature evidence.

A six-gate rollout

1. Record the exact client and policy state

Update to the latest compatible GitHub Copilot plugin, then record the plugin version, JetBrains product/build, account, active billing entity, organization policies, and current Memory state. Do not rely on “latest” as durable evidence.

2. Keep Ollama on loopback

Ollama binds to 127.0.0.1:11434 by default. Keep that default for a single-machine IDE setup. Do not set OLLAMA_HOST=0.0.0.0:11434, add a tunnel, or expose the port merely to make discovery easier.

If you want an explicitly local-only Ollama service, disable its cloud features:

{
  "disable_ollama_cloud": true
}
Enter fullscreen mode Exit fullscreen mode

Then restart Ollama and confirm its logs report that cloud support is disabled. This controls Ollama; it does not disable GitHub-side Copilot features.

3. Prove the provider, not just the answer

In JetBrains, configure Ollama, choose one already-downloaded local model, start a fresh chat, and submit a harmless prompt with a unique marker. Capture:

  • the selected provider and model in the UI;
  • the local Ollama request log or process activity for that marker;
  • the absence of an automatic fallback to a GitHub-hosted model;
  • the result after restarting both the IDE and Ollama.

If the UI says Ollama but no local request appears, stop. A plausible answer is not routing evidence.

4. Test the failure path

Stop Ollama and repeat the harmless prompt. The acceptable result is a clear local-provider failure or an explicit, user-approved provider switch. Silent fallback fails the gate. Restart Ollama and confirm the same model works again.

For larger open models, check hardware before downloading. The local-model hardware checklist shows why “open” and “laptop-ready” are different claims.

5. Audit Memory separately

Keep Memory disabled during the routing test. If you later enable it, use a disposable repository with a harmless convention such as npm run verify:fixture. Interact as a user with write access, then review repository facts under the repository's Copilot Memory settings and user preferences in personal Copilot settings.

Record any fact, its citation, owner, and deletion result. Do not seed passwords, customer data, private URLs, or production architecture secrets. Memory creation is not guaranteed for every sentence; if no entry appears, record “not observed” instead of claiming it was stored.

6. Gate production use

Approve the rollout only if local routing, stopped-server behavior, restart persistence, policy enforcement, memory inspection, and deletion all match the intended boundary. Keep a one-step rollback: switch provider, disable Memory, or disable the local-BYOK policy.

Decision tree

  1. Need only local model inference? Keep Memory off and validate Ollama routing first.
  2. Need persistent repository context? Enable Memory only after ownership, review, retention, and deletion are acceptable.
  3. Need a fully offline or air-gapped workflow? Disable unrelated cloud features and prove network behavior; the JetBrains release alone is not evidence.
  4. Organization policy hides Ollama? Ask the administrator to review local BYOK policy; do not work around it with an exposed endpoint.
  5. Local model lacks tool quality or context? Route only bounded chat tasks to it and keep agentic writes on a separately evaluated model.

Common mistakes

  • Calling the whole Copilot workflow local because the LLM runs in Ollama.
  • Enabling Memory and Ollama together, then being unable to attribute behavior.
  • Exposing port 11434 to the LAN or internet without a real access-control design.
  • Confusing local BYOK with enterprise BYOK, which uses a server-side path.
  • Trusting the model name shown in prose instead of observing the local request.
  • Testing persistence with secrets or sensitive repository facts.
  • Assuming a stored fact is permanent; unused Memory entries expire and facts are revalidated.

For other local-control boundaries, see the Qwen trusted-LAN checklist. For tools that can act on external data, use the connector security checklist.

Copyable acceptance record 

date / owner:
jetbrains_product_build:
copilot_plugin_version:
account / billing_entity:
local_byok_policy: enabled | disabled
memory_policy / user_toggle:
ollama_bind: 127.0.0.1:11434 | other
ollama_cloud_disabled: yes | no
selected_provider / model:
local_request_observed: pass | fail
stopped_server_fails_closed: pass | fail
restart_preserves_selection: pass | fail
memory_fact_observed / citation:
memory_delete_verified: pass | fail | not tested
non_model_network_paths_reviewed:
rollback_action / owner / evidence:
Enter fullscreen mode Exit fullscreen mode

FAQ

Does Ollama make GitHub Copilot for JetBrains fully offline?

It can localize the model-provider path. Other Copilot capabilities have separate account, memory, session, tool, and network behavior. Verify those independently before making an offline claim.

Is Copilot Memory stored inside Ollama?

No official source says that. GitHub documents Memory as repository facts and user preferences managed through GitHub Copilot settings. Treat it as a separate service and control plane.

Should I expose Ollama so JetBrains can find it?

Not for a same-machine setup. Ollama's documented default is loopback. Keep it there unless you have a deliberate authenticated network design.

Sources

Top comments (0)