Summary
The tracking comment posted after a successful push-to-pull-request-branch operation contains a commit link that points to a SHA that does not exist in the target repository.
Example
Comment posted to the PR:
Commit pushed: 8680cc9
Visiting the link returns 404. The commit 8680cc9f does not exist in org/repo. The actual commit that landed on the PR branch has a different SHA.
Root Cause
The agent creates a local commit (e.g. via git cherry-pick or git commit) and the safe_outputs handler records that local SHA for the tracking comment. When push_to_pull_request_branch applies the patch to the remote PR branch, it creates a new commit with a different SHA — different parent, potentially different timestamp, or different apply mechanism. The tracking comment is generated using the agent-side SHA, so the link is always stale when the two SHAs diverge.
Impact
- Every
push_to_pull_request_branch tracking comment that includes a commit link is broken
- The link format
[short-sha](full-url) looks authoritative but leads to a 404
- Users following the link to review the pushed changes find nothing
Expected Behavior
The tracking comment should link to the SHA of the commit that actually landed on the remote branch, not the SHA of the locally-generated commit in the agent sandbox.
Suggested Fix
After applying the patch and pushing, resolve the actual HEAD SHA of the target branch (e.g. via git rev-parse HEAD after push, or via the GitHub API) and use that SHA in the tracking comment instead of the agent's local commit SHA.
Issue filed by Claude (Anthropic)
Summary
The tracking comment posted after a successful
push-to-pull-request-branchoperation contains a commit link that points to a SHA that does not exist in the target repository.Example
Comment posted to the PR:
Visiting the link returns 404. The commit
8680cc9fdoes not exist inorg/repo. The actual commit that landed on the PR branch has a different SHA.Root Cause
The agent creates a local commit (e.g. via
git cherry-pickorgit commit) and the safe_outputs handler records that local SHA for the tracking comment. Whenpush_to_pull_request_branchapplies the patch to the remote PR branch, it creates a new commit with a different SHA — different parent, potentially different timestamp, or different apply mechanism. The tracking comment is generated using the agent-side SHA, so the link is always stale when the two SHAs diverge.Impact
push_to_pull_request_branchtracking comment that includes a commit link is broken[short-sha](full-url)looks authoritative but leads to a 404Expected Behavior
The tracking comment should link to the SHA of the commit that actually landed on the remote branch, not the SHA of the locally-generated commit in the agent sandbox.
Suggested Fix
After applying the patch and pushing, resolve the actual HEAD SHA of the target branch (e.g. via
git rev-parse HEADafter push, or via the GitHub API) and use that SHA in the tracking comment instead of the agent's local commit SHA.Issue filed by Claude (Anthropic)