Should agent approvals expire when the repository changes?

I’m cautiously adding AI coding agents to an open-source workflow, and I’m unsure what an approval should mean once the ground shifts. Should an agent’s review approval automatically expire when the pull request, dependency graph, or test environment changes?

A static “approved” label can be misleading: the reviewed diff may no longer be the diff awaiting merge, and passing tests for an earlier commit do not establish much about the latest SHA. For example, an agent opens a patch, tests pass, and I approve it; then it updates the lockfile or rebases onto a changed base branch. Re-reviewing everything is safer, but expiring approvals for harmless metadata changes could create exhausting churn on a small team.

Should approval attach to a commit, an environment snapshot, or a risk threshold—such as production dependencies or security-sensitive files? Developers and maintainers, disagree, share existing tooling, or propose a better rule.

I’d bind approval to the exact commit plus the merge base, and let CI enforce freshness for the latest SHA. Environment snapshots are harder: reproducibility is useful, but “same environment” can become a vague exception. Risk thresholds should decide whether a human must look again, not whether the old approval remains literally true.

For security-sensitive files, I’d expire aggressively: lockfiles, CI configuration, permissions, deployment code, and anything handling credentials. A dependency update is not metadata just because the application diff is unchanged. The cost of one extra review is lower than treating an old trust decision as current.

Small projects need a boring rule. Dismiss approval on changed executable lines or dependency manifests; don’t do it for formatting, docs, or a rebase with an identical patch. Perfect provenance is nice, but if the bot turns every merge into a review queue, people will disable the gate.

The important distinction is between approval and validation. GitHub’s stale-review behavior is already diff-oriented, while required checks target the latest commit SHA. That suggests a useful baseline: approval follows the reviewed diff, and checks follow the candidate commit. I would be cautious about claiming an environment snapshot solves the remaining problem.

The user experience matters here. If an approval disappears with no explanation, maintainers learn to click through it. I’d show “approval invalidated because dependency X changed” and make the re-review surface only the affected files and new test results. Good policy can still fail as an interface.

I’m not convinced agents deserve a special expiration rule. Humans also approve a PR and then miss a subtle rebase or dependency change. Start with the strongest existing commit/diff rules, measure the false churn, then add agent-specific thresholds only if the failure mode is actually different.

There’s a process edge case: the agent may keep pushing fixes after a reviewer approves. I’d make approval a property of a specific reviewable revision, not the PR. The bot can request re-review automatically, but the queue should distinguish “new risky code” from “tests rerun after an unchanged rebase.”

Approval of what, exactly? If the answer is “this PR,” the model is already too fuzzy. If it is “this diff under these checks,” the rule becomes understandable. I’d rather have a slightly annoying precise system than a green badge nobody can interpret.

I’d use a two-tier policy: automatic expiry for production dependencies, security files, and test configuration; retain approval for low-risk changes if the latest checks pass. Track how often approvals are invalidated and how often that catches a real issue. Otherwise this becomes governance by intuition.