Reviewing a Generated Commit Before It Lands
You ask Claude Code, running in acceptEdits mode, to "clean up the
error handling in payments/charge.ts and commit the result." Claude
makes several edits across the file and proposes this commit message:
Improve error handling in charge.ts
Wrap the Stripe API call in a try/catch and log failures.
- Given that
acceptEditsmode auto-approves file edits without prompting per-edit, what specific step should you take before this commit is created, and why does the agentic loop's own verification not cover it? - Name two concrete things that could be wrong with this diff that a fluent, well-formatted commit message would not reveal.
- If you discover after the fact that the commit included a hardcoded Stripe test key that was already sitting in the file, what is the complete remediation — and why is "delete it in a follow-up commit" not sufficient on its own?
1. The step, and why verification doesn't cover it:
Run git diff --staged (or ask Claude to summarize the staged diff)
yourself before approving the commit. The agentic loop's verification
step checks that tests pass and commands succeed — it has no way to
check that the change is stylistically consistent with the rest of the
codebase or that it's actually the change you meant, because neither of
those is something a test suite or exit code can express. acceptEdits
mode specifically removed the per-edit prompt that would otherwise have
let you catch a problem as it happened, which makes this final
diff-review step the only remaining checkpoint before the change is
permanent history.
2. Two things a good-sounding message wouldn't reveal:
- The diff could touch more of the file than "error handling" implies — e.g., reformatting unrelated lines, which makes the actual functional change harder to spot in review and inflates the diff for anyone looking at it later.
- The try/catch could swallow the error silently instead of surfacing it upstream (logging it is not the same as handling it correctly — a caller that expected the promise to reject now sees it resolve). Either is a plausible, common mistake that reads perfectly well in a commit message, because the message describes intent, not correctness.
3. Complete remediation for a leaked secret:
Rotate the Stripe key immediately — treat it as compromised the moment
it's in git history, live or not. Deleting it in a follow-up commit
only removes it from the current working tree; the key is still
present in every earlier commit's history and in any clone, fork, or
cached copy of the repository that already pulled it. Removing it from
history entirely requires a history rewrite (e.g., git filter-repo or
equivalent) plus a force-push — which is itself a destructive,
shared-history-rewriting operation that needs explicit confirmation and
coordination with anyone who has the branch checked out. Rotation is
the step that actually neutralizes the exposure; the history cleanup is
hygiene on top of that, not a substitute for it.
Share this question