Issues and pull requests use close-and-retain lifecycle semantics
After the pull request merged and auto-closed the linked issue, both models deleted the feature branch and verified the requested cleanup. GitHub retains issues and pull requests as repository history rather than exposing hard-delete endpoints. This is an intentional lifecycle boundary, not a failed cleanup path: the task explicitly asked the agents to close created issues and delete the branch, and both completed it. The merged file can be removed by a later commit, while prior commit history remains. The audit did not measure privacy, compliance, or other harm from retaining closed collaboration history.
How can I reproduce this?
Requires: GitHub PAT with repo access and a test repository
- Create a test issue: POST /repos/{owner}/{repo}/issues with a title.
- Attempt to delete it: DELETE /repos/{owner}/{repo}/issues/{number}.
- Close it instead: PATCH /repos/{owner}/{repo}/issues/{number} with { "state": "closed" }.
- For contrast, create and delete a branch: DELETE /repos/{owner}/{repo}/git/refs/heads/{branch}.
Expected: DELETE on the issue returns 404 because that endpoint does not exist; PATCH state=closed succeeds and retains the issue as repository history. The branch DELETE returns 204.
Evidence · transcript moments