[badcuban]

The problem

A repository often already has worktrees Threadlines did not make: git worktree add by hand, or another app that keeps one per task. They only showed in the branch picker, each with a small "worktree" label. There was no way to carry on in them as threads, and nothing stopped Threadlines from treating those folders as its own.

What this adds

• Right after adding the repository, the new-thread screen lists its worktrees under the message box with a checkbox each. Ones with nothing left to ship start unticked. "Add N threads" makes a thread per ticked worktree, named from its branch ("fix/checkout-retry" reads "Checkout retry"). Nothing runs until a message is sent.
• Later visits show a count beside the recent threads ("4 worktrees"). Opening it lists them with "Work here" (points the thread about to start at that worktree), "Add as threads…" and "Hide for this project".
• The Workspace picker under the message box lists them under "Existing worktree", on desktop and phone.
• The command palette has "Add existing worktrees as threads…", which also brings a hidden count back.
• An added thread opened before its first message says where it works.

Only worktrees outside Threadlines' own worktrees folder count, and only ones no thread works in yet.

A guest, not an owner

A thread in one of these worktrees carries ThreadWorktreeOrigin { kind: "existing" }, the marker a thread lent another thread's worktree already has. So the first turn never renames the branch, no setup script runs, deleting the thread never offers to remove the folder, the cleanup dialog never pre-ticks it, and undo only reverts the thread's own edits. A thread continuing in a guest's worktree is a guest too. The branch picker and the Source panel send the marker when they point a thread at one.

How it is built

• vcs.listWorktrees takes scope: "elsewhere" (leaves out the main checkout and Threadlines' own worktrees before any per-worktree work) and statuses: false (names only). Reading a worktree costs a git status there, about seven seconds on a repository with 34 worktrees, so the count, the menus and the palette ask for names and only a list that is shown asks for statuses.
• thread.create accepts worktreeOrigin: { kind: "existing" } from a client (never without a worktree path; kind: "thread" stays server-only). thread.checkout.select takes existingWorktree.
• The server reports a worktreePickup capability. Without it the client asks for nothing and sends no marker.
• Design note: docs/design/worktree-pickup.md. The app guide's "Threads and worktrees" topic covers it.

Known limits

• A client built between feat(threads): an agent can put a thread in a checkout another thread already has #911 and this change decodes worktreeOrigin as the one-member struct and rejects kind: "existing". No stable release has that schema; it needs a nightly from that window linked to a newer computer.
• A thread pointed at one of these worktrees before this shipped has no marker and is treated as before.

Checked

vp fmt, vp lint, vp run typecheck, the full unit suite, the full browser suite, and the startup size check (891,290 B against 915,000). Walked every screen in the real app against a scratch repository with four worktrees, in light, dark and phone layouts. Not run: a real agent turn inside a picked-up thread.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
threadlines	Ready	Preview	Nov 14, 2026 7:11pm UTC