Claude Code session keeps losing context mid-task - am I doing something wrong?

[BittuChan]

Hello everyone,

I've been using Claude Code for about 2 weeks now and it's honestly been great for most stuff, but I keep running into this annoying issue where it seems to "forget" what we were working on.

What's happening:

I'll start a session working on, say, refactoring a Rust module. We'll get 15-20 messages deep, Claude understands the codebase structure, knows which files we're touching, everything's going smooth.

Then suddenly it'll:

• Ask me to "clarify which file we're working on" (when we've been editing it for 10 minutes)
• Suggest changes to a function we already refactored 5 messages ago
• Lose track of the overall goal and start suggesting unrelated improvements

Example from yesterday:

Me: "Okay now let's add error handling to the parser"
Claude: "I don't see a parser in this codebase. Could you point me to it?"

...when we literally just spent 30 minutes building the parser together.

My setup:

• Claude Code via npm (latest version, I think 0.3.x?)
• Working on a Rust project (~8k lines across 15 files)
• Session usually runs for 45min - 1hr
• Running on Windows 11 with Git Bash

What I've tried:

• Keeping messages shorter (doesn't seem to help)
• Explicitly referencing file paths in every message (tedious and still happens)
• Starting fresh sessions more often (works but kills productivity)

Questions:

1. Is there a context window limit I'm hitting? Does Claude Code have a different limit than regular Claude?
2. Should I be using the TASKS.md or some other file to help maintain context?
3. Am I just expecting too much from the session memory?

I've seen people working on huge refactors across multiple sessions so I feel like I'm missing something obvious here.

Any tips appreciated!

[Shiven0504]

Hey @BittuChan, thanks for sharing your problem, I think I figured out what was going on after reading through some other discussions and experimenting more.

TL;DR: I wasn't using the session persistence pattern correctly. Claude Code doesn't automatically maintain context across the full conversation - you need to explicitly anchor it.

What actually fixed it:

1. Started using TASKS.md + CLAUDE.md pattern

Created two files in my project root:

TASKS.md - What we're working on right now:

## Current Task: Refactor parser module for better error handling

**Goal:** Add comprehensive error types and propagate them properly through the parse chain

**Files in scope:**
- src/parser/mod.rs (main parser logic)
- src/parser/error.rs (NEW - error types)
- src/parser/token.rs (token definitions)

**Progress:**
- [x] Defined ParseError enum
- [x] Updated parse_expression to return Result<Expr, ParseError>
- [ ] Add error recovery for unclosed delimiters
- [ ] Write tests for error cases

**Next steps:**
1. Implement error recovery in parse_block()
2. Add source location tracking to errors

CLAUDE.md - Context that persists across sessions:

## Project Context

This is a Rust-based configuration file parser for a custom DSL.

**Architecture:**
- Lexer: src/lexer/ - tokenizes input
- Parser: src/parser/ - builds AST  
- Evaluator: src/eval/ - executes AST
- REPL: src/main.rs - interactive mode

**Conventions:**
- All errors use anyhow for the public API
- Internal parser uses custom ParseError
- Tests in same file as implementation (Rust convention)

Now when Claude starts losing context, I just say "check TASKS.md" and it immediately gets back on track.

2. Realized I was working in too many files at once

Claude Code seems to handle 3-4 active files really well, but when I had 7-8 files open across different modules, that's when context got wonky.

New workflow:

• Focus on one logical unit at a time
• Finish that completely before moving to the next module
• Update TASKS.md when switching focus areas

3. Used explicit checkpoints

Every 20-30 minutes or at natural break points, I do:
"Let's summarize what we've done so far and update TASKS.md"

Claude then writes a clean summary of changes, updates the task list, and this seems to "reset" its understanding of where we are.

Results after changing approach:

Just finished a 2-hour session refactoring the entire error handling system across 6 files. Zero context loss. Claude remembered function signatures, our naming conventions, everything.

The difference:

• Before: "Which file are we working on?" every 15 minutes
• After: Smooth continuous conversation, Claude references earlier decisions correctly

[Shiven0504]

One more thing I learned:

If Claude does lose context mid-session, instead of restating everything manually, I now do:
"Read TASKS.md and CLAUDE.md, then let's continue with step 3"

This is way faster than re-explaining the entire context. So yeah, my mistake was treating Claude Code like it had infinite perfect memory. It's more like pair programming with someone who takes really good notes but you have to actually write the notes first.

[BittuChan]

Hii @Shiven0504, This was super helpful, thanks for documenting!

Also i wanna ask - do you keep TASKS.md under version control or is it more of a scratch file?
I've been hesitant to commit it because it changes constantly during development, but also seems useful to have the task history...

[Shiven0504]

I actually do both:

TASKS.md → Gitignored (changes every few minutes, very ephemeral)
CLAUDE.md → Committed (stable project context, useful for other contributors)

My .gitignore:
TASKS.md
.claude-session/

You tend to have a task history for future reference, but the active stuff is still in a scratch file. I'm personally sticking with the gitignore approach for now since I tend to write messy WIP notes that I don't want in the repo, but the dev log pattern seems cleaner for teams.

[affaan-m]

Maintainer update: the community answer here is the model I would recommend for current ECC usage.

Claude Code still has a finite context window, and ECC can make that better or worse depending on how much you load. The practical fix is to keep stable project facts in CLAUDE.md, keep live task state in a small TASKS.md or checklist, and checkpoint before switching modules. For a refactor, I would keep the active surface to a few files, finish one logical unit, update the task file, then compact or start a fresh session from that state.

Two ECC-specific notes:

1. If you installed a broad surface, trim it. The low-context path in the README is there because loading every skill, MCP, hook, and rule can waste context on things unrelated to the current task.
2. Use /checkpoint and logical /compact breaks rather than relying on the model to remember every decision from a long conversation.

We are also folding this into the ECC 2.0 context/progress work so the default guidance is less "install everything" and more "load the smallest useful surface, with explicit recovery points."

[chenhz01]

Building on affaan-m's answer — the addition I'd make is about when the anchor gets written. Manual TASKS.md updates fail exactly when you need them: your symptom (asked which file, 15 messages in) is the compaction boundary having fired, not the raw window filling up.

Have scripts/hooks/pre-compact.js write the active surface, and session-start.js read it back:

write('.ecc/active-surface.md', {goal, files: touched.slice(-10)})

Goal plus last N touched files re-anchors a session; a full transcript dump does not — it just re-costs you the window.

Want me to take a crack at it?