[Feature]: Show changed files from repositories modified by the agent

[Wiktorkulas51]

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:

context-repository/
application-repository/

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

1. The active T3 Code project is the context repository.
2. The agent modifies files in a separate application repository.
3. The agent confirms that files in the application repository were changed.
4. The Changed files panel shows only changes from the active context repository.
5. The changes in the application repository are missing from the panel.

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:

1. Show changed files grouped by repository.
2. Automatically detect which Git repository was modified.
3. Provide a repository selector in the Changed files panel.
4. Show a clear notice when the agent modifies files outside the active workspace, with an option to open that repository's diff.

For example:

context-repository
  No changes

application-repository
  src/components/Example.astro
  src/pages/index.astro

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

• T3 Code
• Windows
• Multiple local Git repositories
• One repository used for agent context and instructions
• One or more separate repositories used for application development

[juliusmarminge]

Triage

Confirmed on current main (ccf220be2) and shipping 0.0.42 / nightly 0.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) renders ChangedFilesCard from turnSummary.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.workspaceRoot in apps/server/src/checkpointing/Utils.ts). There is no second repo.

git add -A -- . (GitVcsDriver) cannot see a sibling Git repo. Nested .git directories 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.

DiffPanel uses activeThread.worktreePath ?? activeProject.workspaceRoot. Disabled reason: “Diff is only available for server threads in Git repositories.” No repository picker on main. t3.json has no repositories field (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.json repositories list; Diff picker for nested repos under the project folder	Paths 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 members	Validates workspace membership and path boundaries. Does not collect nearby worktrees. Same gap.
main / 0.0.42	One 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.

1. 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.
2. 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.
3. Do not auto-capture checkpoints, git add, or restore in sibling repos. Checkpoint refs are refs/t3/checkpoints/... in one .git. Multi-cwd capture/restore is a new product, not this card.
4. Do not add a repo selector that pretends sibling status is already in turnSummary.files. That array is one-repo numstat.
5. 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 parent git add -A still skips child .git trees.
• After feat(workspace): support explicit repositories across source control #11251 / feat(web): support multi-repository diff workspaces #9816: wrapper folder + t3.json repositories if 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)