GitHub App Permissions
When you install Neo, GitHub asks you to grant a set of permissions and event subscriptions. These are the App’s published permissions — they apply at install time and govern everything Neo can do on that org or account.Repository permissions
| Permission | Access | Why |
|---|---|---|
| Contents | Read | Clone the repo for scanner and agent analysis. |
| Pull requests | Read & Write | Read diffs, post summary and inline review comments, resolve threads. |
| Issues | Read & Write | Create issues via @pdneo create issue. |
| Checks | Read & Write | Post the check run that shows review status and (optionally) gates merge. |
| Metadata | Read (mandatory) | Required by GitHub for any App to function. |
Organization permissions
| Permission | Access | Why |
|---|---|---|
| Members | Read | Verify whether a Neo user is a member of the org for access control. |
Subscribed events
| Event | Why |
|---|---|
| Install lifecycle and repository grants | Keep Neo’s view of which orgs and repos are connected in sync with GitHub. |
| Pull requests opened or updated | Trigger reviews when PRs open or new commits land. |
| PR review and issue comments | Handle @pdneo commands. |
| Review-thread state changes | Detect when a reviewer manually resolves a Neo review thread. |
Who Installs vs Who Uses
The install flow and day-to-day usage are separable concerns.- GitHub org admin (or personal-account owner): approves the App install on github.com. Required to add new repos to an existing install with the “selected repositories” scope.
- Neo installer: any authenticated Neo user. If they don’t yet have a Neo team, one is auto-created and they become its admin.
- Neo team admin: manages team-level Neo concerns (members, billing, deletions).
- Neo team members: use Neo on PRs they have GitHub access to. The per-repo collaborator gate (next section) enforces this at use time.
Per-Repo Access Via GitHub Collaborator Check
Once an install is connected to a Neo team, Neo doesn’t blindly let every team member act on every repo. Each per-repo operation (view repo, change repo config, list PRs, trigger a review on a PR, fetch repo metadata) goes through a GitHub collaborator check: Neo asks GitHub whether you have collaborator access on that specific repo and defers to GitHub’s answer. This means:- a teammate can install Neo on an org you’re a member of — you’ll see it in Neo
- but acting on a specific repo requires you to actually be a collaborator on that repo on GitHub
- you can’t escalate from “Neo team member” to “GitHub repo access you don’t have on GitHub itself”
Org-Wide Visibility Rules
Neo’s listing of which installs you see follows two layered rules:- Team trust: Neo surfaces installs owned by you or any teammate in your Neo team. Installs that target a personal GitHub account are scoped to their owner — teammates don’t inherit access to someone’s personal install.
- GitHub org membership: for org installs you’re not the owner of, Neo verifies with GitHub that you’re a member of that org before surfacing the install. This requires you to have authorized Neo via OAuth first — which is the default Connect flow.
Repository And Organization Configuration
Reviews are configurable at the repo level and have org-level defaults that new repos inherit when they join the install.From the Neo UI
Settings → Applications → GitHub → click the org switcher → pick an org → adjust:- Auto Review — turn automatic-on-push review on or off
- Review Triggers / Filters — author / label / branch / keyword filters for which PRs Neo should review
- Global review instructions — free-text custom guidance for the agent
- Output & Enforcement — gating, suggested-changes toggle, etc.
From a PR comment
@pdneo config set <key> <value> updates a single setting for the current repo without leaving the PR. Same @pdneo config get <key> to read it back.
Full config-key reference
| Key | Allowed values | What it controls |
|---|---|---|
verbosity | normal · brief · detailed | How much detail per inline comment. |
severity | all · info · low · medium · high · critical | Minimum severity to report. |
draft | skip · review · summary_only | How to handle draft PRs. |
gating | none · block_on_critical · block_on_high | Whether the check fails the PR. |
auto_review | true · false | Master switch for automatic on-push reviews. |
suggested_changes | true · false | Whether inline comments include suggested change blocks. |
set commands):
author_include·author_excludelabel_include·label_excludebranch_include·branch_excludekeyword_include·keyword_exclude
Gating
Gating turns the GitHub check run into a hard merge block when a review finds high-severity issues:| Value | Behavior |
|---|---|
none (default) | Check run reports findings but is always green. |
block_on_critical | Check fails (red) if any finding is critical severity. |
block_on_high | Check fails if any finding is high or critical. |
Auto-Resolve Of Review Threads
If a prior Neo inline comment’s underlying issue is fixed in a new commit, Neo automatically resolves the comment thread on GitHub. You don’t have to manually click “Resolve conversation” — incremental review handles it. If a human resolves a Neo comment thread without fixing the issue (e.g., dismissing a false positive), Neo respects that and doesn’t reopen the thread on subsequent reviews.Org-Wide Settings
Settings configured at the org level become the defaults for newly added repositories under that install. Existing per-repo overrides are not retroactively changed. Org-wide changes are admin-only.Next
- Daily usage and commands: Use Neo On GitHub
- Errors and edge cases: Troubleshooting
- Data handling: Privacy & Support