Skip to main content
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 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.
  • “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: 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.
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 for initial setup.

Available settings

The table below applies to both team-wide defaults and per-project overrides, except where noted.

Advanced settings

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 ReviewsDeveloper 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:

Action taken

The Action taken column reflects what happened after the reply was classified: See Findings for managing the underlying findings.

Review limits

Developer count is based on unique developers interacting with Corridor—IDE users, dashboard users, and PR authors—in the given month.

Next steps

Findings

Track and manage security findings

Guardrails

Configure real-time security guardrails