> ## 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. # Admin & Permissions > GitHub App permissions Neo requests, who can install vs use, the full per-repo and org configuration surface, gating, and the GitHub-side collaborator gate. 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: 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 ` updates a single setting for the current repo without leaving the PR. Same `@pdneo config get ` 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. | 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: | 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. | 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 * Daily usage and commands: [Use Neo On GitHub](/integrations/github-use-neo-on-github) * Errors and edge cases: [Troubleshooting](/integrations/github-troubleshooting) * Data handling: [Privacy & Support](/integrations/github-privacy-and-support)