Why Does Claude Code Lose Track Mid-Task?

TL;DR: Claude Code loses context mid-task, and loses track with it, for six distinct, documented-or-observed reasons. Tool output fills the window, compaction summarises away anything only spoken, an over-long CLAUDE.md competes with the task, the task is too large for one session, rules contradict each other, or a decision from 40 turns ago was never written down. None of them is fixed by waiting it out.

Why Does Claude Code Lose Track Mid-Task?

Because the context window holds everything at once: instructions, files it read, past responses, and the conversation so far. That window is finite. When something has to give, the model doesn't announce what it dropped; it just acts on what remains. That's why "losing track" rarely looks like an error. It looks like the agent quietly redoing finished work, contradicting a decision from ten minutes earlier, or forgetting a constraint you stated once and never wrote down.

This page isn't the general discipline of keeping an agent's context lean; that's context engineering for coding agents, and what belongs in your project file specifically is in CLAUDE.md best practices. This page is the failure itself: what it looks like, which of six mechanisms caused it, and the fix for each.

What Does "Losing Track" Actually Look Like?

Four patterns, from observing sessions rather than any vendor page:

• Re-reading or re-implementing something already built earlier in the same session.
• Stating a plan, then acting a few turns later as if it never existed.
• Following a CLAUDE.md rule correctly for a while, then dropping it with no visible trigger.
• Asking, right after a "Conversation compacted" message, a question you already answered.

Each maps to a specific, mostly documented cause below.

Why Does the Context Window Fill With Tool Output Before the Task Even Gets Hard?

Because every file read, every test run, and every log dump enters the window in full and stays there unless something removes it.

Anthropic's own best-practices documentation names this as a recognised failure pattern: "The infinite exploration." In the documentation's own description, it happens when you ask Claude to investigate something without scoping it, and Claude reads hundreds of files, filling the context. Its documented fix is direct: "Scope investigations narrowly or use subagents so the exploration doesn't consume your main context." Subagent delegation and hook-based output filtering are the deeper mechanics, covered properly in context engineering for coding agents, so this page won't re-derive them.

What's worth adding here is the diagnostic angle: if the agent starts losing the thread only after a long exploration phase, tool output is the first place to look, not the instruction file. Run /context before you dispatch a large investigation and again partway through. If the growth is mostly file contents and command output rather than conversation, that's your answer.

What Does Compaction Actually Discard, and What Comes Back?

Some of it reloads automatically. Most of it, if it was only ever conversation, does not.

Per Claude Code's context-window documentation, the system prompt, project-root CLAUDE.md and unscoped rules, auto memory, and any plan written in plan mode all reload this way; the documentation's own label for that row is "Re-injected from disk". Rules with paths: frontmatter and nested CLAUDE.md files come back only when a matching file is read again. Up to five recently touched files are partially restored, most recently modified first. Everything else, including the conversation itself, is summarised into prose. That last bucket is where a mid-task decision disappears.

There's a genuinely underused way to control this instead of accepting the automatic pass. Checkpointing's /rewind menu offers Summarize from here and Summarize up to here, compressing part of a session on your terms: "freeing context window space" while, per the same documentation, "the original messages stay in the session transcript, so Claude can still reference the details." If a session is getting heavy mid-task, that's a scoped alternative to waiting for automatic compaction to guess what matters.

Why Does an Over-Long Instruction File Compete With the Task Itself?

Because CLAUDE.md loads at the start of every session and is charged against the same budget as everything else, whether or not most of it applies to today's task.

Anthropic states this plainly, not as a guideline but as an observed failure: "Bloated CLAUDE.md files cause Claude to ignore your actual instructions!" The documentation's own size guidance is a target of under 200 lines per file, with Claude Code skipping anything over 4 MiB outright. Splitting a long file into imports doesn't help: "Splitting into @path imports helps organization but doesn't reduce context, since imported files load at launch." Four 100-line files behind imports cost exactly what one 400-line file costs.

This page won't re-teach what belongs in that file. CLAUDE.md best practices covers the removal test and a worked audit, and CLAUDE.md templates for Claude Code has copy-paste starting points. The narrower point here: if the agent is dropping instructions specifically, not forgetting task state generally, check the file's length first.

Is the Task Genuinely Too Large for One Session?

Sometimes, yes. Pushing through produces exactly the symptom this page is about.

Anthropic's own guidance names the diagnostic question directly: "Was the context too noisy? The prompt too vague? The task too big for one pass?" A related failure pattern the same documentation names directly: "The kitchen sink session." Its own description: "You start with one task, then ask Claude something unrelated, then go back to the first task. Context is full of irrelevant information." A 40-file migration and a 4-file bug fix aren't the same shape of task; treating them identically is how a session on track ends up somewhere around file 25 with half its original constraints gone.

The fix is scoping before you start, not correcting after drift. Decide what one session covers and write that scope down, in the prompt or better as a plan mode plan, which reloads from disk rather than only living in conversation. A task that stops early for a different reason, the model deciding it's done rather than losing the thread, is covered separately in why does the model stop before finishing the task.

Why Do Conflicting Instructions Make Claude Flip-Flop Mid-Task?

Because Claude Code doesn't resolve contradictions for you. It concatenates every discovered CLAUDE.md and rule into context, and if two of them disagree, something has to give.

The documentation is explicit: "if two rules contradict each other, Claude may pick one arbitrarily." It recommends reviewing "CLAUDE.md files, nested CLAUDE.md files in subdirectories, and .claude/rules/ periodically to remove outdated or conflicting instructions." The same documentation states the broader compliance limit elsewhere: content is "delivered as a user message after the system prompt," and "there's no guarantee of strict compliance, especially for vague or conflicting instructions." A rule that contradicts what you just typed in chat is the sharpest version of this: two live, disagreeing instructions in the same window, and no documented tie-breaker favors either one.

The fix is a periodic audit, not a stronger phrasing of either rule. Read your user-level file and your project file side by side, and delete the loser rather than letting the model choose one at random mid-task. A related but distinct failure is the agent overstepping a scope boundary entirely rather than picking between two rules; that one is covered in why does AI rewrite code I didn't ask it to touch.

Why Does Relying on Something Said 40 Turns Ago Fail?

Because anything that only ever existed in conversation is exactly what compaction is built to summarise away.

This is the cause behind the largest share of "it forgot" reports, and the most avoidable one. A decision made verbally, "let's use the v2 endpoint, not v1", lives in message history and nowhere else, right up until the session compacts, at which point it becomes a sentence in a summary at best, or nothing at all. Anthropic doesn't publish how instruction files are weighted against conversation history, or what compaction discards in any specific run. Treat "the decision might not make it" as the working assumption for anything spoken and not written.

Claude Code documents one mechanism aimed at this gap: auto memory. On by default, it saves notes Claude judges worth keeping ("corrections you give Claude and approaches you confirm", "ongoing work, deadlines, and decisions that Claude can't derive from the code or git history") into a file that reloads every session. That's a real backstop, but a judgment call, not a guarantee: "Claude doesn't save something every session. It decides what's worth remembering based on whether the information would be useful in a future conversation." The reliable version: the moment a decision matters, put it in CLAUDE.md if permanent, or the plan if scoped to this task.

Checkpointing Is Recovery, Not Prevention

Checkpointing solves a different, related problem. It doesn't stop the context window from filling; it gives you a way to act once you notice something has gone wrong.

Claude Code "automatically tracks Claude's file edits as you work, allowing you to quickly undo changes and rewind to previous states if anything gets off track." Every prompt creates a checkpoint, and /rewind restores code, conversation, or both, to any earlier point. That's useful once a mid-task drift has already produced a wrong edit: revert the file, keep the rest of the conversation, then re-send a corrected instruction.

What it doesn't do is stop the underlying cause. Rewinding conversation doesn't shrink the context that caused the drift; only the two Summarize options free context space deliberately. It also only tracks edits made through Claude's own file tools. For changes a bash command makes, the documentation is direct: "These file modifications cannot be undone through rewind." The same holds for most subagent edits. Treat checkpointing as your undo button, not insurance against the six causes above.

The Honest Limit: You Cannot Make Claude Code Immune to This

Every fix here reduces how often the context window becomes the bottleneck. None makes the bottleneck go away, because the window is finite by design and shared by everything competing for it.

Two things are genuinely undocumented, worth saying plainly rather than guessing. Anthropic doesn't publish how instruction files are weighted against conversation history short of an outright contradiction, and it doesn't document what compaction discards in any specific run: the behaviour is described in categories, not as a guarantee about your session. Anywhere this page named a specific outcome, it came from a dated vendor page; anywhere it described a pattern instead, that's observation, labeled that way on purpose.

Given that, the durable responses are structural, not clever:

1. Write decisions down in a file the moment they matter, rather than trusting them to survive in conversation. CLAUDE.md for anything permanent, a plan mode plan for anything scoped to the current task.
2. Scope one task per session. A session that starts one job and picks up a second mid-stream is carrying two sets of constraints in one budget.
3. Start fresh rather than push through. A session already carrying failed approaches and stale context is not the session to keep correcting.
4. Keep always-on context short. Everything in CLAUDE.md is paid for on every single request, whether or not today's task touches it.

A Mid-Task Recovery Checklist

Work through this when you notice drift, not after the task is finished:

1. Run /context and read what's actually loaded right now.
2. Decide whether the missing piece is CLAUDE.md-based, plan-based, or conversation-only, and write it down immediately if the last one applies.
3. Look for two instructions disagreeing, one in a file, one spoken, before assuming the model is simply wrong.
4. If drift started after a long exploration phase, suspect tool output first; if CLAUDE.md is over 200 lines, suspect that next.
5. Check the task's actual scope against what one session can hold.
6. Use /rewind to restore code or conversation to before the drift, or Summarize from here to free space on your own terms.
7. After a /compact, re-verify that a decision you cared about survived rather than assuming it did.
8. If the same correction is needed twice, stop and restart with a better initial prompt.
9. Confirm auto memory is on if you want a backstop, but don't treat it as a substitute for writing things down.

Copy-Paste Prompts for Keeping Claude Code on Track

These are prompts you send, not settings you configure. Use them at the point in a session where the corresponding cause is likely.

Before a large task, force a written plan instead of a running mental model:

Before writing any code, list the exact scope of this task: which files
change, which don't, and any constraint I've stated that must hold. Save
that as a plan I can review before you start.

Scope an investigation so it doesn't fill the window on its own:

Investigate only src/auth/ and src/api/session.ts for how login state is
stored. Do not read the rest of the codebase. Report findings before
touching anything.

Persist a decision the moment you make it, instead of trusting it to survive in conversation:

We just decided: use the v2 endpoint everywhere, not v1. Add this to
CLAUDE.md right now as a standing rule, don't just note it in this reply.

Check whether a rule actually survived, right after a compaction:

Before continuing, tell me: what do you currently believe our build
command is, and where did that come from: CLAUDE.md, a rule, or this
conversation?

Guide a compaction instead of accepting the automatic pass:

/compact focus on the current bug fix and the test failures, drop the
earlier exploration of alternatives we already ruled out

Recover with a targeted summary instead of a full /compact:

/rewind

then select the message where the session started to feel heavy and choose Summarize from here, adding "keep the API contract we agreed on" when prompted.

Audit for contradicting instructions before assuming the model is wrong:

List every instruction you're currently following that touches how I want
commits formatted. If more than one source disagrees, tell me which ones
and which you picked.

Scope a session to exactly one task, written down before work starts:

This session is scoped to one task only: fixing the rate limiter race
condition in src/middleware/rateLimiter.ts. If I ask you something
unrelated, remind me to start a new session instead.

Re-enter a task cleanly after starting a fresh session:

New session. Context from before: we're migrating the auth module from
sessions to JWTs. Files touched so far: auth/session.ts, auth/jwt.ts (new).
Decision made: refresh tokens are httpOnly cookies, not localStorage.
Continue from there.

Force a two-strikes stop instead of a third correction:

That's the second time this hasn't worked. Stop. Tell me what you now
understand about why, then wait for me to give you a new prompt instead
of trying again.

Confirm what actually reloaded after the session got long:

/context

then compare the Memory files list against what you expect to be loaded. A missing entry is the fastest way to catch a stale or unloaded CLAUDE.md.

Where Prompt Architects Fits, and Where It Doesn't

We run an MCP server at https://mcp.prompt-architects.com/mcp that Claude Code, along with Claude Desktop, Claude.ai, Cursor, Codex, and Codex CLI, can connect to (setup and scopes are covered in using MCP inside Claude Code), exposing prompt tools named improve, refine, shorten, and enhance so the instruction you hand the agent gets tightened before it ever reaches the window. That's a real, if narrow, help against one of the six causes above: a clearer prompt is less likely to be misread as a contradiction, and a shorter one costs less of the budget you're protecting.

What it isn't is a context manager. The server doesn't read chat history, is stateless beyond the current tool call, and has no view into your CLAUDE.md, your plan, or what a compaction pass kept. Whether a decision survives mid-task is entirely between you, your files, and Claude Code's own memory and compaction mechanics, not an MCP-connected prompt tool.

Losing track mid-task is not a bug you patch once. It's the finite-window trade-off surfacing in six different, mostly avoidable shapes. The fixes that hold are the boring ones: write it down, scope it, and start clean when the session is already carrying too much.