Crash Protection for AI Coding Sessions: How Breadcrumbs Keep You Moving

The Crash That Costs You an Hour

You have been working with Claude for two hours on a complex refactor. The architecture is mapped out, four subtasks are planned, and you are halfway through the third one. Then the CLI crashes. Or your laptop reboots. Or the network drops on a remote session.

When you start a fresh session, Claude has no memory of what just happened. It can see your files on disk and your git history, but the working state — which subtask you were on, what you had just finished, what the next step was — is gone. Re-deriving that state from the codebase and commit log can take twenty minutes or more. On a bad day, it takes longer than that.

This is the crash recovery problem, and it is different from the context loss problem. Context loss happens when auto-compaction discards earlier conversation. Crash recovery is about losing everything — the entire session state — in an instant.

What Actually Survives a Crash

When a CLI crash or reboot happens, here is what persists and what does not:

Survives:

• Files you wrote or edited (they are on disk)
• Git commits
• Every context_set call (durable SQLite write)
• Every todo_start, todo_complete, todo_create (durable SQLite write)
• Auto-memory files (they are on the filesystem)

Lost:

• The conversation transcript (depending on the crash mode)
• In-session task checklists
• Anything Claude "knew" but had not written down
• Partial uncommitted code changes may or may not survive

The key insight: context_set is the lowest-friction durable write tool available. One call, fast, atomic, persisted to SQLite. That makes it uniquely suited to be the in-flight working memory that survives anything.

The Breadcrumb Pattern

The idea is simple. For every active task, maintain a single context key that describes exactly where you are:

mcp__todo-mcp__context_set key:"task_#42_progress" value:"
DONE: Auth provider configured, PKCE flow implemented
NOW:  Session middleware — wiring httpOnly cookie storage
NEXT: Integration tests for login/logout cycle
BUILD: App compiles clean, 12/14 tests passing
"

This breadcrumb gets updated after every meaningful step: when a subtask completes, before any long-running operation (builds, full test suites), after every build or test result lands, and whenever work shifts from one file or subsystem to another.

The cost is negligible — less than 100 milliseconds per write. Updating the breadcrumb five to ten times per hour during active work adds up to maybe one second of total tool time. The payoff is the entire next session of work it would otherwise take to re-derive.

Three Recovery Scenarios

A crash mid-sprint lands a fresh Claude instance in one of three states. The breadcrumb disambiguates them immediately.

Scenario A: Task Partly Done

The task list shows a task in progress. The breadcrumb has both DONE and NOW fields. Recovery is straightforward: verify that what DONE claims actually landed (check the files, check git status), then continue where NOW says.

● mcp__todo-mcp__context_resume()
  Task «#42» in_progress

● mcp__todo-mcp__context_get key:"task_#42_progress"
  DONE: DeviceRole.swift slim version landed, LocalSyncService rewritten
  NOW:  SyncCoordinator surgery — replacing startMasterSession
  NEXT: SyncStatusView stub (placeholder)
  BUILD: not yet attempted post-rewrite

Claude knows exactly what to do: continue the SyncCoordinator work, then stub SyncStatusView, then build.

Scenario B: Task Done But Not Marked Complete

The task list shows a task in progress, but the breadcrumb has no NOW or NEXT — just a final state. Verify completion against the spec, then mark it done and clean up.

● mcp__todo-mcp__context_get key:"task_#42_progress"
  DONE: All subtasks complete. Tests passing. Committed as abc1234.
  BUILD: Clean build, 14/14 tests passing

● mcp__todo-mcp__todo_complete task_id:"#42"
● mcp__todo-mcp__context_delete pattern:"task_#42_*"

Scenario C: Task Just Started

The task list shows a task in progress but the breadcrumb has only an opening line. Re-read the task spec, plan the subtasks, write the first real breadcrumb, and proceed.

In all three scenarios, recovery is precise. No codebase re-derivation needed. No guessing about what happened before the crash.

When to Update the Breadcrumb

The pattern works because updates happen at natural checkpoints, not on an artificial schedule:

• After each subtask completion — the most common trigger
• Before any operation that takes longer than a couple of minutes — builds, full test suites, large rename passes
• When context shifts — moving from one subsystem or file to another
• Before any irreversible action — file deletes, force-pushes, schema migrations
• After every build or test result — "app compiles clean" is durable knowledge worth preserving

Cleanup on Completion

When a task closes, delete the entire namespace in one call:

mcp__todo-mcp__context_delete pattern:"task_#42_*"

Most tasks accumulate just one key (the progress breadcrumb), so cleanup is simple. Complex tasks that grew additional keys — a decision log, open questions — get cleaned up in the same pattern-delete.

The Math

A context_set call takes less than 100 milliseconds. Updating the breadcrumb five to ten times per hour during active work adds up to about one second of total tool time.

Compare that to the alternative: after a crash, Claude spends ten to twenty minutes reading files, checking git status, and trying to piece together what was happening. The breadcrumb is a strong trade — spend a fraction of a second per subtask, save significant time on every crash recovery.

How It Fits Into the Bigger Picture

The breadcrumb pattern works alongside three other systems that each handle a different concern:

• Auto-memory handles stable knowledge that should auto-load every session — preferences, lessons learned, project context
• Todo-MCP tasks handle strategic work units with permanent IDs, dependencies, and archival
• TaskCreate handles the in-session subtask checklist that you see updating live in your terminal

The breadcrumb (todo-mcp context) is the crash-protection layer. It is the only system with cheap, frequent, durable writes. Auto-memory writes are multi-step and too heavy for high-frequency updates. TaskCreate state lives in the session and does not survive a crash. The breadcrumb fills the gap.

Together, these four systems mean a CLI crash mid-task lands you at a clean recovery point: the breadcrumb tells you where you were, todo-mcp tasks tell you what is in progress, and auto-memory tells you the broader project context.

Getting Started

If you are already using Todo-MCP, the breadcrumb pattern requires no new tools or configuration. It uses the same context_set and context_get calls you already have. The mastery documentation included with your installation covers the full protocol, including the structured template and the cleanup cadence.

If you have not tried it yet, the breadcrumb pattern is one of the reasons Todo-MCP exists: giving your AI coding assistant a durable working memory that survives anything the real world throws at it.