[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

[none23]

Here's what I would suggest.

1. Create a new git repo.
2. Add every repo in your project as a git subtree
3. Set up monorepo tooling if your repos depend on each other (they probably do). For Typescript I can recommend Turborepo.
4. Create a skill in the monorepo that tells your agents to
   • pull subtree changes before starting work
   • file PRs to the affected subtree repos when filing a PR to the monorepo

That preserves git history across all your repos and works with every tool I've used.

An agent should be able to set it up for you easily.

[LoganRupe]

Thanks @juliusmarminge for moving this into Ideas — feels like the right place to talk about direction, so I'll kick things off with what exists today and where I'd love to see it go.

What I've built so far (on my fork, branch multi-repo-workspaces, building on @func0der's feat/multi-repo-root groundwork):

A workspace is a project spanning several independent git repos, with a .code-workspace file as the source of truth — so the same workspace opens in VS Code and T3 Code, and repos can live anywhere on disk. From there I've been working through the single-repo feature set and making each piece repo-aware:

• Checkpointing and restore track a ref per repo, so turn and thread diffs cover the whole workspace and the diff panel groups changes per repo.
• Source Control shows per-repo status; isolated runs get one worktree per repo; terminals open in the repo you pick.
• @-mentions, file search, previews, and the file tree work across all roots, and agents launch knowing the workspace's shape.

It covers my day-to-day use on web and desktop, and a couple of people from this thread have been running it and filing issues on the fork, which has been genuinely useful — there are still rough edges, and each upstream rebase surfaces new ones. Mobile is untouched so far. I keep the branch rebased on upstream main.

Where I'd like this to go

The ask in this thread is consistent and pretty mainstream: frontend + backend repos, service fleets, workspaces people already have in VS Code. For some it's the one thing blocking adoption at work. I'd love multi-repo workspaces to eventually be first-class upstream rather than a fork people have to build themselves.

I know feature contributions sit outside the current guidelines, and I'm not trying to route around that. What I'd find most useful from the maintainers:

1. Is this a direction you want T3 Code to go at all? Even a "yes, but later" would help the folks in this thread plan.
2. If so, does this shape match how you'd want it — .code-workspace as source of truth, per-repo fan-out for checkpoints/diffs/worktrees — or would you approach it differently?
3. When the project is ready for it, I'm happy to split the work into small reviewable PRs, rework whatever doesn't fit the architecture you want, and stick around to maintain it.

No urgency on my side — the fork keeps me and others here unblocked — but I'm happy to help however is useful.

[mmuqiitf]

I still waiting for this. This can be very useful for everyone because i just stuck with Antigravity right now in order to get this capabilities.

[maxwagner-dev]

This sound like something I would also need. I don't really need the VSCode workspace feature of that, but we have multiple repos for our app (100+). Currently I basically have one main project using the grouping root folder of those git repos as project root.

What I would like to have is instead is the same feature / project structure Codex has. You can create projects based on what you think is correct. For me this would be some features I work on or something else. I want to add a project with a name and then be able to link multiple repos to that which I can use as default context for my threads.

Is this anywhere close to be implemented in t3code or do I have to keep forking it to make it work for me?

[paul-vd]

@none23 in #7041 (comment):

1. Create a new git repo.
2. Add every repo in your project as a git subtree
3. Set up monorepo tooling if your repos depend on each other …
4. Create a skill in the monorepo that tells your agents to pull subtree changes before starting work / file PRs to the affected subtree repos …

Tried this route. It works, but note what you are signing up for: git subtree is a monorepo with a sync duty. Each subtree push re-splits the whole history, so it gets slow with large repos. Upstream squash merges come back as duplicated history on the next pull. Per-repo tooling inside the subtree folder stops working, including stacked PRs and gh pr checkout. And agents must remember to pull first and fan out PRs.

If you control the upstream repos, retiring them and making the monorepo canonical removes all of that. If you do not, a plain parent folder plus a worktree setup script is less machinery, at the price of blind diffs in the tool.

[baanish]

Adding my use case here after #11051 was closed as a duplicate.

Managing my OpenClaw setup frequently requires context from both my clawd and clawdbot folders and changes across both at the same time. I need the agent to use both folders together in a single thread, not treat them as separate tasks.

I’d like to explicitly add both folders to one project. This should work for ordinary folders too, without requiring every folder to be its own Git repository. Where separate repositories are involved, keeping changes identifiable by repository would also be useful.

For a smaller first step, could T3 Code pass the additional folders through provider-native support, such as claude --add-dir path/to/dir? That could be a starting point for shared context and edits across folders, without requiring full multi-repo Git support up front. Repo-aware diffs, worktrees, and checkpoints would still need separate handling.