feat(source-control): add Cursor Origin provider#33093

🟠 High server/OriginPullRequestProvider.ts:347

A push or retarget between getPull and this request makes /pulls/N/files return the newer version's patch, which this loader caches under the earlier base...head key for an hour. Callers requesting the earlier version then receive a mismatched diff; pin the files request to those commits or verify the PR version before caching the result.

No longer relevant as of e8dd3e969fdd7d87d676b232b09feb146c92aa8b

Fixed in 707e7abeaf. The /files read is now followed by a fresh read of the pull request, and the patch is cached for an hour only when that read still names the same base...head. Origin's /files ignores version parameters and /compare returns no files, so the patch can't be pinned in the request itself.

🟡 Medium server/OriginPullRequestProvider.ts:562

When involvement is "reviewing", listChangeRequests returns the unfiltered pull-request list, so the Reviewing partition includes unrelated PRs, including the viewer’s own. Only "authored" affects the query, and every result has reviewRequestLogins: []; filter reviewing results using requested-reviewer identities or reject this unsupported involvement instead of returning an apparently successful list.

Not changing this. Origin's list endpoint has no reviewer filter. The web client builds the Reviewing partition from viewerReviewRequested (apps/web/src/components/pullRequest/pullRequestList.logic.ts:231), so with Origin's empty reviewRequestLogins none of these rows reach Reviewing. Your own PRs land in Authored.

🟡 Medium server/OriginPullRequestProvider.ts:362

For a PR whose base.ref is refs/heads/main, this requests heads/refs/heads/main, so the Git ref lookup fails and mergeabilityOf reports unknown instead of using the prepared merge's definite answer. Strip the refs/heads/ prefix before adding heads/.

Not changing this. Origin returns base.ref as the bare branch name. The live API gives "base":{"ref":"main"}, and the panel shows main ← feat/wave. So the heads/${branch} path is correct.

🟠 High server/OriginPullRequestProvider.ts:601

Repositories with more than 100 matching pull requests cannot reach older results because this method always returns the first page and sets continues to false. It discards page.nextPageToken and never sends input.cursor as pageToken; propagate the token through resumeAfter and use the incoming cursor for the next request.

No longer relevant as of e8dd3e969fdd7d87d676b232b09feb146c92aa8b

Fixed in 707e7abeaf. Origin's page token is about 700 base64 characters, too long for the service cursor's resumeAfter (128 chars from [\w.:~+-]). The provider now keeps the token in an in-memory map and puts a hash key in resumeAfter. In the dev app, Load more on the Origin list grew it from 100 to 198 rows.

🟠 High server/OriginSourceControlProvider.ts:176

getChangeRequest returns the local repository’s PR 42 when given https://cursor.com/codebase/bob/lib/pull/42 from a checkout of alice/app, so callers can display a different PR than the URL identifies. cli.resolveRepository(input) selects the checkout repository, while originPullNumber discards the URL’s repository; parse and honor the URL repository or reject the reference when it does not match the checkout.

No longer relevant as of e8dd3e969fdd7d87d676b232b09feb146c92aa8b

Fixed in 707e7abeaf. A cursor.com pull request URL's repository is now used by getChangeRequest.

🟡 Medium server/OriginPullRequestProvider.ts:744

When a reviewer changes their decision, this filter removes their dismissed review and its body from comments and commentCount, even though dismissed reviews remain visible in Origin’s history. Map all reviews into activity so prior decisions are preserved.

No longer relevant as of e8dd3e969fdd7d87d676b232b09feb146c92aa8b

Fixed in 707e7abeaf. Dismissed reviews stay in the activity with reviewState: "DISMISSED", as the GitHub provider reports them.

🟠 High server/OriginPullRequestProvider.ts:820

Merging a stacked child through runAction also merges its unmerged ancestors, even though the panel presents only the child’s changes. The merge case calls the merge endpoint without detecting stack membership or requiring confirmation, and the service’s stack-action guard does not run when stackNumber is absent. Detect stacked PRs and reject this ordinary merge, or require explicit confirmation before invoking the full-stack operation.

No longer relevant as of e8dd3e969fdd7d87d676b232b09feb146c92aa8b

Fixed in 707e7abeaf. Origin's REST response carries stack.parentPullRequest. Merging a pull request whose parent is still open now fails with "This pull request is stacked on #N. Merge #N first, or merge the stack on Cursor Origin." I checked this in the dev app with a two-PR stack, and Origin left both unmerged.

🟡 Medium server/OriginPullRequestProvider.ts:136

Single-line review threads with endLine: 0 are returned with line: null, so PullRequestCodeTab renders their comments detached from the reviewed line. The ?? keeps zero instead of falling back to the valid startLine, and the following check nulls it; use startLine when endLine is not positive, while preserving null when neither is a valid line.

Not changing this. In the live API, line threads always set startLine == endLine (for example greet.ts with startLine: 3, endLine: 3). Only PR-level comments use 0/0, and those have path: "", which toThreads already skips.

🟠 High server/OriginPullRequestProvider.ts:143

After a PR advances, comments anchored to its previous version are still reported as current, so PullRequestCodeTab can attach them to unrelated code at the same path and line. Origin fixes each anchor to thread.version, but toThreads always sets isOutdated to false; compare the thread version with the current PR version and mark old anchors outdated.

No longer relevant as of e8dd3e969fdd7d87d676b232b09feb146c92aa8b

Fixed in 707e7abeaf. A thread is marked outdated when its version.headSha differs from the pull request's current head.

🟠 High server/originPullRequests.ts:337

checksState reports passing when every check is cancelled, so an aborted CI run is shown as green in the UI. The failing rollup handles failure and action-required but omits cancelled; include cancelled checks in that guard.

No longer relevant as of e8dd3e969fdd7d87d676b232b09feb146c92aa8b

Fixed in 707e7abeaf. Cancelled checks now count as failing, matching the GitCafe rollup.

🟡 Medium server/originPullRequests.ts:357

Rename patches are parsed as ordinary files, so the code tab loses the old filename and resolves the previous path to the new filename. The rename headers omit the similarity index that @pierre/diffs uses to retain rename metadata; emit 100% for pure renames and 0% for renames with a patch.

No longer relevant as of e8dd3e969fdd7d87d676b232b09feb146c92aa8b

Fixed in 707e7abeaf. Renames now emit similarity index 100% (pure rename) or 0% (rename with changes), like the GitCafe and Azure DevOps patches.

External image Minor · Functional Correctness · Quick win

Reject PR URLs for a different repository.

originPullNumber drops the repository from a URL. If a user passes other/repo/pull/7 in an acme/web checkout, lookup can return acme/web#7, and checkout passes 7 -R acme/web to the CLI.

Parse PR URLs with definition.parseChangeRequestUrl and return not-found when the parsed repository differs from the resolved repository, ignoring case. Preserve numeric references and other supported checkout inputs.

Fixed in 707e7abeaf. checkoutChangeRequest now rejects a cursor.com URL for a different repository, and getChangeRequest reads the repository the URL names. On the OpenGrep note: line 77 is RegExp.prototype.exec, not child_process.

@maria-rcks Thanks. I checked commit 707e7abeaf: lookup uses the URL’s repository, and checkout rejects a different repository without regard to case. The OpenGrep note is a false positive: Line 77 calls RegExp.prototype.exec.

I found URL parser tests, but no focused provider regression tests for these paths. Please add or link those tests and a short runtime transcript, as AGENTS.md requires for server-only fixes. I could not run the tests in this environment.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

_{You are interacting with an AI system.}

This repository adds new test files only when a maintainer asks for them, so I haven't added provider tests. If Maria wants tests for the pure helpers (pullReference, originFilesPatch, checksState), they can come in a follow-up.

Runtime checks so far, run against live Cursor Origin in the dev app:

• On 09a453ed0b, PR #2's panel ran origin pr checkout -R maria-rcks/t3-origin-e2e --remote origin 2 and switched the clone to feat/wave.
• Merging stacked probe PR #433 showed "This pull request is stacked on #432. Merge #432 first, or merge the stack on Cursor Origin." Origin reported both PRs still open and unmerged.
• A stale expectedHeadSha on /mergeability returned "head of pull request #2 does not match the expected SHA", which the provider turns into unknown and doesn't cache.

Not checked at runtime: a cursor.com URL for a different repository. That path has only been checked by reading the code (pullReference and checkoutChangeRequest in OriginSourceControlProvider.ts).

External image Major · Security & Privacy · Quick win

Do not leave a published repository team-visible when the privacy update fails.

createRepository runs in two steps. First, the POST creates the repository. Origin creates it as internal, which is visible to the whole team. Then, a separate PATCH sets visibility: "private".

The PATCH can fail after the POST succeeds. Causes include a timeout, a 429, a 5xx, or a 401 after the retry. In that case the effect fails, but the repository stays internal. The user sees a generic publish error. A retry cannot recover, because the POST now fails with "already exists". The docs state that Origin repositories "are published privately", so this failure path breaks a documented privacy promise without telling the user.

Proposed fix:

• Retry the PATCH a bounded number of times.
• If the PATCH still fails, return a specific error. The error must say that the repository was created but is still visible to the team, and must name the repository so the user can fix it.

✅ Confirmed as addressed by @maria-rcks

Fixed in 707e7abeaf. The make-private PATCH retries twice. If it still fails, publish reports that owner/name was created but is still visible to the Cursor team, and asks the user to set it to private on cursor.com.

@maria-rcks Thanks for fixing the privacy failure path.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

Review thread resolved.

_{You are interacting with an AI system.}

🟡 Medium server/originPullRequests.ts:372

Copied files with a different previousFilename are emitted with rename from/rename to, so the patch incorrectly says the source file was moved and no longer exists. Branch on file.status === "copied" and emit copy from/copy to headers instead.

Fixed in 6cd2daaaf4. Files with status copied now get copy from/copy to headers, matching the GitCafe patch builder.

I couldn’t verify commit 6cd2daaaf4; the branch snapshot I can access still emits rename headers for copies. It may not include your latest commit.

6cd2daaaf4 is an ancestor of the current head 09a453ed0b. At that head, originPullRequests.ts:369 sets const action = file.status === "copied" ? "copy" : "rename", and the header lines below it use ${action} from and ${action} to.

🟠 High server/OriginPullRequestProvider.ts:406

If the head or base moves after getPull reads the PR, /mergeability can return a verdict for the newer commits, which this cache then stores for an hour under the older head/base key. Because the request does not pass expectedHeadSha and OriginMergeabilitySchema discards the evaluated commit fields, the provider can report the wrong mergeability for that version; pass the expected head SHA and validate the response’s evaluated head and base before caching it.

Fixed in 6cd2daaaf4. The request now sends expectedHeadSha for the head in the cache key, and an answer whose headSha differs maps to unknown, which isn't cached. I checked live Origin: a stale expectedHeadSha fails with "head of pull request #2 does not match the expected SHA", which recover turns into unknown. Origin's response leaves baseSha empty, so the base is checked through the tip in the key instead.

I couldn’t access that commit to verify the fix. A base tip in the cache key alone doesn’t confirm the endpoint evaluated that tip if the base moved during the request.

Agreed that the key's base tip doesn't prove which base /mergeability evaluated, since its response leaves baseSha empty. I'm leaving it as is, because a wrong entry can't be read once the base has moved. The tip comes from a cache that lives 2 seconds (OriginPullRequestProvider.ts:395). After the base moves, the next read sees the new tip and builds a new key, so an answer stored under the old tip is only reused while the old tip is still cached, and that tip is already stale. The head side is pinned through expectedHeadSha.

Understood, thanks.

🟠 High server/originPullRequests.ts:98

A valid pull request without webUrl is rejected as invalid-response, and in a list response it rejects the entire page. webUrl is required by OriginPullRequestSchema even though Origin omits it when it cannot form a link; accept the missing field and provide a fallback URL when mapping the pull request.

Not changing this. I paged through every pull request in the test repository on live Origin (433 across list pages), and none came back without webUrl. If Origin ever does omit it, decoding fails as invalid-response with a clear message rather than showing a pull request without a working link.

🟠 High server/OriginPullRequestProvider.ts:321

When a pull request has more than 1,000 check runs, getChangeRequest can report checksState as "passing" even though an unread check is failing or pending. The checkRuns cache maps only page.items at line 321 and drops readPages(...).truncated; preserve that incompleteness so a partial result cannot be reported as passing.

No longer relevant as of 09a453ed0be2f89890ca78070c1a7910712a3e30

Fixed in 09a453ed0b. The checks read now keeps the truncated flag from paging. If more than 1,000 check runs are cut off, an all-green partial read reports pending instead of passing.

I couldn’t verify 09a453ed0b; it isn’t available in the checked-out branch. The code there still drops truncated.

🟠 High server/OriginSourceControlProvider.ts:78

Branch refs such as 123/fix and feature/pull/42 are parsed as PR numbers 123 and 42, so getChangeRequest fetches and checkoutChangeRequest checks out unrelated pull requests instead of treating them as branches. originPullNumber allows a /... suffix for non-URL input; restrict it to ^#?\d+$ because URLs are parsed separately.

✅ Resolved in 09a453ed0be2f89890ca78070c1a7910712a3e30

Fixed in 09a453ed0b. A plain reference only counts as a pull request number when it is exactly 42 or #42. 123/fix and feature/pull/42 stay branch names, and cursor.com URLs still go through parseChangeRequestUrl.

I couldn’t verify 09a453ed0b: it isn’t available in the checkout I can access, which still has the original regex. Could you check the commit hash or push?