Agent Context

Can't Find the Claude Session That Had the Fix?

You know the fix was in a chat last week, but which one? Why AI sessions get lost across projects, and a simple habit that makes the right one a click away.

By Tu Nguyen · · 2 min read.md

A frustrated developer holds her head while scrolling a long list of chat sessions on a monitor.

You remember it clearly: last Thursday, the agent found why the build broke on release mode. Something about a flag. It’s in one of your chats. You open the resume list and scroll. Twenty sessions. Most are titled with the first thing you typed — “ok so”, “quick question”, “continue”.

Fifteen minutes later you give up and ask the agent to find the bug again.

Part 3 of Working for the AI — after the copy-paste trap and re-explaining your project.

Why sessions get lost

With one project, the most recent session is usually the right one. With several projects and several sessions a day, three things go wrong:

  • The list is long and unlabelled. Session titles come from the first message, which is rarely useful.
  • Sessions live per folder. Start a session in the wrong directory and it won’t appear where you look.
  • One session drifts across tasks. You fix the build, then ask about the icon, then the store text. Now the “right session” for any of those is buried in a long, mixed conversation.

Habit 1: one task, one session

Start a fresh session for each task, and stay on that task. It’s easier to find, the context stays focused, and the agent isn’t carrying irrelevant history from the last three things you asked.

Habit 2: write the session id next to the task

When a session matters, note its id next to the task — in the same state file as the phase and next step:

Task:    release build crash
Phase:   3/6 — build
Next:    re-enable minify after the flag fix
Session: 8f2c…e41   (claude --resume 8f2c…e41)

Now “which chat had the fix?” is a lookup, not a search. From the project folder, claude --resume <id> opens exactly that conversation.

Habit 3: don’t leave the answer only in the chat

The real lesson from a lost session is that something important lived only in a conversation. When a session finds a fix or makes a decision, ask the agent to write it into the state file:

“Add to the notes: release build needs flag X because Y.”

Then even if the session is gone for good, the answer isn’t. This is the whole point of memory living in files.

When you can’t find it anyway

Don’t spend fifteen minutes scrolling. Start a new session, point it at the state file, and describe the symptom. If the notes are good, it will get there faster than your search would.

Where ShotMatic fits

ShotMatic stores which Claude session belongs to which task, locally. ✦ on a task opens Terminal on claude --resume with the exact id in the right folder — or starts a new session with the task’s context if none exists yet.

FAQ

How do I resume a specific Claude Code session?

Run claude --resume with the session id, from the project's folder. Without an id you get a picker of recent sessions, which is fine for one project and slow for many.

Why can't I find my old Claude sessions?

Sessions are stored per folder, so a session started in the wrong folder won't show up where you look. With several projects and several sessions a day, the recent list also fills up quickly.

Should I keep one long session per project?

No. One session per task is easier to find and keeps the context focused. Put what matters across tasks in a state file in the repo.