Skip to content

[Bug]: Create PR fails with "base invalid" when the worktree base exists only locally #22920

Closed as not planned

Description

@isjiajia01

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

  1. In a repository with a GitHub origin, create a branch from main and do not push it (for example a stack parent you have not pushed yet, or a leftover local branch). It exists only as refs/heads/<parent>.
  2. Create a T3 worktree/thread with that branch as its base (baseRef: "<parent>", either through a new-worktree thread or t3_worktree_handoff). T3 records branch.<child>.gh-merge-base = <parent>.
  3. Commit and push the child branch (git push -u origin <child>). The push succeeds.
  4. 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 baseRef ends up in branch.<child>.gh-merge-base; GitVcsDriver.pushCurrentBranch.recordMergeBase also writes that key when it is empty.
  • PR base resolution reads branch.<child>.gh-merge-base and accepts it after a local branchExists(cwd, <base>) check, returning refs/heads/<base>.
  • createChangeRequest forwards that value as baseBranch / baseRefName to 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

  1. juliusmarminge commented on Nov 12, 2026

    @juliusmarminge
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions