Claude Code Doesn't Remember. Here's How I Fixed That.

Source: Dev.to

Claude Code: Managing Long‑Running Tasks

Claude Code is remarkably capable—it can read codebases, write code, run tests, and create pull requests.
The problem is continuity. As conversations grow, earlier context gets compacted, token costs rise, and response quality degrades. Finding an old conversation is also difficult because Claude Code’s conversation management is minimal. The result: complex tasks that span multiple sessions lose their thread.

Over the past several months I’ve built two patterns that changed how I work with Claude Code:

1. Execution plans that survive across sessions
2. Persistent knowledge about any codebase, even repos you don’t own

Both are simple to set up and compound over time.

---

Plans That Survive Across Sessions

Real work rarely fits in a single conversation. A feature might span several files, require multiple commits, and take days. Claude Code starts fresh every session, so you lose the thread and must re‑explain what’s already been done, what’s left, and what decisions were made.

I solved this with GitHub issues as execution plans, managed by a set of custom Claude Code skills (simplified versions are published at claude‑plan‑skills).

Workflow (four stages)

Example of a plan issue

# Feature: Add user‑profile page

**Description**  
Implement a new user‑profile page that displays the user's avatar, bio, and recent activity.

**Steps**  
- [ ] Create `UserProfile` component  
- [ ] Add route `/profile/:id`  
- [ ] Fetch user data from API  
- [ ] Write unit tests for the component  
- [ ] Update navigation menu  

**Relevant links**  
- Design mockup: https://example.com/mockup  
- API spec: https://api.example.com/spec  

**Notes**  
- Use the existing `Avatar` component for consistency.  
- Follow the project's CSS naming conventions.  

With this pattern, each session can start from the last saved state, eliminating the need to repeat context and keeping the work organized across days or weeks.

Description

What

Add a new validate subcommand that checks config files for syntax errors before deployment.

Why

Users currently discover config errors only at deploy time, which wastes CI minutes and blocks releases.

Steps

• Add CLI argument parsing for validate subcommand
• Implement config file parser with error reporting
• Add unit tests for valid and invalid configs
• Update help text and README

---

Example CLI Flow (Mermaid Diagram)

flowchart TD
    A[Start] --> B{Parse args}
    B -->|validate| C[Load config]
    C --> D{Valid?}
    D -->|yes| E[Run validation]
    D -->|no| F[Show errors]
    E --> G[Exit 0]
    F --> G[Exit 1]

The diagram above visualizes the flow of the validate subcommand.

---

Personal Context for Every Project

The plan cycle solves the “losing the thread” problem, but there’s a second, more subtle kind of context loss.

Claude reads CLAUDE.md files for project‑wide context. These files are committed to the repository and serve as the team’s shared knowledge base. However, contributors often need personal context that is too specific to be stored in a shared file (e.g., custom test commands, modules they specialize in, personal conventions).

CLAUDE.local.md

Claude also reads a file named CLAUDE.local.md from the project directory. It works exactly like CLAUDE.md but is intended for personal, uncommitted context.

Example Directory Structure

ai-memory/
  claude/
    some-oss-project/
      CLAUDE.local.md
    my-teams-service/
      CLAUDE.local.md
    infra-tools/
      CLAUDE.local.md

Sample CLAUDE.local.md

# CLAUDE.local.md

## Personal Test Commands
```bash
# Run unit tests with coverage
pytest -q --cov=src tests/

Owned Modules

• auth.service
• payment.gateway

Architecture Notes

• The payment service communicates with the external Stripe API via a thin wrapper.
• All async code uses asyncio and follows the project’s async style guide.

Conventions

• Use snake_case for function names.
• Prefer TypedDict over plain dictionaries for structured data.

> **Tip:** Keep `CLAUDE.local.md` in a private repository (e.g., `ai-memory`) so it’s never committed to the shared codebase, yet Claude can still access it when working locally.

## My test commands

Run the integration tests I usually work with:

```bash
mvn test -Dtest=ClassName#methodName -Pintegration

Areas I Work On

• Config parser module – src/main/java/config/
• Validation pipeline – src/main/java/validate/

Conventions I’ve Learned

• Commit messages – use Conventional Commits (feat:, fix:, chore:)
• Pull requests – must reference an issue number
• Imports – avoid wildcard imports

---

Personal Claude Context

I symlink a personal CLAUDE.local.md file into each project’s checkout:

~/git/some-oss-project/CLAUDE.local.md
  → ~/git/ai-memory/claude/some-oss-project/CLAUDE.local.md

Now, when I open Claude Code in any project, it automatically picks up my personal context alongside the project’s shared CLAUDE.md. No re‑explaining is needed.

The ai-memory repository is private and version‑controlled, so the knowledge accumulates. Whenever I learn something new about a project—a test quirk, a build flag, a convention I picked up from a code review—I add it to the file. Every future session benefits.

---

Beyond These Two Patterns

These two patterns are the foundation, but they’re not the whole setup. I also use:

• A granular permission model that controls what Claude can do without asking.
• An instruction that prevents Claude from speculating about code it hasn’t read.
• Custom skills that handle the back‑and‑forth of GitHub PR reviews (some of which I’ll cover in a future post).

---

The Edge Is Judgment, Not Config

Everything described here is simple to set up:

1. A private repo with markdown files.
2. GitHub issues with checkboxes.
3. A few custom skills.

None of it is technically impressive.

The real value lies in knowing what to put in a CLAUDE.md file, how to break a task into steps that Claude can execute reliably, and when to let Claude work autonomously versus when to intervene. That judgment comes from using these patterns daily and refining them based on what actually works.

If you try these patterns, you’ll develop your own version of that judgment. The config files are the starting point, not the destination.