What Sigma does with your code

What is fetched

Sigma fetches your pull request's exact head and base commits by SHA, as an immutable Git object snapshot — not your working tree, not a live clone it keeps updating. create_snapshot reads exact commit/tree/blob objects, ignoring working-tree edits; the fetch itself uses "a narrow repository-scoped installation token on the controller, with no checkout, repository execution, inherited Git credentials, hooks or redirects."

A snapshot is bounded: at most 128 MB and 20,000 entries. Every changed file in the review is guaranteed to fit (or the snapshot fails outright); beyond that, the smallest remaining files are archived first, and anything left out is recorded and shown to you as a scope note ("Sigma could not read everything") on that run.

Where it runs

Every review runs inside a disposable Docker sandbox: non-root user, a read-only system filesystem, no Linux capabilities, no new privileges, no Docker socket, and — for the default gateway executor — no network access at all (network=none). Command output is bounded and the whole container is removed after the attempt.

Subscription execution has a different boundary. On owner-login, the producer stage runs through a configured Claude subscription login and needs a route to Anthropic: it gets a Docker network with internal: true (no route off the host at all) whose only exit is a proxy that allows CONNECT only to api.anthropic.com, claude.ai, claude.com and platform.claude.com on port 443, and refuses every other host, port and method. That model also has no shell inside the login-holding container — every command is forwarded to a separate sidecar container with no login volume and no network at all. The offline guarantee does not currently extend to that stage's dependency installation and required checks, which still run inside the login-bearing container; closing that gap is open work (issue #146). See reviewers-and-executors.md for when owner-login applies.

The logins path adds a Codex ChatGPT-login verifier. The source baseline does not provide a Codex tool sidecar: its model-directed shell runs in the same sandbox as that login. Dependency preparation and required checks also run in the stage sandbox. Do not apply the gateway's credential-free offline guarantee to subscription stages or assume that a UI executor label closes this isolation gap. These paths need their own operational acceptance; a configured login is not proof of readiness or a grant for hosted/commercial use.

What leaves the host

Model calls leave your maintainer's Sigma host for a model provider. Which provider depends on the reviewer and executor:

• Gateway executor (the default): both stages call out through Sigma's own credential gateway, using Sigma's API keys. Workers never receive provider keys directly.
• Owner-login executor: the producer stage calls Anthropic directly from inside the sandbox through a configured Claude Code login; its verifier stage still runs on the API gateway. The person reading the profile is not automatically established as that login's owner or payer.
• Logins executor: the Claude producer and Codex verifier use separate subscription logins and can send model requests to their respective providers. Availability requires the installation's enabled logins and repository gates.

In the configured “crossed” construction, Bravo's producer is Codex and its verifier is Claude; Charlie's producer is Claude and its verifier is Codex — so no producer is checked by its own provider's model.

What is kept

Sigma keeps a durable run record (stages, findings, cost, scope notes) and the snapshot/dependency artifacts it used, as host data outside the sandbox. How long these are kept is not yet defined: "Snapshot/dependency stores and retained logs are host data, outside tmpfs. Their per-artifact bounds do not constitute an aggregate host retention quota; release operations must include retention/backup policy." There is no per-review deletion request today.

The secret guard

Before anything a model wrote becomes durable — before it is saved as an artifact, before it reaches the run record, and again before a review is published — Sigma scans it for text shaped like a credential: Anthropic keys, Claude Code OAuth tokens, GitHub tokens, AWS access key IDs, JWTs, Bearer headers, and any unbroken 40+ character opaque run with a 20-character alphanumeric core. It also checks split/obfuscated forms of the same text (zero-width joiners, one-character-at-a-time spacing), so a token cannot slip through as s k - a n t - .... Ordinary review facts — a 40-character Git commit SHA, a SHA-256/512 digest, or a lockfile integrity hash — are exempted by exact form and keep publishing.

If a match sits in a finding's prose (title, claim, impact, evidence, suggested fix, verification), only that one field is replaced with a sentence naming the rule, the rest of the review still publishes, and a scope note is added: "Sigma withheld one finding's text because it looked like a credential (rule …, finding N, field …); that text was neither stored nor published." If a match sits anywhere else, the whole run does not publish: publication withheld: finding text resembles a credential, and the check names the rule and field — never the text itself.