Trust it: Verifying unsupervised runs
You handed Claude a task and let it run without watching every step. Now it says it's done. Before you ship that work, you need a way to check something you didn't even supervise. That check is what makes hands-off Claude Code safe to rely on.
The idea here is simple: verify in proportion to how much rope you gave the run. If you watched the messages scroll by in a short session, a quick glance is enough. But an unattended run, or a job that fired in continuous integration with nobody in the loop, needs a real check. No one saw what happened, so you have to reconstruct it after the fact.
Here's a way to picture it. The less you watched, the more you verify.
한국어 대본
- 00:00Claude에 작업을 맡기고 모든 단계를 지켜보지 않은 채 실행하게 했습니다.
- 00:06이제 완료됐다고 하지만, 배포하기 전에 다음을 확인할 방법이 필요합니다.
- 00:10직접 감독하지도 않은 작업을 말입니다.
- 00:11확인 절차가 있어야 손을 떼고 맡긴 Claude 코드를 안전하게 신뢰할 수 있습니다.
- 00:16실행에 준 자율성에 비례해 검증하세요.
- 00:19메시지가 지나가는 것을 지켜본 짧은 세션은 훑어보는 정도면 됩니다.
- 00:23아무도 지켜보지 않은 실행이나 CI에서 사람 없이 시작된 작업은
- 00:28실제 확인이 필요합니다.
- 00:30아무도 그 과정이 진행되는 것을 보지 못했기 때문입니다. 업무에서 실행을 무인으로 둘 때는 자동 모드를 유지하세요.
- 00:35권한을 우회하는 대신, 분류기는 각 행동의 위험성을 여전히 검토하지만, 다음을 판단하지는 않습니다.
- 00:41코드가 올바른지는 판단하지 않으므로 검증 기준은 그대로입니다. 그 기준은
- 00:45실행이 얼마나 무인 상태였는지에 따라 정하세요. 먼저 클라우드 요약이 아니라 diff 자체를 보고, slash
- 00:52code review로 변경 사항을 살펴 문제를 표시하세요. 그런 다음 git diff를 직접 확인하세요. 함정은 깔끔한
- 00:58요약을 읽으면 괜찮아 보이지만 diff가 정말 예상하지 못한 파일을 건드린 경우입니다.
- 01:03무엇이 바뀌었는지와 계획에 없던 파일을 먼저 읽으세요.
- 01:07무인 실행의 진짜 관문은 테스트가 통과했는지, Claude가 실행했는지 아니면
- 01:12실행했다고 주장만 했는지입니다. 신뢰에 맡기지 말고 훅으로 연결해 Claude가 건너뛸 수 없게 하세요.
- 01:17테스트를 실행하고 실패하면 턴 종료를 거부하는 stop 훅이나, 매 편집 후
- 01:23린트와 타입 검사를 실행하는 post tool use 훅을 사용하세요. 코드 2로 종료되는 훅은 실패를
- 01:27Claude에 바로 전달하고, Claude는 읽은 뒤 요청하지 않아도 고칩니다. 확인은 모든
- 01:32실행에서, 요청하는 것을 기억했는지와 관계없이 작동합니다. PR 전에 실행하던 sub-agent 코드 리뷰도
- 01:38여기서 그대로 사용할 수 있습니다. 무인 실행을 대상으로 지정하고, 새 세션이나 sub-agent를 열어
- 01:43코드 작성 과정을 모르는 상태에서 변경 사항을 검토하게 하세요.
- 01:48접근 방식에 이해관계가 없으므로 원래 실행이 말로 넘어간 문제를 포착합니다. 실행이 무인 상태였던 만큼
- 01:56검토도 엄격하게 하세요. diff를 읽고, 테스트를 턴을 차단하는 훅으로 만들고, headless 실행은 JSON 결과와 exit code로 검증하며, 중요한 사항은 냉정한
- 02:01두 번째 의견으로 확인하세요.
- 02:06이렇게 하면 제가 보지 않는 동안 Claude가 작업을 완료했다고 말해도 더 이상 믿음에 의존하지 않아도 됩니다.
Keep unattended runs in auto mode
When a run goes unattended at work, keep it in auto mode rather than bypass permissions. In auto mode, the classifier still reviews each action for danger. That's a safety net worth keeping.
But be clear about what that net does and doesn't do. The classifier never judges whether the code is actually correct. It only flags dangerous actions. So your verification bar stays exactly where it was. Set that bar based on how unsupervised the run was.
Start with the diff, not the summary
Don't start with Claude's summary of what it did. Start with the diff itself.
- Run
/code-reviewto walk the changes and flag issues. - Then put your own eyes on
git diff.
The trap is a tidy summary that reads perfectly fine, while the actual diff touched a file you honestly didn't expect it to touch. The summary won't tell you that. The diff will.
So read what changed. Read the files that were part of the plan first, then look for anything outside it. A clean write-up is not proof of clean code.
Turn tests into a gate, not a promise
The real gate on an unsupervised run is whether the tests passed, and whether Claude actually ran them or only claimed that it did. Don't leave that to trust. Wire it as a hook so Claude can't skip it.
A couple of hooks do the job:
- A stop hook that runs your tests and refuses to end the turn on a failure.
- A post-tool-use hook that lints and type checks after every edit.
The key detail is the exit code. A hook that exits with exit 2 feeds the failure straight back to Claude. Claude reads that failure and fixes it without you asking. Best of all, the check fires on every run, whether or not you remember to ask for it.
Get a cold second opinion
The sub-agent code review you'd run before a pull request works here too. Point it at an unsupervised run.
Open a fresh session or sub-agent and have it review the changed code with no memory of how the code was built. Because it has no stake in the approach, it catches the things the original run talked itself past. A second reviewer with fresh eyes finds what the author rationalized away.
Putting it together
Make the check as serious as the run was unsupervised:
- Read the diff yourself.
- Turn the tests into a hook that gates the turn.
- Verify headless runs by their JSON result and exit code.
- Get a cold second opinion on anything that matters.
Do that, and "Claude did it while I wasn't looking" no longer takes faith.