[omartelo]

lich lists a repository's pull requests, shows Files changed, comments, resolves conflicts and merges — the right-hand side of the flow. The left-hand side did not exist: an issue was not work. You opened a worktree, named it by hand, and typed the context in at the agent's prompt.

The New worktree dialog's name field now takes an issue beside the branch names and plain words it already took.

What it does

Type #128, or paste the URL copied out of the browser. lich looks the issue up through gh on the project's own account (vcs.account), prints its title and the exact branch it will create under the field before anything exists, and hands the issue to the session that opens on it — number, title, link and body, waiting unsent at the agent's prompt.

Measured against this repository, every state of that one field:

typed	shown under the field
#381	#381 Sandbox backend for Windows (unelevated write protection) / Branch: 381-sandbox-backend-for-windows
#453 (a pull request)	#453 is a pull request, not an issue — open it from the Pulls screen. / Branch: 453
#999999	GitHub has no issue with that number. / Branch: 999999
fix the auth redirect	Branch: fix-the-auth-redirect
381	Branch: 381
(empty)	Branch: <auto-generated>

Two refusals, both because the field is a branch name first

• A bare number stays a branch name. # is the marker, so there is one field with one meaning rather than a mode to be in.
• A pull request's number is refused, naming the screen that does open pull requests. GitHub counts issues and pull requests in one sequence and gh issue view answers for either — taking it would branch off the base under its title instead of checking its head out (CreateWorktreeFromPR). The URL is the only field in the answer that tells the two apart.

And the reference itself never names the branch, resolved or not: git accepts #381 as a branch name, and most shells read the # as the start of a comment — git checkout #381 is git checkout. Caught in the headless smoke, not in review.

Almost all of it already existed

toBranchName()	reused — the slug and the help line are #413's
CreateWorktree()	reused — an issue's worktree is an ordinary branch off the chosen base
writeAtPrompt()	reused — waits for Terminal.Ready, so the paste outlives the setup script (#447)
bracketedPaste()	reused — why a multi-line body is text and not a run of Enters
project.Issue	new — one gh issue view <n> --json number,title,body,url, ~60 lines
lib/issue.ts	new — reference to number, issue to prompt text; pure, tested
ghFailures	one row

No new screen, no route, no topbar entry, no dependency. The body is cut at 4 000 runes with the cut marked; the URL above it is the rest.

Testing

• internal/project/issue_test.go — the gh call's shape, the pull request refusal, the body cut (boundary pinned as a literal and crossed by one), and the not-found wording pinned onto its message.
• frontend/src/lib/issue.test.ts — 10 cases: #N, issue URLs with tails, enterprise hosts, and every shape that is not a reference; the brief's bracketing and its empty-body branch. One asserts toBranchName(issueName(issue)) end to end, so the branch this prints is the branch it makes.
• Headless smoke against real GitHub (the node-only gate cannot render): the dialog driven over CDP through all six states above, no exceptions and no console errors. That is where the #-in-a-branch-name bug surfaced.
• Local gate green: gofmt, go vet, go test ./..., biome check, tsc, vitest (1383), vite build, and the three-OS build/vet loop.

Provider symmetry

The handoff is writeAtPrompt + bracketed paste — the same mechanism the pull request handoff already ships on, provider-agnostic. No per-provider gap, so no new docs/ceilings.md bullet; the paste bullet there now names both callers.

https://claude.ai/code/session_01GSu6sRs6pBuZHmWaJmuZ3o