Continuing a worktree thread after tracked PR should fetch the PR base on a new branch.

[mckamyk]

Continue a thread on a fresh branch after its PR merges

I ran into this while continuing work in the same T3 thread after merging its PR. I'd like maintainer feedback on the intended workflow and approval of the direction and scope before opening a PR.

Problem

1. Start a thread in a new worktree and implement a change.
2. Commit, push, open a PR, and squash-merge it.
3. Send another message in the same thread to make a follow-up change.
4. Commit and open another PR through T3's Git actions.

The checkout still uses the original feature branch. Its old commits remain in that history, so the second PR can include already-landed commits or encounter conflicts with the squash on main. A resumed thread can have the same problem days later.

Keeping the conversation is useful because it contains the reasoning behind the previous change. Starting a new thread and worktree from current main is a workaround, but loses that immediate continuity.

Why the timing matters

Changing branches when the user presses Commit is too late: the agent has already written code against the old checkout, and integrating it with newer main may require conflict resolution and testing.

A fresh branch from stale local main is also insufficient. That base may not contain the previous PR, while the follow-up changes depend on it. Fetching updates the remote refs, but does not itself move the feature branch onto the new base.

The proposed boundary is the first new coding turn after the current branch's PR has merged, before the agent starts editing.

Proposed behavior

• For a clean, exclusively owned T3-managed worktree still at the merged PR's recorded head, fetch the remote default branch and create a fresh branch at that fetched commit in the same folder. Preserve the old branch and the thread's conversation and PR history.
• Update the thread's branch binding and tell the agent that its checkout changed. Show a neutral timeline divider naming the merged PR, new branch, and base, similar to the existing context-handoff divider.
• If follow-up edits or commits already exist, preserve them. Make inspecting and reconciling that work onto the current base the agent's first task, before it implements the new request. Do not automatically rebase, discard files, or guess which commits landed from patch IDs.
• If preparation fails or the worktree is shared or busy, explain the problem before ordinary implementation begins. Never silently fall back to stale main.
• If Commit/Create PR is pressed before preparation, offer Prepare continuation. Preparation does not automatically commit pending changes, push, or open a PR. Keep an explicit option to intentionally reuse the merged branch for the requested action.

The first version would cover same-repository PRs merged into the remote default branch. Forks, stacks, and other target branches would require explicit handling. It would not update arbitrary old feature branches, change auto-settlement, delete branches, or change how an open PR continues.

The clean transition would happen automatically when the user sends the next message, with visible preparation status and a persisted timeline entry. Whether that automatic step is appropriate is the main product decision I'm asking about.

Related work and current verification

• Discussion #15554 proposes deleting local branches during merged-worktree cleanup and mentions resuming from the default branch. This proposal concerns continuation while the checkout still exists and would preserve the old branch.
• Issue #17312 covers choosing the wrong remote for a new worktree in a fork workflow. Remote selection needs care here too; the initial proposal would exclude that case rather than assume every origin is the PR's target repository.

I have a local prototype covering the clean transition, preserved-work preparation context, Git-action guards, and client recovery actions. Focused tests use real local Git repositories for squash, rebase, and merge histories, along with preservation and interruption cases. UI screenshots use seeded or simulated states. A live GitHub merge followed by a complete client continuation has not been verified, and native mobile UI has not been exercised.

Would maintainers support preparing a fresh branch at the first post-merge coding turn within this scope? If a merged PR is intended to finish the thread, would a clearer prompt to start a new thread be preferable?

Drafted with GPT-6.1 Sol through the Codex harness in T3 Code.