TL;DR: Claude Ultrareview CI trust is controlled by the --trust-workspace flag, which grants Claude elevated file-system permissions and should never be used on untrusted pull requests from external contributors. Safe CI pipelines omit that flag on unreviewed fork PRs, reserve it for internal branches only, and expect $5-$25 per run after the free tier ended May 5, 2026. Last verified: May 2026.As of May 2026, the platform details in this article reflect the post-free-tier environment. Claude Code tooling changes frequently; verify current flag behavior against the official Claude Code documentation before deploying.
Key takeaways
- Fork PRs need an untrusted-PR pattern: Passing-trust-workspace on a forked PR hands elevated permissions to code you do not control. Run it in an isolated environment without the flag instead.
- Every review run carries a real cost: The free tier ended May 5, 2026. A misconfigured trigger firing on drafts or external-contributor PRs burns credits silently.
- Some platforms cannot use ultrareview: Certain deployment configurations block ultrareview access. This is author-reported based on community experience; verify your specific deployment against current Claude Code documentation before assuming availability.
- @claude review stop is your cost kill switch: It halts an in-progress review before billing completes.
- Define when NOT to trigger reviews: Draft PRs, formatting-only changes, and first-time external contributors are prime candidates for skipping entirely.
Introduction
Two considerations permanently changed ultrareview's CI calculus: the --trust-workspace flag requirement and the @claude review stop command. Together they create a paired security-and-control system that many CI configurations have not caught up to yet.
The billing reality draws attention first. The trust boundary, which grants contributor-controlled project files execution rights inside your privileged CI runner, draws far less scrutiny. One practitioner burned $241 across 18 PRs after the free tier ended. The billing problem is solvable with better conditionals. Misconfigured trust on a shared runner creates a different category of exposure entirely.
What does --trust-workspace actually grant, and why does it matter for CI security?
Passing --trust-workspace tells Claude Code that the agent may read workspace-level configuration files, including .claude/settings.json, git hooks, and other project-level config. These are execution surfaces, not static data. A malicious .claude/settings.json committed to a forked PR branch can influence how the review agent behaves on your runner.
A shared GitHub Actions runner that processes public-repo PRs with --trust-workspace added globally means every external contributor's project settings run inside your privileged environment. Treat the flag like sudo: it should be passed deliberately, scoped narrowly, and guarded by explicit conditionals.
The practical consequence is straightforward. Without the flag, Claude Code will not run ultrareview, which is the correct and safe outcome for any branch whose files you have not yet reviewed. The flag is a declaration, not a convenience toggle.
How do you safely run ultrareview on a forked PR without granting workspace trust to untrusted code?
The safe pattern for forked-repository pull requests is to run ultrareview in an isolated, ephemeral environment without --trust-workspace, gated on PR author membership before the review job starts.
This untrusted-PR pattern, as used in this guide, has three components:
1. Runner isolation. Use ephemeral runners so no persistent workspace state carries between jobs. A contributor-controlled .claude/settings.json cannot affect a runner that is destroyed after the job completes.
2. Trust-flag suppression. Do not pass --trust-workspace when github.event.pull_request.head.repo.fork == true. Without the flag, Claude Code will not run ultrareview, which is the intended behavior for untrusted branches.
3. Author-tier gating. Use github.event.pull_request.author_association to distinguish MEMBER or COLLABORATOR from FIRST_TIME_CONTRIBUTOR or NONE. Only promote to trusted-workspace review after a maintainer approves the branch.
Table 1: Ultrareview Trust-Flag Decision Matrix
| PR source | Author association | --trust-workspace | Review action |
|---|---|---|---|
| Origin branch | MEMBER / COLLABORATOR | Pass flag | Full ultrareview |
| Fork branch | MEMBER / COLLABORATOR | Suppress flag | Skip or manual trigger |
| Fork branch | FIRST_TIME_CONTRIBUTOR | Suppress flag | Skip entirely |
| Fork branch | NONE | Suppress flag | Skip entirely |
| Any | Draft PR | Not applicable | Skip entirely |
Table 1 summarizes the practical rule of thumb this guide uses: the flag decision follows from PR source and author association, not from feature enablement. The YAML conditional if: github.event.pull_request.head.repo.fork == false is the single cheapest CI security control you can add today. If a review starts on a misclassified PR, @claude review stop is your immediate intervention.
What is the real cost structure and when should teams skip the review entirely?
When NOT to trigger ultrareview in CI (a practical framework used in this guide):
- Draft PRs (
draft: true) - Single-file changes under a configurable line threshold
- PRs from
FIRST_TIME_CONTRIBUTORorNONEauthor association - PRs touching only docs, lock files, or auto-generated files
- PRs labeled
skip-review - Any PR where
--trust-workspacemust be suppressed
Frequently asked questions
Does ultrareview run automatically on every PR once I enable it in CI?
No. Claude Code requires the --trust-workspace flag to run ultrareview. Adding it globally without PR-type conditionals means the tool attempts to run on every matching PR, including drafts and forks, which creates both a security exposure and an uncontrolled billing surface.
Can I pass --trust-workspace safely on a fork PR if I check out only the diff?
No. The flag grants trust at the workspace level, not the diff level. Any fork-branch files present in the checked-out workspace breach the security boundary. Suppress the flag entirely on fork PRs regardless of what subset of the repository you intend to examine.
What is the relationship between @claude review stop and the --trust-workspace flag?
They address different failure modes. The stop command handles runtime cost interruption after a review has already started. The trust flag is the security gate that determines whether a review should start at all. A production CI pipeline needs both: conditionals to prevent bad triggers, and a runbook entry for stopping reviews that slip through.
What are the alternatives for teams on deployment configurations where ultrareview is unavailable?
Based on author experience with blocked environments, practical alternatives include API-based review workflows, compliant third-party CI tools, or structured human review with AI-assisted summarization. There is no flag or configuration workaround that unlocks a hard-blocked deployment; verify your environment's current status against official Claude Code documentation.
Conclusion
--trust-workspace is a declaration that contributor-controlled files have earned the right to influence a privileged agent inside your CI infrastructure. On a fork PR from an external contributor, that declaration is rarely correct.
Audit your CI YAML today: search every --trust-workspace invocation and confirm each one is guarded by github.event.pull_request.head.repo.fork == false. Add the guard where it is missing. Then add @claude review stop to your incident runbook before you need it. Both controls are cheap to implement and expensive to discover you skipped.
References
Learn from me
Forward Deployed Engineering Bootcamp for Full-Stack Developers, my Maven cohort. Build and ship complete AI products end to end, from React and Node.js frontends to deployed models with caching and observability. Join the next cohort →
Hire us
Traversaal.ai. We're a team of forward deployed engineers solving the toughest AI problems for Fortune 100 companies: document intelligence, agentic data platforms, and real-time web intelligence, deployed in production. Work with our team to deploy your next agentic ecosystem. Talk to Traversaal.ai →
Join us
Want to solve these problems with us? We're always looking for forward deployed engineers who want to ship production AI. jobs@traversaal.ai
