Skip to main content
This page covers what permissions Neo needs on GitHub, who can install vs administer, and every config knob exposed at the repo and org level.

​
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

​
Organization permissions

​
Subscribed events

​
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.
Disconnecting from inside Neo is a per-user action — it clears your own GitHub identity link, not your teammates’. To actually uninstall, do it from github.com.

​
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”
The check is cached per (repo, user) to avoid round-tripping to GitHub on every page load.

​
Org-Wide Visibility Rules

Neo’s listing of which installs you see follows two layered rules:
  1. 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.
  2. 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.
If you can see an install in the list, you can authorize against it. Whether you can use a specific repo inside it is still governed by the per-repo collaborator check above.

​
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

Filter keys (set as comma-separated lists or repeated set commands):
  • author_include · author_exclude
  • label_include · label_exclude
  • branch_include · branch_exclude
  • keyword_include · keyword_exclude

​
Gating

Gating turns the GitHub check run into a hard merge block when a review finds high-severity issues: When gated, the PR’s merge button is disabled (assuming branch protection is configured to require the Neo check). Fixing the flagged issues — and pushing — triggers an incremental review that auto-resolves the prior findings; the next check run flips green and merge unblocks.

​
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