Next action: install Aident Loadout once, then ask it to audit every path in your repository that launches Ollama for a missing or conflicting context-length setting:

Follow https://aident.ai/SETUP.md

aident capabilities search --query "read files from a connected GitHub repository" --types '["action"]'

Preflight the exact Action, then at one pinned commit SHA, list every Docker Compose service, systemd unit, launch script, Modelfile, and CI job that starts ollama serve or pulls a model, and flag any path where OLLAMA_CONTEXT_LENGTH or a num_ctx override is absent or inconsistent with another path in the same repository. That is a read-only repo audit, not a live fix; apply the change with the steps below.

The Exact Symptom

GitHub issue ollama/ollama#13938, "Claude Code & Ollama context issues," collected ten comments before closing. The reported pattern is consistent:

• Claude Code sends a growing conversation, including tool definitions, file contents, and prior tool results, every turn.

• Ollama's serving default context window is far smaller than that payload once a session has a few tool calls in it.

• When the input exceeds the active context, Ollama drops the oldest tokens to make room. It does not return an error or a truncation warning.

• The visible failure looks like a reasoning problem: Claude Code re-reads files it already read, repeats a tool call, contradicts an instruction from CLAUDE.md, or claims a file does not exist that it opened two turns earlier.

• One reporter (krkartikay) set OLLAMA_CONTEXT_LENGTH=64000 and still hit the bug, because the variable was exported in the client shell that launched Claude Code, not in the environment of the process actually serving the model. Ollama's server process reads its own environment at the time it starts serving, not the environment of whatever later talks to it over HTTP.

Ollama's own documentation confirms the default is capacity-driven, not fixed: per docs.ollama.com/context-length, default context scales with available VRAM, from 4096 tokens below 24 GiB VRAM, to 32768 tokens between 24 and 48 GiB, up to 256000 tokens at 48 GiB and above. A model that silently drops context on a 12 GiB GPU can look completely healthy on a 48 GiB one with identical Claude Code settings, which is why this bug reads as intermittent across machines.

Why This Breaks Claude Code Specifically

Ollama's own Claude Code integration guide states the requirement plainly: Claude Code's tool-calling loop needs a context window large enough to hold system instructions, tool schemas, file contents, and multi-turn tool results together, and recommends 64k tokens or more for any real coding session. A 4k or 32k default, correct for a short chat, is not enough for one Claude Code turn with two or three files open.

Because the truncation happens inside Ollama's serving layer, Claude Code has no signal that it happened. It receives a normal-looking completion and keeps acting on an instruction set that is missing its beginning, which includes the system prompt and, if your repository uses one, CLAUDE.md. If other CLAUDE.md rules besides this one keep getting ignored even on hosted models, see Claude Code Not Following CLAUDE.md? Enforce the Guardrail for that separate, backend-independent diagnosis; this truncation issue is specific to local or self-hosted Ollama backends and is not explained by instruction scope or conflicts. If your symptom is tool calls failing outright against Ollama rather than silently losing earlier context, see Ollama Tool Calling Broken in GitHub Copilot? Roll Back 0.32.5 for that separate, version-specific regression.

The Fix: Set Context Length on the Server, Then Verify It

1. Identify the process that actually serves the model. This is the host running ollama serve, not the shell where you ran claude or set an environment variable for Claude Code itself.

2. Set the variable in that process's environment before it starts, not after:

   # on the machine/container running ollama serve
   export OLLAMA_CONTEXT_LENGTH=65536
   ollama serve

   For a systemd-managed install, set it in the unit's environment file instead of a login shell, since a user shell export never reaches a system service:

   # /etc/systemd/system/ollama.service.d/override.conf
   [Service]
   Environment="OLLAMA_CONTEXT_LENGTH=65536"

   Then reload and restart:

   sudo systemctl daemon-reload
   sudo systemctl restart ollama

3. If you call the model through the API directly instead of relying on the server default, set num_ctx in the request options, which overrides the server default for that call:

   curl http://localhost:11434/api/generate -d '{
     "model": "qwen2.5-coder:32b",
     "prompt": "test",
     "options": { "num_ctx": 65536 }
   }'

4. Make a request from Claude Code against the model, then check the loaded model on the serving host while it is still running:

   ollama ps

   Read the CONTEXT column for the exact model Claude Code used, and compare it with the intended allocation (65536 in this example). The official context-length documentation uses this command to check allocated context and the PROCESSOR column to check GPU/CPU offloading. If no model is listed, make another request and check before it unloads. If the allocation differs, inspect the serving process environment, model settings, and per-request overrides; a mismatch alone does not establish which setting caused it. /show parameters can help inspect model parameters, but it does not establish the effective server allocation for Claude Code's request.

When Raising num_ctx Alone Doesn't Fix It

A larger context window needs proportionally more VRAM for the KV cache, so raising num_ctx without enough free VRAM can cause Ollama to fail to load the model, silently fall back to a smaller context, or push inference onto slower shared memory. Check nvidia-smi (or your platform's equivalent) for headroom before and after the change, and recheck docs.ollama.com/context-length's VRAM tiers if the fallback appears to have reset to a default you did not request. If you are running multiple models or multiple Claude Code sessions against the same Ollama instance, each loaded model reserves its own context allocation, so the same symptom can return under concurrent load even after one successful ollama ps check.

Verify the Fix

Do not trust the setting until you see the failure mode stop under the same conditions that produced it:

1. Start a fresh Claude Code session against the Ollama backend and open two or three files larger than a trivial size.

2. Ask Claude Code to make several sequential tool calls that reference an early file or an early CLAUDE.md instruction.

3. Confirm it still follows that early instruction and does not re-read a file it already opened in the same session.

4. Run ollama ps on the serving host again after a real mid-session Claude Code request. Recheck the correct model's CONTEXT and PROCESSOR columns after a model reload or concurrent load, and investigate changes before treating the fix as verified.

Recheck this guide if Ollama changes its default VRAM-to-context mapping, if you move from a single-user setup to multiple concurrent Claude Code sessions sharing one Ollama instance, or if issue #13938 receives an upstream fix that surfaces truncation as an explicit error instead of a silent drop.

Sources and Method

• ollama/ollama issue #13938, "Claude Code & Ollama context issues," including the client-vs-server environment-scope detail from reporter krkartikay, inspected October 22, 2026.

• Ollama context length documentation, VRAM-tiered default context values, inspected October 22, 2026.

• Ollama Claude Code integration guide, 64k-token recommendation for coding sessions, inspected October 22, 2026.

• Cross-referenced against Claude Code Not Following CLAUDE.md? Enforce the Guardrail to confirm this is a distinct, backend-specific failure mode rather than an instruction-loading or conflict problem.