[Feature]: Fully custom branch name when starting a new worktree thread

[MrSimmmons]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

New worktree threads get an auto-generated branch, t3code/<hex>, and a directory derived from it, t3code-<hex>. Neither tells me anything.

There is an LLM step that renames the branch after the first message, but it is best-effort and depends on a working text-generation CLI. When that CLI is missing or unhealthy it fails silently and every worktree keeps its hex name. #5359 reports 20 worktrees all named t3code-<hex>.
A scenario I ran into is I only have Claude, but the branch name LLM was configured to use Codex so would never work.

Outside T3 it can get a bit confusing as well. In an external Git client, a window switcher, or a list of open editor windows, every worktree looks identical and I can't tell which thread a given worktree belongs to without opening it.

Often the case, I already know what the branch should be called before I send the first message (picking up a ticket in Jira or Linear for example), and some workplaces put restrictions on branch names which makes using T3 Code a little cumbersome

Proposed solution

An optional text field next to the worktree controls in the composer, to name the branch before the thread is created.

• Leave it empty → today's behaviour
• Type a name → it is used verbatim as the branch, and the worktree directory derives from it as it already does. Typing feat/login-fix gives branch feat/login-fix and directory feat-login-fix.
• Sanitize as you type, rather than rejecting on submit: strip quotes, replace characters Git refuses in a ref, collapse repeated separators, block leading dots per path segment, cap the length.
• Preserve case and dots. A hand-typed name should be used as typed — Feature.V2 should survive.
  • Im aware that these are stripped currently, but my thinking here is if you care about the full name of the branch, you may also care about weather capital letters should be in there or not
• A typed name is used and wont trigger be overwritten by the LLM rename

Why this matters

It makes worktrees identifiable everywhere outside T3, which is where the confusion actually happens.

It gives a deterministic path to a readable branch that needs no text-generation provider at all — useful for anyone hitting #5359, and for anyone who would simply rather not spend an LLM call on naming.

It also side-steps #5734: when a name is typed, the branch-naming helper session is never spawned for that thread. That is not a fix for the underlying bug, but it is a usable workaround today.

Right now the workaround is to open the terminal drawer and git checkout -b by hand, which several people in #272 describe doing.

Smallest useful scope

One optional text input on the new-worktree composer, applied at creation time

• No persistence, no per-project default, no template
• No renaming after creation
• No change to the generated name when the field is left empty

Alternatives considered

• Opening the terminal drawer and running git checkout -b manually. Works, but it is a detour for something the composer could ask once.
• Configurable branch prefixes (PRs feat: make worktree branch prefix configurable #3954 and feat(git): allow custom worktree branch prefixes #6037). Orthogonal, not a substitute: those set an automatic default, this names one specific branch
• PR Add customizable worktree branch naming #1110 implemented a "Custom Branch Name" override and was closed for drift, not on merit, with an explicit invitation to resubmit against current main.

Risks or tradeoffs

• Sanitization has to match what Git actually refuses in a ref, and be forgiving enough to type into — collapsing separators live rather than erroring on every keystroke.
• Name collisions with an existing branch need handling at the input, not as a failure after the thread is created.
• This does not satisfy Use repository-derived worktree branch names instead of the hardcoded t3code prefix #272 and the prefix cluster. Those want a persistent automatic rule for org branch policies; retyping a required prefix on every thread is not an answer to that. It should be framed as complementary, not as closing them.

Examples or references

Related issues: #3044 (this request, including the "before creating it" timing), #5359 (silent rename failure leaves every worktree hex-named), #5734 (the branch-name helper session going off task), #967 (comments asking for legible worktree directory names).

Adjacent: #272, #5275 and #5965 want configurable naming defaults — related but a different shape.

Near-freebie: #6163 asks for whitespace to be replaced with dashes when creating a branch. The same sanitizer would close it if it were also wired to the branch selector's create-branch flow.

Prior art: PR #1110 (closed, "Custom Branch Name" override), PRs #3954 and #6037 (open, prefix settings).

This is what ive been running in a fork (placeholder vs valid input)

Im not sold on this UI, but it works well for my use cases

Contribution

• I would be open to helping implement this.

[jmarbutt]

I think this UI is ok, but I think basic configuration on the prefix is important for many teams it is required to be a specific pattern.

[ethaneng]

ditto at least wanting this as a feature. Honestly not too fussed on implementation but my team isn't too much of a fan of seeing t3code prefixed branches when I push the branch with default name to remote. Would be nice having prefix control and per worktree naming control too

[MrSimmmons]

The way that my PR is set up, it overrides the prefix. So this becomes a fully custom branch name.
If you want to add a prefix, you just add it in the input there (or if you don't want one, you don't)