I Let Claude Code Run Unattended on a Real Build - Here's What I Learned

Running Claude Code unattended means giving it a task and letting it work through the steps on its own - reading files, writing code, running commands, checking results - without you sitting there approving each move. In the desktop app you kick it off and walk away. The appeal is obvious: you describe the work, go make dinner, and come back to progress. The reality is more interesting than either the hype or the fear.

I tested this on a real client build, not a toy demo. The task was migrating a batch of old form components to a new validation library across a mid-size codebase - repetitive, well-defined, the kind of work that eats an afternoon of human attention but doesn't need much creativity. That combination turned out to be exactly the sweet spot.

My first attempt was lazy. I wrote a broad prompt - 'migrate the forms to the new validation library and clean things up while you're in there' - and let it go. When I came back, it had migrated the forms correctly, then kept going. It refactored a shared utility, renamed a few props for consistency, and touched files that had nothing to do with the task. None of it was wrong exactly. All of it was scope I hadn't asked for, which meant every one of those changes now needed review before I trusted it.

That is the core failure mode of unattended runs. Claude is genuinely capable, so when you leave the goal fuzzy, it fills the space with initiative. 'Clean things up while you're in there' is an open door. It will walk through it. The problem is not the tool being bad - it's the instruction being vague, and vague instructions are far more expensive when nobody is watching in real time.

After that run I built a small routine I now call the Leash Loop. It's three moves, and it's the difference between coming back to progress and coming back to cleanup.

The name is the point. You're not caging the tool - a caged tool can't help you. You're keeping it on a leash long enough to do real work and short enough that it can't run off. When I re-ran the migration with the Leash Loop, it did the 14 files, ran the type checker until it was clean, and stopped. I reviewed a focused diff instead of an archaeology dig.

Once I stopped fighting the tool and started scoping for it, the wins were concrete. The pattern that predicts a good unattended run is always the same: the work is well-defined, repetitive, and has an automatic way to verify it's correct.

Here's the honest part the hype skips. Even a clean, well-scoped unattended run produces a first draft, not a shipped feature. I still read every diff before it goes anywhere near production. The time I save is the time I would have spent typing the changes and grinding through the repetitive parts. The time I do not save is the review. If anything, unattended work makes the review more important, because I wasn't watching it happen and I don't have the running context of each decision in my head.

This is where the money guardrail lives, too. I will happily let Claude migrate form components overnight. I will not let it run unattended on anything that spends money, touches authentication, or writes to production data. The blast radius is too big and the failure is too hard to reverse. Unattended runs belong on reversible, reviewable work.

Pick the most boring, most well-defined task on your list - the one you keep putting off because it's tedious rather than hard. Something like adding the same prop to a dozen components, or writing tests for a module whose behavior is already settled. In the Claude Code desktop app, write the prompt with the Leash Loop in mind: name the exact scope, point it at the check that proves it worked, and tell it to stop and report when that check passes.