[vaind]

Seer's coding jobs need to clone, fetch and push customer repositories without ever holding a GitHub or GitLab token. This adds an internal endpoint that speaks git's HTTP protocol and relays each request to the repository's provider, adding the org's integration token on the way:

/api/0/internal/scm-git/repositories/{repository_id}.git/{info/refs | git-upload-pack | git-receive-pack}

Each request carries a grant in X-Scm-Git-Grant: a short-lived token Seer signs for one org, one operation (fetch or push) and a list of repositories. The view verifies it, checks the organizations:scm-git-endpoint flag for that org, and hands the request to scm-platform's scm.git module (sentry-scm 2.0.0), which does the remaining checks and streams the relay. Anything the grant doesn't cover is refused before Sentry looks up the repository or mints a token. Those refusals are plain-text 403s, which git shows as remote: <reason>, never 401s, which would make git ask for a password. Only the credential proxy Seer's jobs go through can reach the endpoint, so a refusal means Sentry or Seer is misconfigured; each one is also reported as a Sentry issue, grouped by reason.

• Tokens come from integration_service.get_access_token (feat(integrations): Add a provider access token RPC for cells #128490, feat(integrations): Add GitLab to the access token RPC #128762): control mints or refreshes them and sends only the token to the cell. GitHub, GitHub Enterprise, GitLab and Cursor Origin work.
• Requests to the provider go through BlacklistAdapter, so a GitHub Enterprise or self-managed GitLab host that resolves to an internal address gets a 503. A self-managed GitLab served over plain http gets a 502, so the token never crosses the network unencrypted.
• grant joins the SDK's request-header denylist, so the grant isn't recorded on spans or error events.
• A push is held in worker memory up to nginx's body limit, because Endpoint.dispatch reads bodies sent with a Content-Length whole, as it already does for objectstore and debug-file uploads.

Before an org gets the flag:

• SCM_GIT_GRANT_SECRETS (a list, so secrets can rotate) has to be set in both Sentry and Seer. Without it, every request is refused.
• The cells' outbound addresses have to be on the published IP allow list. The cell calls the provider itself, because control's integration proxy reads whole bodies and rewrites Authorization, so customer allow lists on GitHub Enterprise, self-managed GitLab and GitHub organizations will see the cell's addresses instead of control's.
• Each clone or push holds a web worker for the whole transfer, since the relay's 300-second timeout only limits how long the provider may stay silent, not the total time. We need to know which worker pool serves /api/0/internal/scm-git/, that nginx and load-balancer timeouts allow transfers of several minutes, and whether many coding jobs cloning large repositories at once could starve that pool's other API traffic.

Before merging, once sentry-scm ships a release with these two scm-platform changes, bump it here and:

• fix(git): Keep the provider token out of error reports scm-platform#167: return the token from fetch_access_token as Secret(access_token.token), so it never sits in a stack frame as plain text.
• feat(git): Let callers map adapter errors to coded errors, like a refused host scm-platform#168: pass map_error to GitRelay so a provider host on an internal address becomes a coded refusal, then remove the view's own except RestrictedIPAddress branch.

Refs CW-2222

[linear-code]

CW-2222

[sentry]

Sentry Snapshot Testing

Name	Added	Removed	Changed	Renamed	Unchanged	Skipped	Status
sentry-frontend sentry-frontend	0	0	0	0	766	0	✅ Unchanged

⚙️ sentry-frontend Snapshot Settings