ManagePullRequest update_pr fails with "PR URL must belong to the current repository" when repo owner casing differs from GitHub canonical

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

Component: Cloud Agents — ManagePullRequest tool (and PR-resolution generally)

Environment:

  • Cloud Agent run (source: desktop), GitHub-connected repo
  • Run-registered repo owner casing: lowercase; GitHub canonical: mixed-case
  • (Run ID available privately on request.)

Summary:
update_pr validates that the target PR belongs to the current repo by comparing owner/repo slugs case-sensitively. The run’s registered repoUrl is stored lowercase (exampleorg), while the GitHub API returns the canonical casing (ExampleOrg). Since ExampleOrg ≠ exampleorg, the check rejects the operation even though both refer to the same repository (GitHub slugs are case-insensitive).

Steps to Reproduce

  1. Have a Cloud Agent whose registered repoUrl owner casing differs from GitHub’s canonical casing.
  2. ManagePullRequest action=create_pr … → succeeds, returns URL …/ExampleOrg/examplerepo/pull/1234.
  3. ManagePullRequest action=update_pr branch_name=<branch> body=… → fails.
  4. Also fails with action=update_pr pr_url=https://github.com/ExampleOrg/examplerepo/pull/1234 ….

Expected Behavior

Expected: update_pr succeeds; owner/repo matching is case-insensitive (or done by GitHub repo node ID), consistent with create_pr

Actual: Error managing PR: PR URL must belong to the current repository on every update_pr variant (both branch_name and pr_url forms).

Operating System

MacOS

Version Information

Version: 3.12.30 (Universal)
VS Code Extension API: 1.128.0
Commit: 63a2996a10d9e476b6c28e951dd7691d9c0cf480
Date: 2026-07-21T22:50:03.568Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

Additional Information

Evidence it’s a casing issue, not the local git remote:

  • Rewriting the local git remote to canonical casing (git remote set-url origin …/ExampleOrg/examplerepo) did not fix it — the comparison reads the run-registered repoUrl (confirmed via cursor-cloud run-info), not git remote.
  • create_pr works because it targets the registered repoUrl directly without cross-checking against the canonical PR URL.

Suggested fix:

  • Normalize both sides (lowercase owner/repo) before comparing, or match on the GitHub repository node ID rather than the slug string.
  • Apply the same normalization anywhere else a PR is validated against the current repo (post_comment, resolve_comment, get_ci_status, set_pr_status).
  • Optionally, store the run’s repoUrl using GitHub’s canonical casing at agent-creation time so downstream comparisons are consistent.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

6

Thanks for the detailed report. I checked this and confirmed that your diagnosis is correct. The Cloud Agent PR ownership check currently compares the GitHub owner and repository names case-sensitively, so a lowercase stored repository URL can reject GitHub’s canonical mixed-case PR URL. This also explains why changing the local Git remote does not help.

We’re tracking this internally, and a fix is currently under review. As a temporary workaround, you can ask the agent to use a pr_url whose owner and repository portions are fully lowercased when calling update_pr, . If that still fails, updating the PR description directly on GitHub is the reliable fallback.

Thank you again for raising this, and I’ll keep you apprised of any updates.

8

Thank you, Kevin. Looking forward to a fix. :slight_smile:

9

Kevin - Do you mind scrubbing our org & repo name out of your comment? It’s a private repo. Thank you.

10

Done

11

I’ve also been experiencing this, with an agent advising me to report it to Cursor. Glad you’ve already got a fix under review.

12

Thanks @DanG6 We’ll let you know when you have more info to share on the resolution.