[Feature]: Adopt an existing local Git checkout as a T3 Code project #17985

Triage

This is a valid enhancement, not a duplicate of clone, relink-after-move, or worktree handoff.

What already exists

T3 Code can already attach a T3 project record to a directory that is already on disk. It does not require git clone or git worktree add.

• Web / desktop: Command palette Add project → Local folder (also from the empty-state / sidebar “New project” / “Add project” actions). Choosing a path that is already registered focuses that project instead of creating a second one.
• Mobile: Add project → Local folder, with the same path reuse.
• Desktop CLI: npx t3 app (or npx t3 app <path>) opens the current/given directory, adding the project if needed. This is the completed form of [Feature Request] Add cli command to open folder inside desktop app #517.
• Onboarding: the welcome wizard can import Claude/Codex checkouts. Linked git worktrees are intentionally not offered there.
• Delete: removing a T3 project removes the project record (and its threads), not the files on disk.
• Dirty trees: project.create only records workspaceRoot. Uncommitted work is not a blocker.
• New threads default to local workspace mode (defaultThreadEnvMode: "local"), so they start in that checkout unless the user/project default is New worktree.

Dedup today is path-scoped (same environment + same normalized workspaceRoot), which is the right model. Two checkouts of one remote (main + a worktree) should remain two projects.

What is still missing

The report is still right that there is no git-aware adopt step:

• No resolve-to-repository-root if the user picks a nested folder.
• No confirm UI showing branch, checkout path, and whether it is a worktree.
• Palette add can create a missing directory (createWorkspaceRootIfMissing: true) instead of requiring an existing checkout.
• Linked / externally created worktrees are easy to miss (onboarding skips them; [Bug]: Externally created Git worktrees are treated as “Local” #1714 is a separate recognition bug).
• Naming is “Add project” / “Local folder”, not “Open existing checkout”, so clone is the more obvious path and people recreate repos.

This is different from #4940 (relink after a folder moved), #2357 (rename), and #3753 / #3754 (handoff into a new worktree).

Recommended direction

Keep this issue open. Extend the existing Local folder flow rather than adding a parallel product:

1. After a directory is chosen, inspect Git (root, branch, worktree vs main checkout) and confirm before create.
2. Point the project at that checkout; allow a dirty tree; do not clone, move, or add a worktree.
3. If that path is already a project, focus/reuse it.
4. Ship the same confirm on web, desktop, and mobile.
5. Optionally offer linked worktrees in onboarding import.

Workaround until then: Add project → Local folder, or on desktop npx t3 app from the checkout.