Repository navigation
[Feature]: Show changed files from repositories modified by the agent #12089
Description
Activity
Triage
Confirmed on current
main(ccf220be2) and shipping0.0.42/ nightly0.0.43-nightly.20260916.1811. This is a real enhancement, not a defect and not already fixed. Changed files and Diff only review the thread’s one Git cwd. Sibling application repos the agent edits stay invisible. Not a duplicate of #9816 or #11251 — those are in-workspace polyrepo and still reject paths that leave the project folder.What you reported. The active T3 project is a context/knowledge repo. The agent edits a separate application repo and confirms those files changed. Changed files still lists only the context repo (often nothing). You want files grouped by the repo that was actually touched, a selector, and a notice when work happened outside the active workspace.
That matches the code. The agent can write the other repo. Review does not follow it.
What the code does
1. Changed files is the turn checkpoint, not the agent’s file list.
AssistantChangedFilesSection(apps/web/src/components/chat/MessagesTimeline.tsx) rendersChangedFilesCardfromturnSummary.files. Empty files → the card is omitted.Those files come from
CheckpointReactor.captureAndDispatchCheckpoint:git add -A -- .plus numstat between two checkpoint refs, all in one cwd (resolveCheckpointCwd→thread.worktreePath ?? project.workspaceRootinapps/server/src/checkpointing/Utils.ts). There is no second repo.git add -A -- .(GitVcsDriver) cannot see a sibling Git repo. Nested.gitdirectories are not that tree. If the context repo is clean, the card is empty even when the application repo has edits.2. Diff / Git status use the same cwd.
DiffPanelusesactiveThread.worktreePath ?? activeProject.workspaceRoot. Disabled reason: “Diff is only available for server threads in Git repositories.” No repository picker onmain.t3.jsonhas norepositoriesfield (packages/contracts/src/t3ProjectFile.ts).3. The agent is allowed to edit the other repo.
Docs: “Projects are organizational boundaries, not filesystem sandboxes.” With Full access / a provider that will write those paths, the application repo changes. Chat and tool activity can mention them. Checkpoint + Diff do not.
Work-log “Changed files” text (
toolActivity/extractChangedFiles) is separate. It is not this panel. The panel is checkpoint numstat only.4. Open PRs do not cover sibling-outside-workspace.
Work What it does Why this still happens Open #9816 Optional t3.jsonrepositorieslist; Diff picker for nested repos under the project folderPaths must stay in the workspace. Symlinks that leave the folder are rejected. Checkpoints stay at the project root. Sibling application-repository/is out.Open #11251 Explicit polyrepo in one workspace ( paths,projects/*, submodules); Diff/Git/PR scoped to membersValidates workspace membership and path boundaries. Does not collect nearby worktrees. Same gap. main/0.0.42One project → one cwd → one checkpoint Git repo No multi-repo surface at all. Related, not the same: #10816 (review uses the selected thread’s repo), #11493 (open PRs in their actual repo), #11528 (V2 turn-start snapshot still one cwd), #10150 (pin turn-diff baseline, one repo).
No open issue matches “context project + agent writes a sibling Git repo + Changed files stays empty.”
Suggested direction
Keep this an enhancement. Do not treat it as a Changed files bugfix. Do not open a third multi-repo stack that also checkpoints sibling repos.
- If both trees can live under one folder, that is feat(workspace): support explicit repositories across source control #11251 / feat(web): support multi-repository diff workspaces #9816. Open the wrapper as the project and declare the child repos. Do not expand those PRs to arbitrary paths outside the workspace.
- Smallest useful extra for this issue: when a tool path resolves outside the thread Git root, show a notice on Changed files / Diff (“edited outside this workspace”) with the other repo’s name and a way to open that folder as a project (or its Diff). Detect from agent-touched paths only. Do not scan
$HOME. - Do not auto-capture checkpoints,
git add, or restore in sibling repos. Checkpoint refs arerefs/t3/checkpoints/...in one.git. Multi-cwd capture/restore is a new product, not this card. - Do not add a repo selector that pretends sibling status is already in
turnSummary.files. That array is one-repo numstat. - Tests (if you take the notice): context repo clean, sibling repo dirty via an absolute write; card/Diff says outside-workspace; context-only edits unchanged. Windows path variants.
Do not take “group every touched Git repo and diff them all” as the first change.
Workaround
- Make the application repo the T3 project when you want to review or commit those edits. Keep context as files you
@-mention or copy (AGENTS.md, docs) into that repo. - Or add both as separate projects and switch. Review follows the active project’s cwd.
- Opening a non-Git parent folder does not fix this on
main: checkpoints require a Git cwd, and parentgit add -Astill skips child.gittrees. - After feat(workspace): support explicit repositories across source control #11251 / feat(web): support multi-repository diff workspaces #9816: wrapper folder +
t3.jsonrepositoriesif you can nest both checkouts. That still will not include a sibling outside the wrapper.
Classification: enhancement (product: notice + “open the other project” vs in-workspace polyrepo only; sibling checkpoints are out of scope)
- locked and limited conversation to collaborators
on Oct 11, 2026
Description
I use T3 Code with multiple separate Git repositories.
One repository acts as a central context and knowledge repository. It contains project instructions, documentation, shared context, and information used by the agent.
Other repositories contain the actual applications being developed.
For example:
The active T3 Code project is the context repository because it contains the instructions and project information needed by the agent. However, I often ask the agent to modify files in a separate application repository.
The agent can successfully edit files in the application repository, but the Changed files panel continues to show only changes from the active context repository.
Current behavior
Expected behavior
The Changed files panel should detect and display changes based on the repositories and files actually modified by the agent during the thread.
Ideally, T3 Code should:
For example:
Why this matters
The current behavior makes it difficult to verify the agent's work. It can create the impression that no changes were made, or that the wrong files were modified.
This is especially problematic for workflows where one central repository contains the agent's instructions and project context, while implementation happens in separate application repositories.
The active workspace should be allowed to remain responsible for context and instructions, while the change review interface should still display modifications made in other repositories.
Possible implementation direction
T3 Code could track the Git repositories touched during the thread and expose their changes in the Changed files panel.
Alternatively, T3 Code could display a repository selector next to the current Changed files panel.
Environment