Repository navigation
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/desktop
Steps to reproduce
- In a repository with a GitHub
origin, create a branch frommainand do not push it (for example a stack parent you have not pushed yet, or a leftover local branch). It exists only asrefs/heads/<parent>. - Create a T3 worktree/thread with that branch as its base (
baseRef: "<parent>", either through a new-worktree thread ort3_worktree_handoff). T3 recordsbranch.<child>.gh-merge-base = <parent>. - Commit and push the child branch (
git push -u origin <child>). The push succeeds. - Click Create PR in the thread's source-control panel.
Expected behavior
T3 should not send a base branch that the remote does not have. It should validate the base against refs/remotes/origin/<base> (or the GitHub API), and either fall back to the repository's default branch or show an actionable error naming the missing remote base.
Actual behavior
Create PR fails with:
Source control provider github failed in createChangeRequest: GitHub returned an error: Validation Failed; base invalid
The push itself succeeds; only PR creation fails. git config --get branch.<child>.gh-merge-base returns the local-only parent, while the remote has no such branch (gh api repos/<owner>/<repo>/branches/<parent> returns 404). Choosing main manually in the Create PR menu works.
Impact
Minor bug or occasional failure — it blocks PR creation until the base is corrected manually, but it is easy to hit whenever a worktree is created from a local-only or stale branch.
Version or commit
T3 Code (Beta) 0.1.1 (CFBundleShortVersionString 0.1.1)
Environment
macOS 27.2, GitHub cloud provider, SSH remote (git@github.com:...), desktop app.
Logs or stack traces
Not a crash. The full UI error is the createChangeRequest message above.
Relevant behaviour in the bundled 0.1.1 app:
- The worktree's
baseRefends up inbranch.<child>.gh-merge-base;GitVcsDriver.pushCurrentBranch.recordMergeBasealso writes that key when it is empty. - PR base resolution reads
branch.<child>.gh-merge-baseand accepts it after a localbranchExists(cwd, <base>)check, returningrefs/heads/<base>. createChangeRequestforwards that value asbaseBranch/baseRefNameto the GitHub provider.
A base that exists only in the local clone therefore passes T3's check and is rejected by GitHub, so the user sees an opaque provider error instead of a base-selection problem.
Workaround
Point the merge base at a branch that exists on the remote:
git config branch.<child>.gh-merge-base main
or push the intended parent first (git push -u origin <parent>) and retry Create PR.
Activity
juliusmarminge commentedon Nov 12, 2026
I tried to reproduce this on the current build and could not.
On origin/main bfec275, added two cases to apps/server/src/git/GitManager.test.ts (each uses real git): an origin with only main, a local-only branch stack-parent, and a child branch feature/child pushed to origin. Case 1 creates the child the way a new-worktree thread does (GitVcsDriver.createWorktree with baseRefName 'stack-parent'); case 2 sets branch.feature/child.gh-merge-base=stack-parent. Running the create_pr stacked action sends createChangeRequest with baseRefName 'stack-parent' in both cases (
vp test run src/git/GitManager.test.ts -t "does not open a PR against a base branch": 2 failed, 'expected [ 'stack-parent' ] to not include 'stack-parent''). Not run in the desktop or web app: the GitHub provider calls GitHub's REST API directly, so a real Create PR needs a scratch GitHub repository and a create-PR request, a forge write this step may not make.Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.