Documentation Index
Fetch the complete documentation index at: https://docs.neo.projectdiscovery.io/llms.txt
Use this file to discover all available pages before exploring further.
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
| 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.
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:
- 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.
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.
@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
