Why full repo context matters for code review
Most "AI review" tools only see the diff you send them. That's a problem because a patch rarely stands alone — a renamed helper, a config file, a sibling module — the rest of the codebase usually decides whether the change is correct. A reviewer that only sees the patch ends up flagging things that are already handled elsewhere, and missing things that depend on context outside the diff.
The latest Cloud release, ThinkReview Cloud 2.4.0, is built around that gap. The headline change is how you grant Cloud access to your repositories, and what it can do once it has access.
GitHub App and GitLab.com OAuth for repo-wide reads
Previously, connecting a repo for full repository context required generating a personal access token and pasting it into ThinkReview. That works, but it's friction, and it's a token that has to be scoped, stored, and rotated.
Cloud 2.4.0 adds two first-party auth paths:
- GitHub App install — Click Connect on Integrations, pick the account or repos you want to grant access to, and the App handles the rest. No PAT to manage.
- GitLab.com OAuth — Same flow for GitLab.com repositories. Authorize once, Cloud can read the project, not just the diff.
PATs are still supported for self-hosted GitHub Enterprise, self-hosted GitLab, Bitbucket, Azure DevOps, or any case where installing the App isn't an option.
Reviews that look past the diff
With repo-wide read access, the first review on a PR can now look through the real project:
- Surrounding files in the same module
- How the changed function or class is used by callers
- Whether a flagged issue is already mitigated elsewhere in the codebase
The practical effect: fewer "the patch looks wrong" comments that ignore the rest of the repo, and fewer false positives that you'd otherwise have to defend in a reply.
Conflicting and overlapping PRs
A second consequence of repo-wide context is cross-PR awareness. Cloud reviews can now check other open pull requests / merge requests that touch the same files. If two in-flight changes are likely to collide — same function, same config, same generated file — the review can flag that instead of treating your PR as if it were the only one in flight.
This is most useful on long-lived branches and busy repos where merge order matters.
What you need
- A ThinkReview account with an active plan or available review credits
- A connection via Connect with GitHub or Connect with GitLab (recommended), or a PAT for self-hosted hosts, under Integrations
- The ThinkReview extension, MCP, or an API client calling the hosted review endpoints
Where to go
- Integrations: portal.thinkreview.dev/integrations
- Full release notes: thinkreview.dev/release-notes/cloud-v2.4.0
- Feedback: thinkreview.dev/feedback
- Bug reports: the "Report a Bug" button in the extension review panel
If your team has been holding off on giving an AI reviewer broader repo access because of the PAT step, this release is the path of least resistance.


Top comments (0)