> ## Documentation Index
> Fetch the complete documentation index at: https://docs.corridor.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# PR Reviews
> Automated security reviews on every GitHub pull request with actionable findings and low false positive rates.
Corridor's Pull Request (PR) review feature acts as an automated security reviewer for your code changes. Whenever you open or update a PR, Corridor analyzes the diff for potential security issues and provides feedback directly in the PR.
## Developer workflow
Treat Corridor's comments like those from a human reviewer specialized in security:
1. **Understand the issue**: Read the explanation and remediation guidance
2. **Push a fix**: Push additional commits to address the problem. Corridor will re-check the PR on the new commit
3. **Reply to discuss or provide feedback**: Reply directly in the PR thread to ask follow-up questions, flag a finding as a false positive, or request an unblock. See [Replying to Corridor's comments](#replying-to-corridors-comments) below
4. **Handle false positives**: If you believe a finding is a false positive, reply with the reasoning, or mark it as **Won't Fix** in the dashboard. This feedback helps Corridor learn and helps the security team adjust guardrails
Once all issues are resolved, Corridor's status check will turn green and you can merge knowing the security review is clear.
### Replying to Corridor's comments
You can reply to any Corridor review comment in the PR thread to keep the conversation in GitHub. Corridor reads the thread and responds in-line. Common things to say:
* **"This is a false positive because..."** — Corridor evaluates your reasoning and closes the finding as a false positive. Corridor also performs AI enrichment on reported false positives and aggregates them into a feedback report at [app.corridor.dev/pr-reviews/feedback](https://app.corridor.dev/pr-reviews/feedback).
* **"Please unblock this PR"** — Corridor reviews the request and, if warranted, removes the blocking status on the finding.
* **A follow-up question** — Corridor answers in context using the same code understanding it used for the original review.
Corridor signals where it is in the workflow by adding emoji reactions to your reply:
| Reaction | Meaning |
| -------- | ---------------------------------------------------------------- |
| 👀 | Your reply was received and Corridor is processing it |
| 👍 | Processing finished — look for Corridor's response in the thread |
If you don't see a 👀 within a minute or two, Corridor most likely decided no response was warranted (for example, the reply was a thank-you or directed at another participant). You can always re-reply with a more specific question to re-trigger processing.
## Configuration
PR review settings can be configured at two scopes:
* **Team-wide defaults** apply to every project on the team. Configure them on the **PR Reviews** page → **Configure** (top right corner).
* **Per-project overrides** apply to a single project and take precedence over the team default. Configure them on the project page → **Settings**. See [Project Settings](/onboarding/adding-projects#project-settings).
By default, a project inherits every setting from the team. When you override a setting on a project, only that setting is detached from the team default—other settings continue to inherit. Use **Reset to Team Defaults** on the project settings page to clear overrides and resume inheritance.
See [Connecting GitHub](/onboarding/connecting-github) for initial setup.
### Available settings
The table below applies to both team-wide defaults and per-project overrides, except where noted.
| Setting | Description |
| --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Enable Pull Request Reviews** | Automatically review pull requests for security vulnerabilities |
| **Block PRs with Security Findings** | Prevent merging pull requests that contain security vulnerabilities (blocks can still be overridden in GitHub). Corridor Team only. Team-wide setting |
| **Review Verbosity Mode** | Control how inclusive the PR reviewer is when flagging potential security issues. Standard review mode provides a balanced approach between catching vulnerabilities and minimizing false positives |
| **Leave Comments on Pull Requests** | Post review comments directly on GitHub PRs |
| **Disable Comments for Specific Repos** | PRs from selected repositories will still be reviewed but comments won't be posted. Team-wide setting—to disable commenting for a single project, turn off **Leave Comments on Pull Requests** in that project's settings instead |
### Advanced settings
| Setting | Description |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| **Enable Draft PR Reviews** | Review pull requests that are marked as draft |
| **GitHub Label Filter** | Optionally restrict review comments to PRs with a specific label |
| **Comment When No Issues Found** | Leave a comment even when no vulnerabilities are detected |
| **Minimum Severity to Comment On** | Only post PR comments for findings at or above the selected severity level (Medium, High, or Critical). Defaults to all issues |
| **Enable Threat Modeling** | Include threat model analysis with risk level and security considerations on all PRs |
## How it works
When a pull request is opened or updated:
1. **Webhook trigger**: GitHub sends a webhook to Corridor
2. **Diff analysis**: Corridor analyzes only the changed code, understanding context from the broader codebase
3. **Security review**: The changes are evaluated against security best practices, known vulnerability patterns, and your guardrails
4. **Review posted**: Findings appear directly on the PR with inline comments
5. **Corridor Review check**: GitHub shows a **Corridor Review** check on your pull request. It moves from **Queued** to **In progress** while Corridor reviews your changes, and to **Success** when the review is finished. The check does not block merging on its own. Click **Details** to open this review in the Corridor dashboard.
Corridor's reviews are context-aware—not just pattern matching. The review understands your codebase structure, existing security patterns, and the purpose of the changes. Each finding includes specific remediation steps, not generic advice.
## Developer Feedback
The **Developer Feedback** page is available to **team admins** only.
When a developer replies to a Corridor PR comment—accepting a finding, pushing back on a false positive, or asking to unblock—that exchange is captured on the **Developer Feedback** page (**PR Reviews** → **Developer Feedback** in the sidebar). Admins use this page to review every reply for the selected team alongside the action Corridor took in response, so you can see how Corridor is learning from your developers.
Each row shows the date, PR number, finding, the developer's comment, a sentiment classification, and an **Action taken** summary. Click a row to open the full thread or jump to the finding.
### Sentiments
Corridor classifies each developer reply into one of four sentiments, which you can filter by:
| Sentiment | Meaning |
| ------------------- | ------------------------------------------------------------------------------------------- |
| **True Positive** | The developer confirmed the finding is a real issue |
| **False Positive** | The developer pushed back on the finding |
| **Unblock Request** | The developer accepted the risk and asked to unblock the PR |
| **Other** | A reply that did not change the finding's state (clarifying question, acknowledgment, etc.) |
### Action taken
The **Action taken** column reflects what happened after the reply was classified:
| Action | When you see it |
| ---------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| **Marked as false positive · AI agreed** | A second-pass review confirmed the developer's false-positive claim |
| **Marked as false positive · AI flagged for review** | The second-pass review disputed the false-positive claim—worth a look from the security team |
| **Marked as false positive · analysis pending** | The follow-up analysis is still running |
| **Confirmed as a real issue** | The finding was kept open for remediation |
| **PR unblocked · risk accepted** | The PR was unblocked despite the finding |
| **Replied — no state change** | A non-actionable reply was recorded but the finding's state was not changed |
See [Findings](/features/findings) for managing the underlying findings.
## Review limits
| Tier | PR Reviews |
| ---------- | ------------- |
| Pro | 100/month |
| Team | 100/dev/month |
| Enterprise | Unlimited |
Developer count is based on unique developers interacting with Corridor—IDE users, dashboard users, and PR authors—in the given month.
## Next steps
Track and manage security findings
Configure real-time security guardrails