Read-Only Mode
Run Cygent against your repos with zero write access — audits and reviews, no PRs, no commits, no issue changes.
Overview
By default, Cygent's GitHub App can write: it opens pull requests, pushes to feature branches, creates issues, and posts review comments. For some teams — a security-sensitive org evaluating the product, a cautious first rollout, a repo where write access has to be earned — that's more than you want to grant on day one.
Read-only mode is the answer. It's a separate GitHub App installation with no write scopes at all. Cygent can read your code, audit it, and review PRs, but it physically cannot change anything in GitHub — the permission simply isn't granted at the GitHub App level, not just disabled in software.
Read-only mode is a per-instance setting. You can run one instance read-only while another has full access, and you can switch an instance between modes at any time.
Two apps, not a software switch
This is the important part: read-only mode isn't a checkbox that asks Cygent to behave. It's a genuinely different GitHub App with reduced scopes.
| Full access | Read-only | |
|---|---|---|
contents | write | read |
pull_requests | write | read |
issues | write | read |
metadata | read | read |
Because the write scopes aren't on the installation, there's no path — bug, prompt injection, or otherwise — by which Cygent writes to your repo in read-only mode. The guarantee is enforced by GitHub, not by Cygent's own code.
What works and what doesn't
Still works
Cloning and reading code · full audits · PR reviews (reading the diff and analysing it) · reading issues and PRs · everything in chat that doesn't write to GitHub · creating issues in Linear or Jira
Blocked
Opening or pushing fix PRs (Cygent Code) · creating, closing, or labeling GitHub issues · posting PR review comments · Battle Mode defense PRs
When you ask Cygent to do something that needs write access while in read-only mode, it won't fail silently — it tells you the action requires full GitHub access and links you to the settings page to switch.
The biggest thing you give up is the remediation loop. Cygent Code can still plan and explain a fix, but it can't open the PR. If fixing findings from chat is core to how your team wants to work, read-only mode isn't the right fit — use full access and lean on autonomy settings to control when it writes instead. See Behavior & Autonomy.
Choosing a mode at install
When you connect GitHub during the install wizard, you choose which app to install — full or read-only. Installing the read-only app sets the instance to read-only from the start. If you're not sure, install read-only first; switching to full later takes one click.
Switching modes later
You can change an instance's mode anytime from the dashboard:
Open instance Settings
Change the GitHub permission mode
Switch between Full access and Read-only. Switching installs (or points the instance at) the corresponding GitHub App.
Let the instance restart
The agent restarts with the new app's credentials so the change takes effect. In-flight work isn't affected retroactively — the new mode applies going forward.
Once read-only, the dashboard shows a read-only badge and hides the buttons for actions that would write — so the UI matches what the integration can actually do.
When to use read-only mode
| Situation | Why read-only fits |
|---|---|
| Evaluating Cygent | See the quality of audits and PR reviews before granting write access |
| Security/compliance constraints | Some orgs can't grant write to a third-party app without a review process |
| A locked-down repo | Read the code and review PRs without any ability to change the repo |
| Cautious rollout | Start read-only, build trust, upgrade to full when you want the remediation loop |