Bug Description
Title: Claude Code rewrote public git history (force-push to a branch with an open PR) on the strength of a consent prompt that buried the action
What happened. While working in a public OSS repo (thousands of users), Claude Code added a commit to a branch with an open PR, then decided the commit belonged in a separate PR. To split it, it ran git reset --hard HEAD~1 and git push --force-with-lease on that branch — rewriting the history of a branch under open public review.
The consent problem. It did ask, but the destructive action appeared only as a parenthetical inside a multiple-choice option description: "(needs a force-push to ragplus, which has the open #1903)". Selecting an option labelled "Split into its own PR (Recommended)" is not informed consent to rewrite public history. A destructive, irreversible, publicly-visible git operation must be its own explicit confirmation, in plain words — never a clause inside an option a user is choosing for a different reason.
Why this matters more than the diff. No work was lost and the PR's content ended up correct, so by a naive check "nothing broke". But in open source the audience is every contributor and user watching the repo. A force-push on an open PR breaks the review contract, can orphan review comments, and leaves an unexplained rewrite in the permanent public record. I had to comment on the PR myself to explain it to the community. The cost is reputational and cannot be reverted.
Requested behaviour. Treat history-rewriting operations on pushed branches (push --force, --force-with-lease, reset --hard + push, rebase of a pushed branch) as a distinct hazard class, especially where a PR is open:
- Never bundle them into an option description or a compound question.
- Prefer non-destructive alternatives by default — to split a commit out, cherry-pick to a new branch and leave the original alone; a slightly messy PR is far cheaper than a rewritten one.
- Treat --force-with-lease as not a mitigation: it prevents clobbering someone else's push, not the reputational damage of rewriting a public PR.
- Weigh public-repo context explicitly. "Reversible in git" is not the same as "reversible in public".
Environment Info
- Platform: darwin
- Terminal: intellij
- Version: 2.1.226
- Feedback ID: a9c018f0-48b7-433f-b1d7-89a96a61bda5
Errors
Bug Description
Title: Claude Code rewrote public git history (force-push to a branch with an open PR) on the strength of a consent prompt that buried the action
What happened. While working in a public OSS repo (thousands of users), Claude Code added a commit to a branch with an open PR, then decided the commit belonged in a separate PR. To split it, it ran git reset --hard HEAD~1 and git push --force-with-lease on that branch — rewriting the history of a branch under open public review.
The consent problem. It did ask, but the destructive action appeared only as a parenthetical inside a multiple-choice option description: "(needs a force-push to ragplus, which has the open #1903)". Selecting an option labelled "Split into its own PR (Recommended)" is not informed consent to rewrite public history. A destructive, irreversible, publicly-visible git operation must be its own explicit confirmation, in plain words — never a clause inside an option a user is choosing for a different reason.
Why this matters more than the diff. No work was lost and the PR's content ended up correct, so by a naive check "nothing broke". But in open source the audience is every contributor and user watching the repo. A force-push on an open PR breaks the review contract, can orphan review comments, and leaves an unexplained rewrite in the permanent public record. I had to comment on the PR myself to explain it to the community. The cost is reputational and cannot be reverted.
Requested behaviour. Treat history-rewriting operations on pushed branches (push --force, --force-with-lease, reset --hard + push, rebase of a pushed branch) as a distinct hazard class, especially where a PR is open:
Environment Info
Errors