A broken feature appearing after an agent's work is a lead, not proof of authorship. First reproduce the failure in a known checkout. Then identify the change that introduced it, inspect the PR and diff, and only then look for the session that produced or reviewed that change.
Freeze a reproducible report
Record the failing action, actual and expected result, URL or environment, branch, commit, and first error. Verify that the server serving the page belongs to that checkout. If the bug appears only in production, record the deployed revision before searching local agent tabs. A session title or recent timestamp is weak evidence when several agents and worktrees were active. Preserve logs and screenshots without copying secrets into an agent prompt. The immediate goal is one repeatable failure and one known-good comparison, if available.
Locate the change in Git
Start with the affected file and recent commits, then inspect each candidate diff. Git blame reports the commit that last changed a current line; it cannot by itself prove that commit caused the behavior, and it does not display deleted lines. Git log with a path or a text search can find earlier edits. When you have a reliable good revision and a bad revision with a repeatable check, Git bisect can narrow the first bad commit. Avoid bisecting an unbuildable range or marking a revision bad when the failure was actually a missing environment dependency.
| Evidence | Useful next check | Limit |
|---|---|---|
| One suspicious current line | Inspect blame, then the whole commit diff | Last edit is not causation |
| A removed condition or renamed file | Search Git history and compare diffs | Current-line blame may miss it |
| Known good and bad revisions | Run the same check through bisect | The check must be deterministic |
| A PR was merged recently | Read its commits, review, checks, and final diff | A green check may not cover this behavior |
Connect the commit to the PR and workspace
GitHub's PR views separate conversation, commits, changed files, and checks. Use those to learn what the change intended and what was actually reviewed. Canopy's current-main README describes an Agent Workspace joining a session to its checkout, files, commits, branch, diff, and PR. Check your installed release and the CLI's supported attribution before treating that link as complete. A commit author, PR author, and agent session are different identities; shared working trees, manual edits, rebases, and squash merges can break a simple one-to-one story. If the session cannot be found, keep the Git evidence and do not guess its owner.
- Match repository, checkout path, branch, commit or PR, and approximate time.
- Compare the session's task and observed tool output with the actual diff.
- Mark attribution as confirmed, partial, or unknown in the incident note.
Assign a bounded fix to the right agent
Give the fixing agent the reproduction, suspect revision, relevant diff, and acceptance check. Ask it to explain the cause before changing code. If the original session still has useful context, resume it in the correct checkout; otherwise start a focused new session and link the evidence. For an independent review, use a separate session or model to challenge the diagnosis. Do not ask an agent to revert a broad PR merely because the error appeared afterward: first identify whether the faulty behavior came from that PR, an environment change, or an older assumption exposed by the new code.
Close the incident with the final state
After the fix, repeat the failing action, run the focused regression check, inspect the final diff, and verify the target branch and PR checks. Write down which commit introduced the behavior, what evidence supports that conclusion, which session worked on the fix, and what remains uncertain. A compact incident trail helps the next reviewer without turning a raw agent transcript into project documentation. The accountable artifact is the corrected code and observed behavior, not the agent's final message.
Copyable resources
Regression trace card
Use evidence labels so a suspected session is not presented as a proven cause.
Failure and exact reproduction: [ ]
Environment, URL, branch, and deployed or local commit: [ ]
Last known good revision and check: [ ]
Suspect commit, PR, and relevant diff: [ ]
How the suspect was identified (blame, history, bisect, review): [ ]
Agent session and checkout link (confirmed, partial, or unknown): [ ]
Fix owner and acceptance check: [ ]
Final behavior, tests, diff, and remaining uncertainty: [ ]Frequently asked questions
Does Git blame prove which agent caused a bug?
No. It identifies the revision that last changed a current line. Inspect the full history, behavior, and workspace evidence before attributing a regression or agent session.
What if a PR was squash merged?
Use the PR's commits and final diff alongside the resulting merge commit. The final commit alone may not preserve a one-to-one mapping to each agent session.
Should the original agent fix its own regression?
It can be useful if that session still has the right context. Give it the reproducible failure and check its diagnosis and final diff; a separate review is valuable for risky fixes.