The report
A coding agent can receive an error after successfully creating a pull request. It can also delete a newer version of a file using a stale identifier, or overwrite another agent's project-field change while both callers receive success. These are separate reported defects in GitHub's MCP server; together they show why a tool response cannot be taken as a complete record of committed effects.
Three failure modes, three different checks
The pull-request report starts with an authorized create_pull_request. The PR is created. The next step, assigning an invalid reviewer, receives HTTP 422, so the MCP tool returns an error without the PR's ID or URL. A retry encounters an existing PR but cannot reliably recover its identifier from that original response. The committed resource and the reported operation status have diverged.
The file-deletion report concerns a different trust expectation. The caller supplies a blob SHA for the version it believes it is deleting; the implementation described in the issue builds a tree operation without enforcing that SHA as a current-version precondition. A collaborator may have replaced the file between inspection and deletion. The same report tests a directory path and observes a subtree removal, although the tool is called delete_file. Both outcomes require write permission to the repository.
The concurrent project-field test uses read, merge and full-set write. Two callers update distinct fields, but the later write restores an outdated snapshot of the other field. The reporter measured 19 lost changes among 30 concurrent pairs. A comparison using a direct per-field GraphQL mutation lost zero among 28 pairs. The samples support a race in the tested method, not a general GitHub data-loss rate.
| Tool assumption | What the report actually observes | Better verification target |
|---|---|---|
| A failure means nothing was committed | PR created before reviewer error | Query new PR by returned or recoverable ID |
| A deletion targets the SHA inspected earlier | Stale SHA not enforced in tested path | Compare-and-swap against current blob/tree |
| Successful field update affects one field | Full-value replacement lost another writer's change | Per-field mutation or versioned update |
Why this matters to agent workflows
The model need not be malicious or mistaken. A correct-looking plan can still produce an unacknowledged change, and a repeat attempt can compound the effect. GitHub token permissions remain relevant and do not disappear because of these bugs; the question is whether an authorized agent performed exactly the requested state transition.
These are public issue reports with controlled reproductions and proposed directions, not proof of a merged fix or an observed hostile campaign. Until the implementation is independently checked, operational logs should compare actual repository, PR and project state with the tool's returned result before retrying consequential calls.