FAQ
Which VCS integrations are supported?
PR Review works with the GitHub and GitLab integrations. A project must be bound to a repository from one of these connections.
A Bitbucket connection gives a project its source, its assessments and its scans. AISafe does not review Bitbucket pull requests yet.
The review format is the same across providers: one summary comment, edited in place as you push, plus inline comments on the findings that carry a fix or a high severity. The status object differs. GitHub gets a check run; GitLab gets a commit status, which GitLab records as a pipeline job. See GitLab for what that means for a project with no CI.
How does PR Review differ from a code audit?
A code audit is a full assessment of your codebase. PR Review is a continuous capability of a project that audits only the changed paths of a pull request and posts inline comments. It is not a full assessment. For complete coverage, run a code audit or use Source Code Audit.
On which repositories can PR Review comment?
PR Review posts comments on pull requests in any repository you grant to the GitHub or GitLab integration and bind to a project. The integration must have pull-request webhook permissions for the target repository. Bitbucket repositories are not reviewed yet.
How much does each review cost?
Each workspace pays for its own review attempts. Each new push or authorized request uses one included review, then costs $1 when the allowance is exhausted. A push containing several commits produces one review of its latest commit. Duplicate deliveries and internal retries reuse that attempt. Adding funds does not restart a refused review; comment @aisafe review, use Run again, or push a new commit. See Credits & billing.
How do I know why a PR was not reviewed?
Open the project's Source tab and inspect the delivery log. Delivery rows show the repository, commit, event type, status, and a readable ignored reason such as an unbound project, branch filter mismatch, or disabled PR review. See How it works.
Is PR Review a full assessment?
No. It reviews only the changed paths of a pull request and returns inline comments instead of a full findings report. For a full assessment of your codebase, use code audit.
Can one project review several repositories?
Yes. Connect up to five repositories from the same provider — every plan includes five — then configure PR review for each repository independently. Each PR review uses the complete application context and keeps the companion repositories at a fixed commit during the comparison. One project's source holds five repositories; for a larger application, write to [email protected].
Can two projects claim the same repository?
Within one workspace, you explicitly select one project for a repository's PR reviews. AISafe refuses a competing selection instead of silently dropping one of the projects. Different workspaces may each select a project; each of them receives independent reviews, comments, checks, results, and charges.
Why did the required check name change?
Each workspace and project now publishes its own check. Copy its exact name from PR Reviews → Settings and update branch protection rules that require the old generic name. AISafe preserves ambiguous old comments and checks rather than letting one workspace overwrite another's history.
What happens when I add or remove repositories?
Saving the change resets the entire living knowledge base after active runs finish. Historical assessments, reports, findings, and revisions remain available. New runs pause while a change is pending. Setup shows a retry action if the change needs to resume.
Why did my review fail?
When a review fails, AISafe shows the cause. You can find it on the review in AISafe, or in the check run on the pull request.
| What you see | What to do |
|---|---|
| Could not read the repository snapshot for this pull request. | Push a new commit or re-run. If it repeats, check the repository connection. |
| The repository snapshot is larger than PR review supports. | Exclude large directories in the project's source settings. |
| This pull request changes more code than one review can cover. | Split it into smaller pull requests, or narrow the review with path filters. |
| The provider's list of changed files did not match the repository contents. | Push a new commit or re-run. |
| This pull request changes only generated, binary or vendored files. | Nothing. There was nothing to review. |
| Could not verify the evidence behind this review, and withheld it. | Re-run the review. |
| This review was withheld: it did not pass publication checks. | Re-run the review, or push a new commit. |
| The review finished and the provider refused to post it on this pull request. | Check the four things the sentence names: the AISafe app's write access to the repository, a branch rule rejecting its check, whether the pull request is still open, and whether the review is small enough for one comment. Fix the cause, then re-run. The findings are already on the review in AISafe. |
| The review ran out of analysis budget before finishing. | Split the pull request, or narrow the review with path filters. |
| The analysis provider was unavailable. | Re-run the review once it is back. |
| This review could not complete. | Update the pull request to retry. If it repeats, write to [email protected]. |
A failed review is refunded. Re-running one is charged like any review.
A review the provider refused is refunded too, and it keeps its findings, because the analysis finished and only the delivery to the pull request failed. You can read the findings on the review in AISafe while you fix the cause of the refusal.
Why does a review say it covered only some of the changed files?
Each review states which files it actually read. When a pull request is larger than one review can cover, AISafe reviews as much of it as the limits allow and says so in the summary. The summary gives how many changed files AISafe read, how many it skipped, and why (the review size limit, a single file whose change is too large, or the time limit). AISafe names each skipped file, and a skipped file never fails the review.
A result of "No security findings" across part of a pull request means something different from "no security findings" across all of it, so the summary never makes the two look alike. To cover the rest, split the pull request or narrow the review with path filters, so that the review budget is spent on the files that matter most.