[Bug]: GitHub repository lookup rejects a bare repo name and hides the reason behind a generic error #17230

Activity

1. juliusmarminge commented on Oct 8, 2026

   

   juliusmarminge

   on Oct 8, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Thanks for the detailed report. I checked it against main at 9a3070b, and both halves look accurate.

   1. Bare names stopped resolving to your own account (looks like a regression from #16321)

   • parseGitHubRepositorySelector accepts a URL, owner/name, or host/owner/name, and returns null for anything else. Its doc comment says it was written for the gh --repo / GH_REPO format.
   • getRepositoryCloneUrls fails on that null with "Repositories are named owner/name." (L977), so no request reaches GitHub.
   • Before feat(server): source control, media and discovery use GitHub's API instead of gh #16321, the input went straight to gh repo view <input>. gh's repo view prefixes a slash-less argument with the current login. feat(server): source control, media and discovery use GitHub's API instead of gh #16321's description doesn't mention dropping bare names, and I couldn't find a test that asserts the rejection, so this looks unintended rather than a deliberate change.
   • One small correction: on a bare name, createRepository doesn't call readViewerLogin. That call only happens when a locator parsed (L990). Instead it posts to user/repos. The outcome is the same, since a bare name means "mine". For lookup, though, there's no equivalent endpoint, so the fix would need readViewerLogin (GET user) on fallbackHost to build <viewer>/<name>.

   2. The reason gets replaced by a generic message

   • mapRepositoryError replaces every provider detail with "The source control operation could not be completed." (L104). The one exception is Bitbucket's locator error, added in fix(server): reject invalid explicit Bitbucket repositories #15876. A test pins this behavior for a GitHub lookup failure (SourceControlRepositoryService.test.ts:151-154).
   • The masking appears deliberate. It came from [codex] structure source-control repository failures #3336, which keeps raw provider text on cause so nothing sensitive reaches clients. Since then, though, the GitHub provider has started writing its detail as user-facing text (L262-L271). So messages like "Repositories are named owner/name." and "Repository not found. Check the owner and name and try again." are written for users but don't appear to reach them.
   • One caveat for the fix: passing every GitHub detail through wouldn't be completely safe. For request and response errors, L304-L308 forwards error.message. A small allowlist of fixed messages (format, not found, auth, rate limit), or a marker on the error saying it's safe for users, would fit the [codex] structure source-control repository failures #3336 intent better.

   Client side: both clients hint at the format. Web's prompt reads "Enter GitHub repository (owner/repo)" (CommandPalette.tsx:356), and mobile uses owner/repo as the placeholder (AddProjectScreen.tsx:847-850). Neither checks the input before lookup.

   Related

   • [Bug]: Bitbucket repository lookup of a name without workspace fails with a generic error instead of a validation message #15193 / fix(server): reject invalid explicit Bitbucket repositories #15876: the same masking problem, fixed for Bitbucket only.
   • fix(server): explain invalid GitHub repository paths #8300 (open): adds an "Enter a GitHub repository as owner/repo." check before lookup, but it predates feat(server): source control, media and discovery use GitHub's API instead of gh #16321. Its ^[^/\s]+/[^/\s]+$ check would also reject GitHub URLs and host/owner/name, which lookup accepts on main today (pasting a URL is the workaround here). It would also lock in rejecting bare names rather than restoring them, so it probably needs rework, not a straight merge.
   • fix(client): reject incomplete GitHub owner paths before lookup #15969 (open): only blocks owner/ on the client and explicitly lets bare names through, so it doesn't conflict.
   • [Bug]: New-project repository lookup fails for self-hosted GitLab when given a full URL — entire URL is sent as the project path to glab api projects/<encoded-url> #7849: a separate GitLab URL lookup bug.

   I didn't find a duplicate or an existing fix PR. A likely fix: (1) when the selector is a single segment, resolve the owner with readViewerLogin(fallbackHost); (2) let a vetted set of GitHub lookup details through mapRepositoryError. Until then, the workaround of entering owner/name or pasting the URL should still work.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 8, 2026
3. Ghost-9 commented on Oct 9, 2026

   

   Ghost-9

   on Oct 9, 2026

   More actions

   Second independent confirmation on a different platform, plus two points that may affect the fix.

   Environment: macOS T3 Code (Nightly) desktop with its bundled server, 0.0.46-nightly.20261009.2861 — a later nightly than the report, same behaviour. gh is authenticated with repo scope, GET repos/{owner}/{name} works from the same machine, and GitHubSourceControlProvider.discovery is Success. So nothing environmental is involved: the field input never becomes a request.

   Repro: Add project → GitHub → type a bare repository name into the field whose placeholder is owner/repo → Enter. Five attempts over ~10 hours, identical every time:

   SourceControlRepositoryError: Source control repository operation lookupRepository failed for github: The source control operation could not be completed.
     [cause]: SourceControlProviderError: Source control provider github failed in getRepositoryCloneUrls: Repositories are named owner/name.
   

   Ten occurrences of that innermost line in ~/.t3/userdata/logs/server.trace.ndjson*, and the toast above is the only thing a user ever sees.

   Two points for the fix:

   1. In this path the discarded detail is a fixed literal with no user data ("Repositories are named owner/name."), unlike the request/response errors that forward error.message. So an allowlist or a "safe for users" marker, as you suggested, cleanly covers the format/not-found/auth/rate-limit strings that are already written for users.
   2. On the framing: the reason a bare name gets typed at all is that the field is the only way in — there is no repository list or search anywhere in the Add-project clone flow in the current build. Restoring the pre-feat(server): source control, media and discovery use GitHub's API instead of gh #16321 bare-name resolution therefore removes most of the real-world pain cheaply. The listing idea is tracked separately at Suggest GitHub repositories after typing an owner #15973 (Ideas, open, awaiting maintainer direction); prior attempts were fix(github): search repositories by name #8340, fix(source-control): suggest GitHub repositories by owner #10214 and feat(source-control): search GitHub repositories when cloning #13228 (all closed unmerged) and the original request [Feature]: Let users search their GitHub repositories when cloning a new project #8654 (closed not_planned).

   For anyone landing here: owner/name resolves correctly, and a full URL works only through the Git URL entry, which skips lookupRepository entirely.