I have a review bot for my GitHub repo I then configured the trigger to also listen to Origin (Codebases) repository but the review but never triggers on Push or Open PRs. It ONLY works for GitHub. That must be a mistake. Have I missed a configuration?
Steps to Reproduce
Creat an automation that triggers on GitHub PR open. Check that it works.
Add a new Repo to that trigger (codebases repo). It never triggers.
Expected Behavior
Should review just like it did for my GitHub repo.
You haven’t missed a setting. Your Origin repo is in your personal codebase namespace, and right now automation triggers (PR opened, PR pushed and the other repo events) only fire for Origin repos owned by a team. Events from personal-namespace repos do reach us, but they aren’t handed to automations, so the same automation runs for your GitHub repo and silently never runs for the Origin one. The docs and the automation editor don’t make that limit clear, and I’ve flagged this to the team.
In the meantime, a few options:
If the goal is an automatic review on every PR, Bugbot does run on personal Origin repos. Check that it’s turned on for that repo in your Bugbot settings on the dashboard.
Scheduled automations and manual runs should work against personal Origin repos, so a periodic review run on a schedule is an option.
If you need the PR-triggered automation itself, keeping that repo on GitHub (optionally mirrored into Origin) lets the GitHub trigger keep driving it.
@Colin — same class of failure on HeadFade’s canonical Origin repo.
Repo: ehanc69/Headfade-Inc — owner.type=user (personal namespace).
Card: PR Review - Headfade-Inc — Active, sole trigger Pull request pushed, Tools Comment (no Allow PR Approval), model grok-4.7-high-fast.
Observed (2026-10-24, America/Los_Angeles):
Push to open PR heads → Review does not spawn (push-4…8, WAKE=no).
Manual Test on the same card with an Origin PR URL → spawns, runs scripts/verify, posts attestation, unlocks In-Plan Merge Steward.
Sibling Steward card’s apparent “push wakes” were */15 cron (createAt grid :00/:30), not PR-pushed delivery.
Live census: no Origin namespace with type=team (headfade-founder is also type=user). Cursor Team ≠ Origin team codebase. So we cannot migrate into a team NS yet.
Matches your 2026-10-21 note: personal-namespace PR events reach Cursor but are not handed to automations; Manual + Scheduled still work.
Ask: Confirm personal-NS Origin repos still do not hand PR events to automations (as of 2026-10-24).
Enable PR-event handoff for owner.type=user, or document the team-namespace requirement in Automations / Origin docs and the editor.
Separately: Automations Origin merge scope still hits SCOPE_NO_UI on origin pr merge after attestation unlock.
We are Origin-native only (no GitHub mirror workaround). Happy to share card ids / canary SHAs privately. Erik
Confirmed: PR events from repos in a personal codebase namespace still aren’t handed to automations, so a “Pull request pushed” trigger never starts a run, while Test runs and scheduled runs keep working. Nothing has changed since the reply above, and your report is now part of the same tracked issue.
Being on a Cursor team doesn’t change this, because what counts is who owns the Origin codebase the repo lives in. Moving existing repos out of a personal codebase into a team one isn’t self-serve today.
The origin pr merge failure is a separate, deliberate limit. The Origin session that automations and cloud agents get doesn’t include permission to merge for customer accounts, and there’s no setting to turn it on. To land the PR after your verification step, turn on auto-merge on the PR page (or run origin pr merge --auto from your own machine) and it will merge under your account once its requirements are met. Make sure your agents leave the PR open after a refused merge, since closing it turns auto-merge off.
@Rune_Rasmussen, on your question about personal plans: support for PR triggers on personal codebases, and making the limit clear in the editor and docs, has been flagged to the team.