[Question] Is there a way to work with multi-repo projects?

[ORanuare]

I have a project that has multiple repositories, I work on them through vscode workspace so the agents can make changes across all repositories. Is there a way to work like this in T3Code?

I'm ready to dump Cursor horrible experience.

Ofc, I can add the parent folder containing all projects but then the git changes are not visible.

[ercnshngit]

Yes, that would be great. For example, when using warp, if I'm in the main folder, it groups and displays all the changes and also shows the folders.

[Ivorisnoob]

this is actually a good call, might try to convince them to add this

[azimari-toure-ikbal]

I was looking for someone asking for the exact same feature. I'd love to have a group / workspace feature and have all my single repo in there and have the agents get the whole workspace context if needed and having the git changes visible.

[CountableNewt]

Multiple repos in a project is something that Codex/CC Desktop/Cursor Glass haven't been able to get right and it's something that keeps me on legacy Cursor, definitely would love for this to be a feature

[ORanuare]

Honestly, I don't get why almost all agent tools (besides Legacy Cursor) only support monorepos.

I’ve been using a custom skill to help agents see sibling projects, but it’s a bit of a headache when I’m working on a feature that spans across all of them. So instead of just knocking out one fully wired and tested change, I’m stuck making separate updates and then manually stitching them back together.

Apparently, the future of coding just doesn't involve multi-repos.

[erenkulaksiz]

Hello, I have 2 different folders and different repos. I would like to work in them in the same chat (for example, frontend and backend) But at current state, I have to tell current agent to look up the project in my computer or start 2 chats where I could just open one.

[func0der]

Since the same problem existed in OpenCode before, I was so annoyed that I threw a few tokens at the problem. This is the result: https://github.com/func0der/t3code/tree/feat/multi-repo-root

Since this project does not accept any contributions for new features right now, please test is yourself, if you want this :)

Let's gather feedback here, since I do not want to open a PR and get banned for annoying the devs ;)

[LoganRupe]

Hey, figured I'd share since this thread's where the multi-repo stuff is at.

Been running a build locally for a while and it's working really well day-to-day. A project is defined by a .code-workspace file (same one VS Code uses), so repos can be arbitrary paths: cousins in different trees, no shared parent needed. T3 resolves the folders[], treats the git ones as roots, and the diff view shows changes grouped per repo while the agent edits across all of them in one thread. Single-repo projects work exactly like today.

It lives on my fork if anyone wants to poke at it: LoganRupe/t3code @ multi-repo-workspaces.

Big thanks to @func0der for the feat/multi-repo-root branch, that's where the data foundation came from.

Not pushing for a PR, just sharing in case it's useful to anyone else here, and to say thanks for the original work.

[stefanvandervelden-zipline]

The lack of multi-repo support is basically preventing me from being able to really use T3 Code at work. I'm loving it for personal projects that are contained to a single repo, especially the per-turn diffs, if multi-repo support was added I would switch to T3 Code at work immediately! For now I'm stuck in the Claude Code TUI 😅

[LoganRupe]

The lack of multi-repo support is basically preventing me from being able to really use T3 Code at work. I'm loving it for personal projects that are contained to a single repo, especially the per-turn diffs, if multi-repo support was added I would switch to T3 Code at work immediately! For now I'm stuck in the Claude Code TUI 😅

Hi @stefanvandervelden-zipline - if you're willing to build/package yourself, my fork provides multi-repo support: LoganRupe/t3code @ multi-repo-workspaces. The build scripts are in the package.json. Feel free to raise issues on my fork, happy to address them. I try to rebase off this upstream every few days and grab the latest changes.
NOTE: The reason I haven't submitted a PR for this is because it's against their CONTRIBUTING.md atm. This is a large feature.

[stefanvandervelden-zipline]

The lack of multi-repo support is basically preventing me from being able to really use T3 Code at work. I'm loving it for personal projects that are contained to a single repo, especially the per-turn diffs, if multi-repo support was added I would switch to T3 Code at work immediately! For now I'm stuck in the Claude Code TUI 😅

Hi @stefanvandervelden-zipline - if you're willing to build/package yourself, my fork provides multi-repo support: LoganRupe/t3code @ multi-repo-workspaces. The build scripts are in the package.json. Feel free to raise issues on my fork, happy to address them. I try to rebase off this upstream every few days and grab the latest changes. NOTE: The reason I haven't submitted a PR for this is because it's against their CONTRIBUTING.md atm. This is a large feature.

Oh that's awesome @LoganRupe! I wasn't sure how much work you were planning to put into maintaining that fork, so didn't want to jump straight into it at first. I'll definitely make sure to report anything I find! Thanks for the fork, hopefully you don't have to maintain it for too long!

[stefanvandervelden-zipline]

@LoganRupe your fork seems to have github issues disabled, I believe that's just the default for forks, and I think you can just enable issues in the repo settings? I've already encountered one thing that might be worth fixing, and I noticed that I couldn't actually post an issue 😅

Seems to be working so far though! Haven't done much with it just yet though (been busy)

[LoganRupe]

@LoganRupe your fork seems to have github issues disabled, I believe that's just the default for forks, and I think you can just enable issues in the repo settings? I've already encountered one thing that might be worth fixing, and I noticed that I couldn't actually post an issue 😅

Seems to be working so far though! Haven't done much with it just yet though (been busy)

Allowed issues now. Ta. 👍

[CDVolvik]

Same use case keeps coming up: a project root with multiple nested git repos under it (VS Code multi-root / workspace style). Opening the parent works for the agent, but git / diffs / worktree features don't treat the child repos as roots.

If you're hitting this, please don't open a new issue — 👍 this one and drop a short note with your layout (parent path + how the nested repos are arranged). Signal helps more than duplicates.

Stopgaps people are already using (not official, not a PR into main — CONTRIBUTING is still cool on large features):

• https://github.com/LoganRupe/t3code/tree/multi-repo-workspaces — projects via `.code-workspace`, diffs grouped per repo
• https://github.com/func0der/t3code/tree/feat/multi-repo-root — earlier multi-repo-root branch

Would love first-class multi-repo roots in upstream whenever the team is ready for it.

[alanbem]

Yup, my use case as well.

I need to work with multiple repositories. They are in different progress of agentification, so I created workspace directory - that contains those repos - where I setup my agentic context, docs & skills. Agent can work on single or multiple repos at once depending on the scope.

Would love to have such support in T3 Code

[olesuv]

Hey, I’ve also been working on multi-folder workspace support in my fork: implementation and notes.

I decided to close my fork PR after reading the contribution guidelines and finding your work here. I hadn’t agreed on scope with upstream maintainers, and there’s substantial overlap, so I’d like to coordinate rather than pursue a competing PR.

My branch includes explicitly listed external and non-Git folders, named-folder browsing and @ mentions, grouped repository review, and mobile repository-specific Git controls. It uses existing checkouts and doesn’t support multi-repo worktrees or file restoration on rewind.

The code remains available as a reference.

[LoganRupe]

@maria-rcks thanks for pointing us back here, and understood on review capacity. Credit where it's due though: @Tr1Fecta-7 rebuilt this whole feature on orchestration V2 at about a tenth of the old fork's size, and #15752 is a solid piece of work.

I'm not going to pitch a smaller PR. I'd rather agree on what the feature should be first, then cut PRs to fit whatever you sign off on.

Where things stand: we've run multi-repo workspaces on a fork since August, and a handful of people from this thread use it daily. #15752 stayed inside the #12089 triage: only repos inside the project folder count, there are no schema or event changes, and single-repo projects are untouched.

Three questions I'd like answered before anyone opens more PRs:

1. Do you want multi-repo projects in T3 Code at all? "Not now" helps too, since people here are planning around it.
2. If yes, which model do you prefer? One is a folder of repos discovered from disk, which is what feat: one project can hold several Git repositories #15752 does. The other is a project that lists its roots explicitly, like the Codex-style ask further up.
3. Which part matters most to you first: turn diffs and rewind across repos, per-repo Git actions, or New worktree across repos?

If a design write-up here or a quick call is easier than reading 54 files, I'm happy to do either. If you'd rather reimplement it your way, the fork is there as a reference.

[Tr1Fecta-7]

Yeah @maria-rcks any idea on what a smaller scope should be?

[maria-rcks]

reopened, but this seems like something julius / theo would like to build themselves.

[LoganRupe]

Thanks for reopening it. If Julius or Theo would rather build this themselves, that's completely fine by us. We mostly want multi-repo support in T3 Code, and who writes it matters a lot less. Take whatever helps from #15752 and the fork, or ignore it all.

Two things we ran into that are easy to miss, in case they save time:

• Checkpoints when only some repos have the ref. If a repo joins the workspace mid-thread, or a capture fails partway, recapturing the baseline in every repo overwrites the good checkpoints in the others. Earlier turns' diffs and rewinds then quietly pick up edits made between turns. The fix is to capture only in the repos that are missing the ref.
• Worktree containers. Non-repo entries like .env, node_modules and shared folders get linked back to the real project. That means a New worktree run can still change the original checkout.

If it ever makes the roadmap, a heads-up here would help the people in this thread who are planning around it. Until then the fork keeps us unblocked.

[Tr1Fecta-7]

reopened, but this seems like something julius / theo would like to build themselves.

Thanks! That's completely fine as Logan said. Could this be passed on to them to look into/build? It's a big thing in mine and many others' workflow which we would love to have without having to sync and keep a fork up to date :)

[qcho]

Hope it gets saw soon enough. Also I am wondering if with Orchestrator v2 we just need single repo agents with a2a protocol conversations insated of multi-repo support.

[LoganRupe]

Also I am wondering if with Orchestrator v2 we just need single repo agents with a2a protocol conversations insated of multi-repo support.

I think those solve different problems, and you'd want both.

Single-repo agents talking to each other covers "the agent in repo A needs something from repo B". Orchestrator v2 handles a lot of that already, since one thread can delegate to another. A2A would mostly matter for talking to agents that live outside T3.

The original ask here is a bit different. When one change spans repos, like an API contract plus the client that calls it, I want one agent that can read both sides, and one view of the git changes per repo so I can review it all together. With two agents passing messages, the API agent describes the change in prose and the client agent works from that description. That's slower and easier to get wrong than one agent looking at both.

So I'd see them as complementary. Delegation for loosely coupled work, multi-repo workspaces when the change is one unit.

[JoshuaDietz]

Would also love multi-repo projects. This is the one feature that's currently keeping my with my home-brewed solution: I can configure a project with multiple repos. And important for me: When I start a task, I can choose which of the repos should be part of the task. Only for these repos a worktree is created. An info file tells the agent that there were other repos that did not receive a worktree for this task. At any time, I can add more repos to a task. This is super helpful because working on a game I have a separate repo for assets that I don't want to be copied every time because it's big.

[stefanvandervelden-zipline]

Yeah that would be a pretty nice enhancement!

[edevri]

Right, claude and codex have no problem dealing with our 70+ polyrepo so long as I open them in the project root, which is how I'm using T3 code atm as well -- but that sacrifices the git integration (diffs, commit/push, PR's) so am forced to use vscode for that.

Btw: worktrees should not be created for all projects, just for the one(s) that are getting changed.

[LoganRupe]

When I start a task, I can choose which of the repos should be part of the task. Only for these repos a worktree is created. An info file tells the agent that there were other repos that did not receive a worktree for this task. At any time, I can add more repos to a task.

worktrees should not be created for all projects, just for the one(s) that are getting changed.

I built this in my fork: LoganRupe#352. It's merged into multi-repo-workspaces.

When you start a task you tick which repos get a worktree. The rest are linked in, and the agent is told they're there and to ask before changing them. That covers the big assets repo: leave it unticked and it's never copied. Projects with more than 8 repos start with nothing ticked, so a 70-repo polyrepo only gets worktrees for the repos you pick, and you keep diffs, commit, push and PRs for those. Once there are more than 5 repos the list gets a filter.

You can add or remove a repo on a running task from the composer or the thread details panel on web, or from the Git sheet on mobile. Removing a repo is refused if it has uncommitted changes, and its branch is kept.

One limit: you can't rewind a thread to before a repo was added. The PR has a before/after video and a web and iOS walkthrough.

[kieron]

Our layout is another data point for this. The root is itself a git repo: agent instructions, skills, docs and scripts. The product repos (backend/, frontend/, a few smaller services) are separate clones inside it, gitignored by the root. Most tasks span backend and frontend in one thread, so the root is our T3 project.

Two things from running this daily that I haven't seen covered yet:

1. Storage cleanup needs to be multi-repo too. Each repo's worktree should be judged against its own default branch (our backend's is develop) and its own PR, and the container removed only when every repo in it is done. Today worktreeUnchanged compares the root worktree with main. The root never gets its own commits, so that always passes. As far as I can tell, feat: one project can hold several Git repositories #15752's containers have no .git at the top, so cleanup would never collect them. That's safer than the alternative: when we nested repo worktrees inside the root's T3 worktree, cleanup deleted them with uncommitted work (filed as [Bug]: Storage cleanup deletes git worktrees nested inside a thread worktree, including uncommitted work #23866).
2. The root as a repo of its own. In our case the parent isn't a plain folder. It should be one of the repos, alongside the children it ignores.

+1 to choosing repos per task (as @JoshuaDietz described): most of our threads only touch one or two repos.

[LoganRupe]

Thanks @kieron, you were right about cleanup, and in my fork it was worse than you thought. With your layout the root repo's worktree is the container, and the nested backend/ and frontend/ worktrees sit inside it. Cleanup only checked the root, found nothing to keep, and removed it along with everything nested in it. That's the same data loss as #23866.

Fixed in LoganRupe#354, now merged into multi-repo-workspaces. Cleanup now checks each repo's worktree on its own: local changes, its own default branch (so your backend is judged against develop), and its own PR. It removes the container only once every repo is done. Containers without a root repo now get cleaned up too. The PR has a before/after video.

For the root to count as a repo alongside the children, add a .code-workspace at the root that lists ., backend and frontend. Choosing repos per task is in as well (LoganRupe#352).

This fix doesn't help #23866 upstream. Worktrees you nest by hand don't have the fork's layout file, so cleanup has nothing to read there.

[JusticeMatthew]

Just figured I would add my two cents to try and get this feature added

I have 4 workspaces each with their own copies of our frontend/backend and would love to have those grouped nicely in the left panel allowing agents to still have full context of both + having proper diffs etc

Guess I'm sticking with Zed for now since I can do this there, hope to see this feature added soon, outside of this limitation the app as a whole is pretty nice and I was looking forward to trying it out more

[katafractari]

Most of my projects at home and at work consist of multiple repositories. T3 can work on such projects in the same way as vanilla Codex, the difference being that Codex detects all git repos in project child directories and shows diff for each of the repos, while T3 shows "Init git" for such projects because it's only looking at the root dir. This is the only issue that is currently keeping me from completely switching to T3 Code!

[sztadii]

@maria-rcks any idea when julius / theo will build it?

[frasza]

#26254

I think this is it? :) Cannot wait for this to land, ultimate W for the workflow I am usually using at work.

[Tr1Fecta-7]

Oh my, yes indeed! Let's hope it gets merged soon!

[Heldinhow]

+1 on this. My day-to-day work spans a few repos that change together, and right now I have to jump between separate T3 Code projects to keep one task going.
What I'd want, at minimum:
a workspace that groups several projects/reposone session that can read and edit files across all of themgit status/diff per repo inside that session
I built a version of this in my own fork of OpenChamber: a workspace is just a name plus a list of projects, and a session in it can read and edit files in every member repo. I also opened a feature request for it there (openchamber/openchamber#5972).
Would a small first step be acceptable here, like letting a session use extra folders as read/edit references, without any git orchestration? Happy to test

[t3dotgg]

on it

[xornet-sl]

Hey @t3dotgg
First before my rant, I want to give you my deep appreciation on what you and your team are doing in your free time, it's a very good product!
But (I'll try to keep my critic constructive, I promise!):

It's genuinely impressive how there are so many tools and harnesses around and they all support and focus on only tiny-scale projects. And by word project I mean project, like a system as a whole, not just its component.
Like take any reasonably big (not giant, just not tiny would also work) project with front-end, back-end, some infra repos, some side micro-services, API declarations/generators and what not. Those easily span across 5-10 or more repos very fast. And it's not like in open source world or in smaller companies we have a luxury of well established and mature mono-repo infrastructure and automation that makes all the problems I'm mentioning here non relevant. In a majority of non-FAANG world every component of a project sits in its own repo. And maybe it's something wrong with me, but aside of some independent libraries or ad-hoc tools, almost all projects which at least I know actually are multi-repo projects. And what the construct "project" describes the best is such collections of actually whatever that is doing and is being built to do something coordinated with the shared goal. Take as an example a whole web shop with all its related sub-systems and infrastructure.
From what I've seen at my job in some of the harnesses, projects are very beneficial not as a 1-1 mapping to a component (i.e. repo), but as a container of related components that share the same context, goal, history, decisions, rules, maintenance procedures. This is how it unlocks truly awesome things and serve the single entry-point for all the context and system-knowledge / memory items /skills / rules that agents' might need across all repos in the project and across external systems it needs to communicate to.
We can go even further and have sub-projects which, for example, can be used as a feature branch from pre-historic age but for the entire system level that requires a coordinated change to multiple repos. Sub-projects with context inheritance can actually have many more very cool use-cases, including sharing agents between people for a specific feature, but plain proper projects would be a good start anyway.

Sure, threads from different "projects" (in the current t3code's definition of work project) can communicate to each other and it's good, but as soon as the project you're working on goes beyond 1 repo I want to stop orchestrating just threads but want to orchestrate collections of threads / workstreams

I think a lot more people would start using t3code (or any other agent orchestration platforms to be honest) as soon as we stop focusing on a repo. Repo is a tool of delivering changes. It might not represent the system layout at all.
Given that you've delivered one of the very nice things that I've seen in big companies but not in any open and free platforms - seamless mobile client integration and multiple hosts with transferring sessions between them - the current implementation of "projects" is the only actual stopper where I could finally say that t3code is MUCH better than managing individual claude sessions with loads of skills in it either in terminal or in vscode.
Or maybe again it's just me, but the main reason I'd love to see this feature is a simple fact that I'm not working on only one single project, I'm working on multiple independent ones. And then I have multiple but related, but still isolated projects with their own multiple repos. It's not useful to have them all just completely mixed on a sidebar spanning across 30+ repos/projects with no hierarchy. That's why at home I still use tmux sessions and separate multi-root vscode windows even though I don't like it.

With all I've just said, I still very like the direction where t3code is going, and it feels surprisingly close to the best orchestration platforms I've seen so far in big companies while those platforms are closed and being developed by huge amount of people and you make it open and free.

[JanezStupar]

I’m already using T3 Code successfully with git-ws, and wanted to share my setup as a compatibility use case for future multi-repo support.

I open a parent workspace directory in T3. It contains a workspace-control Git repository alongside ten independent repositories covering the desktop app, web portal, backend services, shared libraries, website, QA, and documentation.

git-ws.toml declares each repository’s URL, relative path, target branch/revision, and groups. git-ws assembles the workspace and exposes shared AGENTS.md instructions and agent configuration at the root. Each repository retains its own history, branches, commits, and PRs.

One T3 conversation can work across the whole workspace—for example, updating a shared schema, backend, and client together. Agents use git-ws to discover the layout and Git commands within each repository for delivery. For concurrent work needing different revisions, I use separate complete git-ws workspaces.

The compatibility request: please preserve the ability to open an existing parent directory and work across its repositories without requiring T3 to own their checkout or branch lifecycle. The workspace root itself need not be a Git repository.

Per-repository diffs and Git controls would be welcome additions. Automatic worktree creation, branch switching, or rewind across repositories should be explicit and respect externally managed layouts. Keeping workspace context separate from Git isolation would preserve what already works well here.

[LoganRupe]

Update for anyone running my fork: Theo's #26254 is upstream's version of this, and it covers most of what multi-repo-workspaces does. I've been running a build of it across my machines today.

Two things if you switch to a build of that PR:

• Existing projects start with no tracked folders. Add them in project settings, or click Rescan if your .code-workspace sits in the project root. Rescan reads only one .code-workspace file, and if the project root is a symlink it finds nothing, so point the project at the real path first.
• The PR numbers its two migrations 73 and 74, and main has since used those numbers for different migrations. Before you move from a PR build to an official release, delete rows 73 and 74 from effect_sql_migrations so main's versions run. The PR's two are safe to re-run.

Once it lands I'll stop maintaining the fork.

[RonnyMarkus]

I'd like to add a use case and some requirements for the multi-folder work in #26254. I use Codex projects to combine a primary code repository with briefs, strategy documents, teaching materials and content folders. Those folders can be ordinary directories without Git, including locally synced Google Drive, Box or OneDrive folders.

The core request is one primary Git repository plus additional working/context folders, with these behaviors:

1. Keep the primary Git repository explicit. Adding context folders should not change which repository the existing Git controls operate on. This use case does not require Git orchestration across multiple repositories.

2. Allow additional folders at arbitrary local paths. They may be siblings of, unrelated to, or ancestors of the primary repository. They should not need their own Git repository. Locally accessible cloud-synced folders should work like other local folders; direct cloud-provider integrations are not part of this request.

3. Choose access per folder, independently of Git. Allow an additional folder to be read-only or explicitly editable. Read-only is a sensible default, but some folders are destinations for reports, documentation updates or content, rather than reference material only.

4. Make the folders usable within the same thread. The agent should be able to find, read and reference files across the attached folders, and create or edit files where write access has been granted. File search, file selection and previews should include these folders and make each file's origin clear.

5. Support overlapping roots without ambiguity. For example, /client/website is the primary Git repository, while /client holds the briefs and documentation. Both should be attachable without moving files or creating an umbrella Git repo. Search results should not duplicate the same file. In worktree mode, the primary repo's code must resolve to the task's worktree; attaching its parent must not accidentally send the agent back to the original checkout.

6. Persist the configuration per project. Keep the folder list and access choices across restarts. The same context folder may be used by several projects. Removing a folder association must leave its files and other projects' associations intact.

7. Handle unavailable folders visibly. If a folder is temporarily inaccessible, show that state, preserve its configuration, and keep the other folders usable.

The two additions that matter most for my existing setups are editable non-Git folders and ancestor context folders. The current proposal describes external plain folders as read-only, and the current validation rejects tracked folders that contain the home folder. The other points describe the expected end-to-end behavior and useful acceptance cases.

[aroraraunaq]

A gap I haven't seen raised here: in a project whose home folder has no .git (like the git-ws and plain wrapper layouts above), Edit from here never appears, not even Revert and keep changes. Every turn's checkpoint is recorded as missing, and the client only offers rewind when a ready checkpoint precedes the message (deriveRevertTurnCountByUserMessageId in apps/web/src/session-logic.ts).

Two questions for #26254:

• With tracked repos under a non-Git home, does Edit from here key off the per-repo checkpoint scopes, or still the home scope? If it's the home scope, declining "Initialize Git and commit home files" would leave rewind off.
• Conversation-only rewind doesn't need Git, since Claude and Codex roll back their own history. Could Revert and keep changes be offered whenever no ready checkpoint exists, with Revert files too disabled? That would also cover the non-Git folders in the comment above.

#28957 already separates missing from error, and this would leave it out.