Permissions

Code review has two permission surfaces: the review Ellipsis posts, and the sandboxes your reviewers run in. The first is fixed; the second is yours to scope.

Posting the review

A reviewer never posts to GitHub. It reads the pull request's code in its sandbox and hands its findings to Ellipsis; Ellipsis validates them and posts one pull request review, authored by the Ellipsis bot.

So enabling code review means exactly this: Ellipsis reads your code and writes pull request comments. It pushes no commits, edits no files, and merges nothing. Every review posts as a comment-only review, never an approval or a request for changes, so it can never satisfy a required-review rule or block a merge. The one other mark it leaves is an eyes reaction on the pull request while a review is running, cleared when the review finishes.

Review stage permissions

Every stage in a pipeline, whether a reviewer, the gatekeeper, or a pre_review agent, runs as an ordinary agent session. Its sandbox gets its own short-lived GitHub token scoped to the sandbox's repositories, and sandbox.github narrows that token the same way it does for any agent, down to read_only. A pipeline-level sandbox: block applies to every stage; a stage's own sandbox: merges on top, so one reviewer can carry a narrower token, an extra credential, or a different image than the rest.

The scoping fields, permission levels, and the read_only posture are documented once, in Cloud Agents permissions; everything there applies per stage. One consequence worth knowing: because findings are delivered through Ellipsis rather than posted by the agent, a reviewer works correctly on a fully read-only token.

Comments anchor to commits

Every review posts anchored to the exact commit it reviewed, the head of its range at the moment it ran. Two things follow:

• Comments stay accurate as the pull request moves. Each comment attaches to lines in the reviewed commit; when a later push changes those lines, GitHub collapses the comment as outdated instead of showing it against code it was never about.
• Anchoring is what makes reviews incremental. The next review covers only what landed after the anchored commit, so nothing is re-reviewed and nothing is skipped. See Which PRs get reviewed.