feat(issue): expose suspect commit in sentry issue view

[sergical]

The issue page shows a Suspect Commit block, but no CLI command surfaces it. For triage — human or agent — "who does Sentry think broke this" is among the first things you want, and today it is only reachable by hand-constructing an undocumented API call.

Today

sentry issue view returns 30 top-level fields including culprit, seerFixabilityScore, trace and the whole latest event. None of them carry the suspect commit. sentry issue list has no such field either. Searching the source, suspect commit appears exactly twice, both docstrings in code-mappings about enabling the feature:

packages/cli/src/commands/code-mappings/upload.ts:173
packages/cli/src/lib/api/code-mappings.ts:6

committers appears nowhere.

The data is available

It just takes two calls and an undocumented, event-level, project-scoped route:

$ sentry api /api/0/issues/7670740039/events/latest/        # to get an event id
$ sentry api /api/0/projects/{org}/{project}/events/{event_id}/committers/

which returns:

Sergiy Dybskiy
  c28baa9 | api-gateway: auth, quota, rate limits, routing | 2026-07-14T17:05:00Z

matching the Suspect Commit block in the UI exactly.

Two things make this hard to find. The route is event-level, not issue-level, so every issue-scoped path you would guess first 404s — silently, per #1423. And committers is absent from sentry schema, so it cannot be discovered through the documented path either (#1424).

Proposal

Add the suspect commit to sentry issue view, resolved from the latest event so the caller does not have to make the two-step call:

$ sentry issue view API-GATEWAY-5 --json --fields shortId,suspectCommit

{
  "shortId": "API-GATEWAY-5",
  "suspectCommit": {
    "id": "c28baa9...",
    "message": "api-gateway: auth, quota, rate limits, routing",
    "author": { "name": "Sergiy Dybskiy", "email": "..." },
    "dateCreated": "2026-07-14T17:05:00Z"
  }
}

and a line in the human-readable output alongside culprit. null when there are no committers — note the endpoint currently 404s rather than returning an empty array when none are found, so that needs handling rather than surfacing as an error.

Related: getsentry/sentry#80771 asks for the same data in the public API.

Version

0.43.0-dev.1786559401, checked against origin/main @ 47ad7e4.