[Bug]: Reused long-lived branch remains associated with a historical merged PR #4970

Activity

1. iamtoled commented on Aug 6, 2026

   

   iamtoled

   on Aug 6, 2026

   More actions

   Third facet of the same root cause, just filed as #5514: opening a new release PR from the shared dev branch retroactively adopts every historical thread on that branch — all my settled threads woke up simultaneously stamped with the new PR number. Branch-name-keyed association really needs to become a per-thread binding (e.g. PR created from within the thread, or explicitly attached).
2. JasperG134 commented on Aug 9, 2026

   

   JasperG134

   on Aug 9, 2026

   More actions

   Confirmed on T3 Code Nightly 0.0.33-nightly.20260809.1043 with inactivity auto-settlement explicitly disabled. A newly created thread on a reused branch was classified as settled because a pull request for that branch had already merged several days earlier. The local branch HEAD still exactly matched the historical pull request head, so checking only whether the branch advanced after the pull request is not sufficient. A terminal pull request should only influence settlement when its merged/closed timestamp is at or after the thread creation time; otherwise it is historical context and should not settle the new thread. This reproduces the configuration-independent failure described here.
3. HemalR commented on Aug 11, 2026

   

   HemalR

   on Aug 11, 2026

   More actions

   This is driving me nuts - I made the cardinal sin of pressing the wrong button yesterday (Create PR when I thought I was clicking on the Commit button) and now my dev branch is unusable because every agent reply auto-settles it.

   

   It would be super helpful if there was support for a long lived branch
4. Mnigos commented on Aug 12, 2026

   

   Mnigos

   on Aug 12, 2026

   Contributor

   More actions

   Confirmed with a local thread that reproduces this exactly.

   Setup:

   • Inactivity auto-settle was disabled (sidebarAutoSettleAfterDays: null).
   • A PR from the branch had merged.
   • Nearly 11 hours later, I created a new T3 thread on that same branch.
   • The local HEAD still matched the historical PR head.

   Observed:

   • The new thread was treated as belonging to the already-merged PR.
   • I manually un-settled it 9 times.
   • Starting another turn cleared the temporary “active” override.
   • When the agent finished, the thread moved back to Settled.
   • The event store contains 9 user un-settle events and 9 corresponding activity resets, but no explicit settle events. Settlement was derived client-side from the historical merged PR.

   Expected:

   A PR merged before the thread was created should be treated as historical context and should not settle that thread.
5. AntoineArt commented on Aug 18, 2026

   

   AntoineArt

   on Aug 18, 2026

   More actions

   Root cause is reproducible by reading, not just by symptom — it sits in findLatestPrForHeadContext and its single caller guard in apps/server/src/git/GitManager.ts (main @ cebac35).

   Three ingredients combine:

   1. The query deliberately includes terminal change requests — listChangeRequests({ headSelector, state: "all", limit: 20 }) (L1308-1313). Merged and closed MRs/PRs are in the candidate set by design.

   2. The fallback returns a terminal change request when no open one exists (L1324-1330):

      const latestOpenPr = parsed.find((pr) => pr.state === "open");
      if (latestOpenPr) return latestOpenPr;
      return parsed[0] ?? null;   // <- most recently *updated*, any state

      parsed is sorted by updatedAt desc, so with zero open candidates this hands back the historical merged one.

   3. The only filter is scoped to the default branch (L1025-1031):

      // On the default branch, only surface open PRs.
      // Merged/closed matches are usually reverse-merge history, not the thread's PR context.
      if (details.isDefaultBranch && latest.state !== "open") return { pr: null, headContext };

   So the suppression that this comment describes as the general rule is applied only when isDefaultBranch is true. On any non-default branch the merged change request flows straight through to the thread.

   That explains why this reads as intermittent across setups: on a repo where work happens on short-lived branches off main, the guard covers the common case and the bug looks rare. On a GitFlow-style repo — long-lived dev with main as the default branch — dev is never isDefaultBranch, so every thread on dev inherits the last merged change request from dev indefinitely. Same for any feature branch recycled after its MR merged.

   This hits GitLab remotes identically: GitLabCli.listMergeRequests maps state: "all" onto glab mr list --all, and normalizeGitLabMergeRequestState faithfully returns "merged" — the state is decoded correctly, it is just never used as a rejection criterion off the default branch.

   Worth noting for the per-thread-binding proposal above: projection_threads has no change-request column at all (thread_id, project_id, title, branch, worktree_path, …). The association is derived at read time from branch, and the lookup cache is explicitly keyed on (cwd, branch) (L1020-1023). Nothing is persisted binding a thread to the MR/PR it actually opened, which is why every consumer has to re-guess from the branch name, and why #5514 is this same defect seen from the other side.

   Two fixes, independent, both cheap:

   • Short term — make the terminal fallback time-aware rather than branch-aware, which is what @JasperG134 asked for above: a merged/closed change request should only bind when its merged_at/closed_at is at or after thread creation. Older than that, it is historical context. No schema change, and it fixes the recycled-branch case on every provider.
   • Structural — persist the change-request number on the thread when it is opened from within that thread, and prefer the stored binding over branch resolution. That is the only thing that makes the release-PR case in [Bug]: Opening a release PR (dev → main) retroactively adopts every thread on the shared branch — all settled threads wake up stamped with the new PR number #5514 correct, since there the branch genuinely does have a new open MR — it just does not belong to those threads.

   Happy to send a PR for the first one if a maintainer confirms the time-guard framing is the direction you want.
6. AntoineArt commented on Aug 18, 2026

   

   AntoineArt

   on Aug 18, 2026

   More actions

   Follow-up: there is a second, independent root cause, and it is the one that actually fires in practice. The isDefaultBranch value that the whole suppression hinges on is resolved from a stale local snapshot, never from the forge.

   resolveDefaultBranchName (apps/server/src/vcs/GitVcsDriverCore.ts L1260-1267 on main) does exactly one thing:

   ["symbolic-ref", `refs/remotes/${remoteName}/HEAD`]

   with the fallback at L1717:

   (defaultBranch === null && (refName === "main" || refName === "master"))

   refs/remotes/origin/HEAD is a clone-time snapshot. Git never refreshes it — not on fetch, not on pull. It only moves if someone explicitly runs git remote set-head origin -a. So when a project changes its default branch on the forge after you cloned, this value stays silently wrong forever, and nothing in the codebase ever asks GitLab/GitHub what the default branch actually is.

   Live reproduction I just captured (details anonymised, private repo):

   • GitLab project, forge default branch is dev (confirmed via glab repo view).
   • Local refs/remotes/origin/HEAD still points at origin/main — set at clone time, before the default moved.
   • ⇒ defaultBranch resolves to "main", so a thread checked out on dev gets isDefaultBranch = false.
   • ⇒ the L1028 guard never fires.
   • ⇒ findLatestPrForHeadContext falls through to parsed[0] — the most recently updated MR sourced from dev, which is a closed MR last updated 2026-07-07.
   • ⇒ a thread created 2026-08-11 is bound to that terminal MR and re-settles after every completed turn.

   The event store shows the signature clearly: for that thread, 6 thread.unsettled events against 1 thread.settled. The un-settles do not stick, and — worth noting for anyone trying to debug this from the event log — the re-settle emits no event at all, because the settled state is re-derived from the branch→MR resolution on read rather than stored. That asymmetry (unsettled ≫ settled on a single thread) is a reliable fingerprint for this bug.

   Two consequences beyond the reported case:

   1. Any repo whose default is dev / develop / trunk and where origin/HEAD was never set-head is permanently exposed, because the null fallback guesses main/master. That is very likely why the reports here cluster on GitFlow-style setups.
   2. Conversely a repo whose default is main gets correct behaviour by accident, which is why this looks unreproducible to anyone testing on a standard GitHub layout.

   Suggested fix, orthogonal to the time-based guard from my previous comment and cheaper: resolve the default branch from the forge first — gh repo view --json defaultBranchRef / glab repo view — and fall back to the local symbolic-ref only when that fails, rather than the other way around. Both CLIs are already hard dependencies of the source-control layer, and the result is cacheable per repo. That alone makes the existing L1028 guard do what its comment claims it does.
7. mohamedaminetebini commented on Sep 22, 2026

   

   mohamedaminetebini

   on Sep 22, 2026

   More actions

   I can reproduce a related variant on the Linux desktop app with a local/shared checkout.

   1. Open a T3 Code conversation on a branch whose PR has already merged.
   2. Create a new conversation using that branch.
   3. Ask the agent to create and switch to a new branch.
   4. The new conversation still shows the violet merged-PR indicator from the old branch.

   Expected: once the conversation is associated with the newly created branch, the historical merged PR indicator should disappear.

   Actual: the old merged PR stays attached to the new conversation/branch.

   This appears to be stale terminal PR state retained across a shared-checkout branch change, rather than a rendering-only issue.

   Environment: Linux desktop app, local/shared checkout, GitHub repository, [provider/version if known].
8. Fastdesigner commented on Oct 2, 2026

   

   Fastdesigner

   on Oct 2, 2026

   More actions

   Additional current reproduction on iPad in a Safari Home Screen web app, accessing T3 over Tailscale:

   • Repository: Fastdesigner/fiCMS, long-lived integration branch worker.
   • PR https://github.com/Fastdesigner/fiCMS/pull/9 was closed without merging on 2026-09-09. Its head branch is worker, base main.
   • New, unrelated threads on worker still display the red New application architecture #9 badge. One affected thread concerns generating/distributing a Font Awesome subset, rather than the old PR's UI-kit changes.
   • Opening New application architecture #9 from that thread's badge and opening the PR More menu shows “Link to this thread”, not “Unlink from thread”. The badge also remains visible beneath the composer.

   This means the manual unlink workaround described in #7517 / #11087 is not available for this observed association. The screenshots supplied by the reporter show the badge and that menu together. Installed T3 version has not yet been captured.

   A source check of current main shows usePullRequestLinking.isLinked() inspecting explicit pullRequests entries (or legacy linkedPullRequest), rather than the automatically detected branchPullRequest. That appears consistent with this menu/badge mismatch, but the installed build's actual matching path has not been traced.

   Please cover closed-without-merge PRs as well as merged PRs in the fix. A user should be able to dismiss an automatically detected historical branch PR durably, without explicitly linking unrelated work first, deleting the thread, or abandoning the integration branch. A badge that is already displayed should not leave the user with only “Link” and no route to remove the association.
9. shivamhwp commented on Oct 5, 2026

   

   shivamhwp

   on Oct 5, 2026

   Collaborator

   More actions

   Still happens on current main (1e2ecbd, orchestration V2). I reproduced it in the web app with a clone of this repo on fix/cursor-usage-cache-savings. That branch still exists here at the head of merged #13731. While the branch sits on that commit, the thread shows #13731, which is correct. After one more commit on the branch, the thread and the git panel still show #13731.

   Recordings and a fix are in #16006. A merged or closed PR stops being the branch's PR once the branch tip moves past the PR's head commit. GitHub's headRefOid comes from the gh pr list call T3 already makes.
10. MRNAQA commented on Oct 5, 2026

    

    MRNAQA

    on Oct 5, 2026

    More actions

    Another case of this one, on desktop 0.0.45 (macOS, local checkout, Claude provider). This time the PR was closed without a merge.

    Setup: long-lived integration branch development. The default branch is main. Before this, no PR had ever used development as its head branch.

    Timeline (UTC, 2026-10-05, from orchestration_events):

    Time	Event
    04:58	A teammate opened a PR development → main by mistake
    05:02	thread.meta-updated set branchPullRequest to that PR on 9 threads on development
    07:42	The PR was closed. It was not merged.
    07:46	App restart. The startup backfill set it on 43 more threads.
    11:00–12:33	Every new thread on development gets it when it is created

    Result: all 62 active local-checkout threads on development show the closed PR. That includes threads created hours after it closed and unrelated to it. One thread linked the PR explicitly through the agent. That link is correct.

    The branch tip has moved since then: PR headRefOid is 310f0bf… and development is now 24f2010…. So the head-OID check in #16006 should drop it. Two notes:

    1. The adoption started while the PR was still open. That is the [Bug]: Opening a release PR (dev → main) retroactively adopts every thread on the shared branch — all settled threads wake up stamped with the new PR number #5514 facet. fix(git): a long-lived branch stops showing an old merged PR once it moves on #16006 covers only terminal PRs, so an open PR from a shared branch still stamps every thread on it. 0.0.45 may predate the orchestrator change that closed [Bug]: Opening a release PR (dev → main) retroactively adopts every thread on the shared branch — all settled threads wake up stamped with the new PR number #5514. If so, please ignore this point.
    2. In ThreadPullRequestService, a lookup that returns no PR keeps a stored closed or merged branchPullRequest for local-checkout threads. That is why the badge survives. fix(git): a long-lived branch stops showing an old merged PR once it moves on #16006 says it handles this. I mention it only so this case stays covered by a test.
11. shivamhwp

    added 3 commits that reference this issue on Oct 8, 2026

    fix(server): drop a terminal PR once its branch moves past it

    ...

    This issue will close once commit e66afeb is merged into the 'main' branch.

    e66afeb

    fix(server): drop a terminal PR once its branch moves past it

    ...

    This issue will close once commit e48a048 is merged into the 'main' branch.

    e48a048

    fix(server): drop a terminal PR once its branch moves past it

    ...

    This issue will close once commit f164e7d is merged into the 'main' branch.

    f164e7d
12. juliusmarminge commented on Oct 21, 2026

    

    juliusmarminge

    on Oct 21, 2026 – with GitCafe Production

    Member

    More actions

    This overlaps #14858: a reused branch retains a historical merged PR after its tip advances. This report predates that one. No runtime reproduction completed; triage stopped at the duplicate check.
13. juliusmarminge

    closed this as completedon Oct 21, 2026