Shoot Your Claude Code in the Head

You've been going back and forth with Claude Code for forty-five minutes. It was so close three turns ago. So you nudge it again. And again. Each reply is a little more confident and a little more wrong, and now you're writing paragraph-long corrections into a box.

Stop. Put it down.

The single most valuable skill in agentic coding isn't writing the perfect prompt. It's recognizing a dead session and having the nerve to kill it. "Shoot it in the head" is what a certain kind of engineer says about a wedged process — you don't attach a debugger, you don't reason with it, you kill -9 and start it clean. That same instinct is what separates people who move fast with Claude Code from people who fight it all afternoon. When a session goes bad, you don't rescue it. You put it down and open a fresh one that's smarter for what the dead one taught you.

Here's when, why, and how — without losing a thing.

Why sessions rot

A Claude Code session is a growing pile of context: your instructions, every file it read, every command it ran, every edit it tried, and every wrong turn it took. On each turn, the entire pile is fed back through the model. Two consequences follow that people underestimate.

Mistakes are sticky. Once a wrong assumption is in the context — a misread of your schema, a hallucinated function name, a bad mental model of your architecture — it doesn't fade. It sits there and anchors every turn after it. The model keeps "remembering" the wrong thing because the wrong thing is right there in the prompt, on every single request.

Noise crowds out signal. Fifteen failed attempts at the same fix are fifteen examples of what didn't work, all competing for attention with the two lines that actually matter. A long, thrashing session is a low-signal-to-noise prompt, and it gets worse with every turn you add.

This is why "it's confused, let me explain more" so reliably backfires. You're not clearing up the confusion — you're adding to the pile that caused it. More turns after things go sideways is almost always worse, not better.

The tells: how to know it's time

Learn to spot a dead session early. Pull the trigger when you see two or more of these:

• It re-reads files it already read a few turns ago, as if seeing them fresh.
• It re-applies an edit it already tried — sometimes verbatim — that already failed.
• The "you're absolutely right" ping-pong: it agrees with your correction, changes one thing, quietly reintroduces the original problem, agrees again.
• It's inventing — calling functions, flags, or files that don't exist, then building on them.
• It has drifted from the goal; you're three sub-problems deep in something you never asked for.
• You're now debugging the agent, not the code. This is the big one. The moment your job became "manage the confused AI" instead of "ship the feature," the session is already dead. You just haven't called it yet.

Kill, rewind, or course-correct?

Not every wrong turn deserves a headshot. Match the response to the damage:

Situation	Do this
One clear wrong step, context otherwise clean	Course-correct — say the specific thing, once
One bad edit to undo, but the reasoning up to it was sound	Rewind the files (press Esc twice) to before the edit
Multiple failed attempts, goal drift, or an anchored wrong assumption	Shoot it in the head — clear the context and restart

That middle option is worth knowing about. If it was a single bad edit and the thinking up to it was good, you don't need a headshot — press Esc twice to roll the files back to the checkpoint Claude Code snapshotted before that edit, and carry on. Rewind restores files, not the conversation, so you keep the good context and lose only the bad diff.

But the mistake most people make is reaching for course-correct when the situation calls for kill. If you've corrected the same thing twice and it's back a third time, stop correcting. The context is poisoned, and no amount of explaining fixes a poisoned context. Only a fresh one does.

How to pull the trigger cleanly

Killing a session is two motions: end the old context, and open the new one better.

End it. /clear gives you an empty context window in the same directory, and your CLAUDE.md reloads automatically so your project rules come right back. Here's the part that should make you fearless about it: the old conversation isn't destroyed. Claude Code saves every session to disk, so you can --resume it later if you ever need to. A headshot is never actually fatal — you're not losing the session, you're setting it down and picking up a clean one.

Open it better. This is the step people skip, and it's the entire point. A headshot without a sharper re-prompt just resets you to the same starting line. Instead, spend the one thing you genuinely earned in the dead session — knowledge — on the opening line of the new one:

We're adding X. The last attempt failed because the auth middleware runs before the body parser, so the token was never read. Start from that constraint: move the parser first, then wire the check. Don't touch the session store.

That's a fresh, tight context that already contains the lesson which took forty-five minutes to learn. The new agent doesn't relive the thrash; it starts where you ended up, minus the damage. A clean session plus a sharp opening beats an hour of nudging every time.

The reason you're afraid to do it

Most people nurse dead sessions for one honest reason: they're afraid of losing context. All that back-and-forth, all those little decisions, the shape of the thing you finally figured out — pull the trigger and it's gone, right?

Only if you kept it in the wrong place.

The fix isn't to protect the session. It's to stop keeping anything important inside a thing you're willing to kill. Durable context belongs outside the session:

• Repo rules go in CLAUDE.md. Conventions, architecture notes, "always run the typecheck before you claim it's done" — put them in the file Claude Code re-reads at the start of every session. That knowledge survives every headshot for free.
• Decisions and team knowledge go in a real store. The why behind a choice, the brand, the context that spans sessions and teammates — the things a fresh agent would otherwise have to rediscover — belong somewhere permanent it can pull on demand. That's exactly what a Company Brain is: durable memory an agent recalls by meaning, so a brand-new session re-hydrates in one query instead of an hour of re-explaining. With Beehaven, the agent pulls it straight from the CLI.

Put your context somewhere permanent and the math flips. The session stops being precious. It becomes what it always should have been: cheap, disposable, and easy to shoot.

Cattle, not pets

Infrastructure people have a phrase: treat servers like cattle, not pets. A pet server is one you name, nurse, and SSH into at 2am to save. A cattle server is one you kill and replace without a second thought, because everything that mattered lived somewhere else.

Claude Code sessions are cattle. The urge to nurse one — to make it this session that finally gets it — is the urge to fight. The people who move fast aren't luckier; they don't hit fewer bad sessions. They just kill theirs sooner, restart smarter, and keep their real context somewhere a headshot can't touch.

So when it goes bad, don't debug the agent. Shoot it in the head, and open a better one.

P.S. — we liked this metaphor enough to build it into a tiny Mac toy: your live Claude Code sessions become draggable avatars, and a headshot ends the real process. Half joke, half kill switch. The banana's free.

---

Keep reading: Claude Code stuck in a loop? Restart it, don't debug it · /clear vs /compact vs kill: managing Claude Code's context window