[Bug]: Fork PR creation always fails — head selector is computed against `origin` instead of gh's resolved base repo#7382

openedAug 18, 2026byVvrathikshenoy

Before submitting

I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

Fork-based workflow, where gh's resolved base repo is not origin:

Clone a fork so origin = <you>/<repo> and upstream = <org>/<repo>.
Let gh resolve the base repo to upstream (gh repo set-default <org>/<repo>, or answer its prompt once). This writes remote.upstream.gh-resolved=base.
Create a branch, commit, and push it to origin so it tracks origin/<branch>. The branch exists only on the fork.
Use T3 Code's source-control action to create a PR for that branch.

Expected behavior

A cross-repository PR is created from <you>:<branch> into <org>/<repo>, matching what bare gh pr create does in the same worktree.

Actual behavior

text

1	Source control provider github failed in createChangeRequest: GitHub CLI command failed.

gh exits 1 because it is asked for a head branch that does not exist in the base repo.

Cause

resolveBranchHeadContext in apps/server/src/git/GitManager.ts decides cross-repository-ness by comparing the branch's remote against the literal remote named origin:

1	const [remoteRepository, originRepository] = yield* Effect.all([
2	resolveRemoteRepositoryContext(cwd, remoteName),
3	resolveRemoteRepositoryContext(cwd, "origin"), // <-- assumes origin is the base repo
4	], { concurrency: "unbounded" });
5
6	const isCrossRepository =
7	remoteRepository.repositoryNameWithOwner !== null && originRepository.repositoryNameWithOwner !== null
8	? remoteRepository.repositoryNameWithOwner.toLowerCase() !==
9	originRepository.repositoryNameWithOwner.toLowerCase()
10	: remoteName !== null && remoteName !== "origin" && remoteRepository.repositoryNameWithOwner !== null;
11
12	// ...
13	preferredHeadSelector: ownerHeadSelector && isCrossRepository ? ownerHeadSelector : headBranch,

In a fork clone the branch tracks origin, and origin is the fork — so remoteRepository === originRepository, isCrossRepository is false, and the owner-qualified ownerHeadSelector (<you>:<branch>) is discarded in favour of the bare headBranch.

That bare value flows to GitHubCli.createPullRequest (apps/server/src/sourceControl/GitHubCli.ts), which passes it as an explicit --head:

1	args: ["pr", "create", "--base", input.baseBranch, "--head", input.headSelector,
2	"--title", input.title, "--body-file", input.bodyFile]

An explicit --head suppresses gh's own tracking-branch inference, so gh looks for <branch> in the base repo it resolved (upstream), does not find it, and exits non-zero.

The asymmetry is the core of it: the base branch is resolved through gh — resolveBaseBranch falls through to getDefaultBranch, i.e. gh repo view --json defaultBranchRef, which honours gh-resolved and therefore reports upstream's default branch — while the head selector is computed against origin. Base comes from one repo, head is assumed to live in another.

Searching the shipped 0.0.33 server bundle for gh-resolved, set-default, or any base-repo resolution returns nothing, so this appears to be a general assumption rather than a slip: whenever gh's base repo is not origin, cross-repository PR creation sends an unqualified head.

Evidence

console

1	$ gh repo set-default --view
2	<org>/<repo>
3
4	$ git config --get-regexp gh-resolved
5	remote.upstream.gh-resolved base
6
7	$ git rev-parse --abbrev-ref @{u}
8	origin/<branch>
9
10	# the head T3 Code sends is absent from the base repo
11	$ gh api repos/<org>/<repo>/branches/<branch>
12	gh: Branch not found (HTTP 404)
13
14	# ...but it is a valid cross-fork head
15	$ gh api "repos/<org>/<repo>/compare/main...<you>:<branch>" --jq .status
16	ahead

Same command shape, with and without the explicit --head T3 Code passes:

console

1	$ gh pr create --base main --title t --body-file /dev/null --dry-run
2	head: <you>:<branch> # gh infers the owner prefix
3
4	$ gh pr create --base main --head <branch> --title t --body-file /dev/null --dry-run
5	head: <branch> # what T3 Code sends -> 404 against the base repo

Suggested fix

Compare the head remote against the provider's resolved base repository rather than the remote literally named origin — read remote.<name>.gh-resolved / gh repo view --json nameWithOwner and use that as the comparison target. ownerHeadSelector is already computed correctly; only the predicate that gates it is wrong.

Relationship to existing issues

#3801 (closed, completed) fixed this same origin assumption, but on the read path (selectProviderContext, baseRefChoices.ts, GitActionsControl.tsx). GitManager.resolveBranchHeadContext is on the write path and was not in that scope, so PR creation still assumes origin.
#3694 reports the identical user-facing string from a different cause (Windows, single-repo, dry run succeeds). Not a duplicate — but its point stands here too: because GitHubCliCommandError.detail is the constant "GitHub CLI command failed." and gh's stderr never reaches the error or the logs, this bug is invisible from the app. The underlying gh message names the missing head branch directly.

Impact

Major degradation or frequent failure

Version or commit

T3 Code v0.0.33 (Linux AppImage)

Environment

OS: Linux (Ubuntu, KDE Plasma 6, Wayland)
GitHub CLI: gh version 2.97.0
Remotes: origin = fork (HTTPS), upstream = source repo (HTTPS)
gh base repo: upstream, via remote.upstream.gh-resolved=base
Branch tracks origin/<branch>; the branch exists only on the fork

Workaround

Push the branch to whichever repo gh resolves as base, so the bare head resolves there:

1	git push -u upstream <branch>
2	git config remote.pushDefault upstream # keeps future branches out of the trap

Repointing the base repo at the fork (gh repo set-default <you>/<repo>) also makes T3 Code succeed, but then PRs target the fork instead of upstream, which is usually not what you want. There is no local configuration that makes T3 Code open a genuine fork -> upstream PR.

VvrathikshenoyAug 18, 2026

Confirmed at runtime, not just from reading the source. I put a logging shim earlier on PATH than the real gh and drove the shipped v0.0.33 Linux AppImage through the normal UI action. The shim intercepted pr create so nothing could be created; every other subcommand was passed through untouched.

Captured pr create invocation (branch and repo names genericized):

text

1	cwd=/path/to/fork-clone
2	argv: [pr] [create] [--base] [main] [--head] [<branch>] [--title] [...] [--body-file] [/tmp/t3code-pr-body-<pid>-<uuid>.md]

--head is unqualified. The branch exists only on origin (the fork); gh's resolved base repo is upstream via remote.upstream.gh-resolved=base. So gh is asked for <branch> in a repo that does not have it, and exits 1 — surfacing as the generic createChangeRequest error.

Note --base main in the same command: that value came from getDefaultBranch → gh repo view --json defaultBranchRef, which honours gh-resolved and therefore reports the upstream repo's default branch. Base is resolved through gh, head is assumed to live on origin. Both halves of the asymmetry are visible in that single argv.

The predicate flipping, observed live. Same repo, same branch, same running process — only the branch's tracking remote changed between these two background pr list probes:

text

1	argv: [pr] [list] [--head] [upstream:<branch>] ... # branch tracked upstream -> qualified
2	argv: [pr] [list] [--head] [<branch>] ... # branch tracked origin -> bare

That is isCrossRepository in resolveBranchHeadContext doing exactly what the report describes. When the branch tracks origin and origin is the fork, the comparison is fork-vs-fork, the predicate is false, and the correctly-computed ownerHeadSelector (<you>:<branch>) is discarded in favour of the bare headBranch. Nothing about whether the branch exists on any remote enters into it — the selector is decided purely from branch.<name>.remote and the remote URLs, so this reproduces from git config alone.

For contrast, gh resolves the same worktree correctly when it is allowed to infer the head itself:

console

1	$ gh pr create --base main --title t --body-file /dev/null --dry-run
2	head: <you>:<branch>
3
4	$ gh pr create --base main --head <branch> --title t --body-file /dev/null --dry-run
5	head: <branch> # what T3 Code sends

The explicit --head is what suppresses that inference.

One incidental observation from the same log, unrelated to this bug and already covered by #3581: the shim recorded ~450 gh pr list invocations in roughly ten idle minutes, at close to one per second.

Mmaria22d ago

Note

This is an automated response from a bot acting on maria's behalf. This issue has had no activity since 2026-08-18. Is it still relevant on the current version? If so, your version and OS would help.