Why does Claude Code forget your setup every session? (CCA-F D3)

What changed

Coding agents like Claude Code, Cursor, and Codex now hold real context across a session. The repo, the recent edits, the open files (🟢 first-hand: Claude Code keeps project context across a session and reads a CLAUDE.md project file on startup). So it feels like the agent "knows" your project.

But context is not procedure. The agent can know your files and still not know your setup steps, your review checklist, or how you verify a change. Those are instructions, not context, and if they are not written down, you re-type them every session.

That re-typing masquerades as work. Tabs switch, prompts grow, context gets pasted. Visible motion, nothing moving forward.

Memory of context vs memory of procedure

How procedural debt actually accrues

The tell is four symptoms that travel together:

• Prompt bloat. Prompts keep growing because you keep adding the setup back in.
• Re-explanation tax. The same instructions every session, paid in your time.
• Instruction fragmentation. Rules live in scattered chats, not one place.
• Weak verification. The check gets remembered inconsistently, so it slips.

The non-obvious part is that this is not a memory failure. It is a workflow design failure. If the same playbook keeps coming back, the process is not encoded.

Worked example - "tool-switching that feels productive."

1. A team moves between Claude Code, Cursor, and Codex, re-explaining setup, review rules, and verification each time.
2. It feels like progress because there is motion, but the same instructions keep returning.
3. The fix is not a better model. Put the procedure in a canonical runbook (CLAUDE.md or AGENTS.md), keep one checklist for setup, execution, and verification, and compress prompts into invariants.
4. Now the agent reads the procedure on startup, subagents inherit it, and the re-explanation tax goes to zero.

A name for it: Procedural Debt

Procedural Debt - the recurring cost of re-explaining your operating procedure to an agent that already has your code context. It looks like a memory gap, but it is a workflow gap: the procedure was never encoded, so you pay the explanation every session. You pay it down by writing the procedure once, in config the agent reads, not by buying more memory or a stronger model.

Why it matters for CCA-F

This sits in D3 - Claude Code Configuration and Workflows, which is 20% of the exam, and connects to agent instruction files and subagent CLAUDE.md inheritance.

The proprietary read: D3 questions reward encoding procedure in config over re-prompting it. The CLAUDE.md is not a nicety, it is where the operating procedure lives so the workflow stops depending on your memory.

• Old instinct: the agent forgot, so add memory or use a stronger model.
• D3 instinct: the procedure was never written down, so encode it in CLAUDE.md.

The distractor pattern to memorize. On D3 scenarios where every session restarts with the same setup and the build drags, the trap answer is "add memory" or "switch to a stronger model." The architecturally correct move is one of:

1. Write the procedure into CLAUDE.md so the agent reads it on startup, or
2. Standardize one checklist for setup, execution, and verification across tools, or
3. Encode verification in hooks (see debugging Claude Code hooks) so the check runs without being re-explained.

How to apply it

1. Write the runbook. Put setup, review rules, and verification in CLAUDE.md (or AGENTS.md).
2. One checklist, every tool. Use the same setup-execute-verify list across Claude Code, Cursor, and Codex.
3. Compress prompts into invariants. Encode the stable rules once; stop re-pasting essays.
4. Let subagents inherit it. Lean on CLAUDE.md inheritance so one runbook covers the whole tree.
5. Treat repeated setup as waste. If the same instructions keep coming back, that is the debt. Encode it and delete the re-explanation.

The meta-skill, and the D3 exam skill, is the same: perfect memory is not reusable procedure. If the agent needs the same playbook every session, the fix is in the workflow, not the model.