fix(server): repository identity prefers the gh default remote

[donnes]

What Changed

RepositoryIdentityResolver now checks for a remote marked by gh repo set-default and prefers it. gh stores remote.<name>.gh-resolved as base for that remote's own repo, or as OWNER/REPO when the chosen parent repo has no remote. The second case resolves to that repo on the marked remote's host, the same way gh does. Only after that does it fall back to the existing order: upstream, then origin, then the first remote alphabetically. Resolving an identity reads that config with one git config --get-regexp call, which runs in parallel with git remote -v. It only runs on a cache miss.

Why

In a fork with both origin (the fork) and upstream remotes, the project's repository identity always resolved to upstream. That identity also drives PR detection, lookup and linking, so a fork's PRs were looked up against the upstream repo and "View PR" opened the wrong one. gh users already record which repo PRs belong to with gh repo set-default, so honoring it fixes forks without adding a setting. Repos where no default is set behave exactly as before.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (none)
• I included a video for animation/interaction changes (none)

Model: Claude Opus 5.5 (1M context), running in Claude Code inside T3 Code.

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features
  • Repository identity detection now prioritizes the Git remote marked as the resolved default, helping identify the intended repository when multiple remotes are configured.
  • When a marked remote cannot provide a valid identity, detection continues to use the existing remote-selection behavior.

Fixes #15023

[macroscopeapp]

Approvability

Verdict: Approved at c36f108

Macroscope's review found this PR approvable — This is a localized server bug fix that honors an explicitly configured GitHub CLI remote while preserving the existing fallback behavior. The new subprocess lookup and remote-selection behavior are covered by focused tests, with no schema, deployment, security, billing, or static-analysis changes.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository: pingdotgg/t3code/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 222f95c3-82aa-4163-9e0a-09c227472fa3

📥 Commits

Reviewing files that changed from the base of the PR and between d2c9281 and 737db75.

📒 Files selected for processing (2)

• apps/server/src/project/RepositoryIdentityResolver.test.ts
• apps/server/src/project/RepositoryIdentityResolver.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

📝 Walkthrough

Walkthrough

Repository identity resolution now reads GitHub CLI’s gh-resolved remote configuration alongside remote URLs. It uses a configured remote to select the canonical identity when possible, then falls back to the existing remote selection order.

Changes

Remote preference resolution

Layer / File(s)	Summary
Read and apply remote preference apps/server/src/project/RepositoryIdentityResolver.ts, apps/server/src/project/RepositoryIdentityResolver.test.ts	The resolver parses gh-resolved settings and applies a matching remote preference. For base, it uses the configured URL; for an OWNER/REPO resolution, it substitutes that path in the URL. Tests cover preference selection, URL retention, refresh, and retry after a negative-cache interval.

Priority: ⬇️ Low

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix

Sequence Diagram(s)

sequenceDiagram
  participant RepositoryIdentityResolver
  participant Git
  participant pickPrimaryRemote
  par Query remote URLs
    RepositoryIdentityResolver->>Git: Run git remote -v
  and Query resolved remote preference
    RepositoryIdentityResolver->>Git: Read remote.*.gh-resolved
  end
  Git-->>RepositoryIdentityResolver: Return query results
  RepositoryIdentityResolver->>pickPrimaryRemote: Pass remotes and parsed preference
  pickPrimaryRemote-->>RepositoryIdentityResolver: Return selected primary remote

Loading

Suggested reviewers: t3dotgg, juliusmarminge

Merge Risk: ⚪ Minimal · up to 737db

No concrete issue has been established that would prevent merging after normal checks.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 737db

The new selection is limited to a configured Git remote and its host. Invalid preferences retain the existing fallback, and no new credential or provider access path was identified. The trust model for local Git configuration and the authorization behavior of downstream providers remain unverified.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The changed selection can redirect a project’s PR lookups and fallback linking to another repository on the configured remote’s host. No change to credentials, provider registration, or deployment authority was identified in the changed resolver.

Trust Boundaries and Controls

• observed — Git configuration supplies the preference, but the selected remote must exist and an alternate repository path must pass format validation. The inspected source does not establish who can write that configuration or which selected repositories provider credentials authorize.

Resilience and Maintainability Implications

• observed — Explicit refresh permits recovery from a changed preference, but ordinary cached resolution need not immediately reflect an external Git configuration change. This caching behavior predates the PR.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 4 functions across 2 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly and concisely describes the main change: preferring the GitHub CLI default remote when resolving repository identity.
Description check	✅ Passed	The description explains the problem and the change, and it references issue #15023. It does not report focused verification results or explain the scope approval or why this fix qualifies without pri…

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

---

_{Comment @coderabbitai help to get the list of available commands.}