Pick a nested git repo when the project root isn't a git repo

[scriptease]

Problem

If a project's root directory is not a git repository, the git actions control shows only one option: Initialize Git. That runs git init at the project root.

That's wrong for two common layouts:

1. Monorepo without git at the root. Several packages or services live side by side, and each one is its own git repo.
2. A folder of repos. For example ~/github/ containing repo-a/, repo-b/, repo-c/, each with its own .git. You add the parent folder as the project so the agent can read and change several repos in one thread.

In both cases, initializing git at the root is not what you want. It would create a repo that contains other repos. Once you skip it, you lose the diff view, commit, push/PR actions, and checkpoints, even though the files the agent is editing are already inside a real git repo.

Proposal

When the project root is not a git repo, offer a Select repository option next to Initialize Git:

• Scan the project root for nested git repos: directories that contain .git (a directory, or a file for worktrees/submodules). Limit the depth, for example 2 or 3 levels, and skip node_modules and the like.
• Show them as a list of relative paths (repo-a, packages/api, ...).
• Picking one makes it the active git working directory for the thread. Diff, commit, push, PR, and branch actions all run against that repo.
• Show the active repo in the git control and let the user switch it or clear it. It is per thread, so two threads in the same parent folder can each target a different repo.

Heuristic default (optional)

People often open the first message with the folder they want to work in ("in repo-b, fix ..."), and agents tend to stay in one repo per turn. Two signals could preselect a repo:

• A path in the first user message that resolves to (or sits inside) one of the nested repos.
• The files the agent actually changes in the first turn, if they all belong to one nested repo.

This should suggest a repo, not silently switch to it. The user confirms, or it shows as the default that they can change.

Open questions

• Checkpoints: checkpoints are hidden git refs. Should they go into the selected nested repo, or stay disabled for non-repo roots? Using the selected repo seems natural, but edits outside it wouldn't be captured.
• Multiple repos changed in one turn: one active repo per thread keeps the model simple. Showing diffs across every touched repo would be nicer, but it's a much bigger change.
• Where the selection lives: per thread (my preference) or per project.
• Surfaces: web/desktop git control, plus mobile, which has the same git actions.

Why

Pointing the agent at a parent folder is the easiest way to work across related repos (a shared lib plus its consumer, frontend plus backend in separate repos). Today that setup costs you every git feature in T3 Code, or you have to create a pointless root repo.

[scriptease]

I looked at what implementing this would take across the codebase. Before writing any code I'd like a maintainer to sign off on the direction and scope below.

Design

• One new optional per-thread field, gitRepositoryPath. It is relative to the project root, and null means the root. It goes on the thread, the thread shell, thread.create and bootstrap.createThread, and travels on the existing thread.meta-updated event so older clients still decode it.
• Two new RPCs:
  • vcs.listRepositories scans for nested repos. Depth is limited to 3, symlinks aren't followed, node_modules and build dirs are skipped, it stops descending at the first .git, and results are capped and marked truncated.
  • vcs.setThreadRepository checks the path stays inside the project and matches --show-toplevel, then sets the repo and thread.branch in one update.
• Git RPCs stay keyed by cwd. Clients compute it with one shared helper, worktreePath ?? join(workspaceRoot, gitRepositoryPath), and the server checks it stays inside the project. Keying the ~15 git RPCs by thread instead would break status-stream dedupe and the refs cache.
• The provider cwd stays at the project root for every adapter, so the agent can still edit all repos. Codex's sandbox and Antigravity's file access are limited to the cwd, and Claude Code and OpenCode key their sessions by cwd.
• A server capability flag gates the UI, so new clients connected to old servers don't show it.

Checkpoints

Checkpoints are captured in the selected repo. Two changes to CheckpointReactor make that possible:

• It currently skips capture without any message when the root isn't a repo.
• It prefers the session cwd, which stays at the non-git root, so the selected repo has to win.

Each checkpoint records its repositoryPath, and the server prefixes turn-diff paths so older turns stay correct after a switch. Switching is rejected while a turn is running. Edits outside the selected repo aren't captured in v1.

Answers to the open questions in my post

• The selection is per thread and can be set when the thread is created. The first checkpoint baseline needs it.
• One repo per thread. A later note like "N files edited outside repo-a" can be built from the changed-files data clients already have.
• The suggestion heuristic is deferred.
• Surfaces: server, web, React Native and SwiftUI. Desktop needs no changes, since the picker and path handling live on the server and in the web app.

Out of scope for v1

• Worktrees for a nested repo. Threads stay in local mode while a repo is selected.
• Syncing PRs linked from a nested repo. PullRequestService routes by project.repositoryIdentity, which is null for a non-git root. Creating a PR works; sync and auto-settle would be a follow-up.
• The heuristic.

Size and split

Roughly 2.8–3.5k lines of production code plus tests, split into one PR per concern:

1. Server + contracts: field, migration, scan, RPCs, capability flag, MCP tools
2. Server: checkpoints and turn diffs in the nested repo
3. Web + client-runtime
4. React Native
5. SwiftUI

Questions for maintainers

1. Is this direction OK: a per-thread field, the cwd resolved by clients, and the provider cwd left at the root?
2. Should "Initialize Git" stay a primary button next to "Select repository", or move into a menu?
3. Is a v1 without worktrees and without nested-repo PR sync acceptable?

Related: #9816 used a static list in t3.json and covered status and diffs only. This proposal also covers commit, push, PR and checkpoints, and needs no configuration.

Impact analysis prepared with Claude Code (Opus 5.5).

[scriptease]

Here is what i have in my swift ui branch:

Repository selection if no git root

Normal open or repo

Workspace / Repo shown in the threads list

Repository search 3 levels deep, limited to 100, npm etc excluded

Repository folder change next to branch selection

Additional section to go to the repository in the file browser