Permissions
Contents read-only, plus write to pull request comments, checks and issues. Nothing else: a feature needing a fourth write scope is a different product.
Crocotaste reads your repository, comments on pull requests, and posts a check. That is the whole surface. The permission list below is not a starting point we plan to grow; it is a constraint the product is built inside, and every feature has to fit it or not exist.
The GitHub App's permissions
| Permission | Access | Used for |
|---|---|---|
| Contents | read | the pull request diff; DESIGN.md, stylesheets, the Tailwind config and component files at the base commit |
| Pull requests | write | the summary comment, inline findings with suggestions, the approving review, replies to @crocotaste ignore, and marking the finding it dismisses resolved |
| Checks | write | the crocotaste check run and its JSON |
| Issues | write | the one "Generate your DESIGN.md" issue at setup, and closing it when the file lands |
| Metadata | read | required by GitHub for every App |
Contents is read, and that is the load-bearing line. Every write above lands on a pull request, a check run or one issue. None of them can put a byte in a file, a branch or a commit.
Crocotaste subscribes to the pull request and comment events it needs to review and to answer commands, plus installation events. It also watches pushes to your default branch, but only to notice that DESIGN.md changed; nothing else about a push is read, and nothing is polled.
Signing in uses the same App
There is no second app behind the dashboard. Signing in issues a user token for this same App, and asks you for one account permission:
| Permission | Access | Used for |
|---|---|---|
| Email addresses | read | creating your Crocotaste account |
That token is how we check which installations your own GitHub account can reach. GitHub limits it to what the App and you can both do, so it can never exceed the table above: signing in still cannot put a byte in a file.
What Crocotaste never does
- Never commits, never opens pull requests, never edits files in your repository. DESIGN.md and every recorded decision are written by you or by your own coding agent.
- Never requests changes on a pull request. Findings are a comment review, so a review never blocks a merge on its own.
- Never resolves your conversation threads or hides comments. A finding you fixed leaves the summary; its thread stays yours.
- Never reads a repository outside the installation, and never one the installation was not granted.
- Never treats a comment marker as proof. A comment claiming to be ours is checked against its author, because a marker in a body is something anyone can type.
Who can see the dashboard
What you see in the dashboard is what your own GitHub account can see: the installations you linked at setup are listed, the one you open is checked with GitHub, and only the repositories you can reach are shown, with their reviews and findings. We ask GitHub that question on every visit and keep none of the answer, so a repository you lose access to is gone from your dashboard on the next page you open. Uninstalling the App removes the link as well.
The dashboard shows the review balance, the review ledger per repository, billing, a Re-run button and a review mode per repository: automatic, on demand or paused.
Re-run and the review mode act on the same live answer the page does, and take write access: with read alone you see a repository's reviews and its state, and change neither. Access to an installation means you can see at least one of its repositories, which is not the same as all of them, so an outside collaborator on one public repository cannot pause the private ones beside it.
Changing the plan, buying a pack and opening the portal are for people who administer every repository the App is installed on, because the plan belongs to the whole GitHub account: an owner of the account always does, and someone who administers one repository among several does not.
There are no design rules there, and there never will be. A rules editor on our side would be a second source of truth competing with your DESIGN.md, and the one that lives in your repository is the one your agents read and your team reviews. A design decision takes effect by being merged into your file; see the DESIGN.md standard.
Who may issue commands
@crocotaste review and @crocotaste ignore are honoured only from people who can push to the repository (write, maintain or admin, asked of GitHub live through the metadata permission), so an outside contributor cannot spend your reviews or dismiss a finding. Their pull requests are reviewed when a member asks: the check says Skipped · ask a member for @crocotaste review, free, and the command runs it at once. Commands covers this in full.
Reducing the surface further
Install on the repositories you want rather than on all of them; GitHub's installation settings are the switch. Inside an installation, the dashboard's per-repository mode sets how reviews start: automatic, on demand (only @crocotaste review and Re-run start one) or paused, without removing anything, and no GitHub event ever changes it.
To stop everything, uninstall the App. Data and retention covers what is deleted and when.