[Bug]: Cross-repository edits are invisible before push approval

[juliusmarminge]

Originally filed as issue #18906 by @lucasdu4rte: #18906

---

Before submitting

• I searched existing issues. Related work and the remaining scope are described below.
• I included enough detail to investigate the problem.

Area

apps/web, apps/desktop; source-control review and push approval context.

Actual behavior

In one T3 Code session, the agent edited two separate Git repositories, but the UI only exposed changes from the repository associated with the thread. I learned that both repositories had been changed when the final chat response announced two pull requests.

I wanted to inspect the changes in both repositories before pushing. With the second repository absent from the review UI, I approved a push believing I was reviewing and approving the visible repository. The eventual operation included both repositories. That made the second repository's publication a surprise.

The problem is an incomplete review surface and unclear publication scope. This report does not establish that T3's native permission system bypassed a rejected approval or technically reused a repository-scoped permission. The original commands and approval prompts have not been captured.

Steps to reproduce / investigate

1. Open repository A as a T3 Code project and start a thread in its checkout or worktree.
2. Have the agent edit files in A and in a separate repository B outside the thread's Git root, using a provider/mode that permits those paths.
3. Inspect the thread's Changed files and Diff before any push.
4. Observe that the review is scoped to A and does not provide an inventory or diff for B.
5. Ask the agent to prepare the publication request without executing it. Check whether the user can clearly identify and review every repository targeted by that request.

The two-PR outcome is the user's reported incident. The investigation confirmed the current review scoping in source; it did not reproduce remote pushes or the original approval interaction.

Expected behavior

• Show a persistent indication when a session modifies more than one repository, including which checkout/worktree and branch each change belongs to.
• Let the user inspect each affected repository's changes before publishing, including local commits that have already left the working-tree diff.
• At minimum, show a clear notice when files were edited outside the thread's Git root, with a way to open the affected checkout for review. Tool activity or a final chat message should not be the only disclosure.
• Make push/PR requests explicitly identify the target repository, branch and remote. Approval for A must not be presented or interpreted as approval for B; publishing both should require an explicit choice of both targets or separate approvals.
• Linking multiple PRs after publication should not substitute for reviewing the repositories before publication.

Impact

Major degradation of review confidence: users can consent to publishing changes in a second repository without having seen that repository in the review UI.

Version or commit

• Server reported during this investigation: 0.0.46-nightly.20261012.3021.
• Current upstream source checked on October 13, 2026: 80664d5266a1be8c5989bac352ee5e060bbbdf4a.
• The version and permission mode of the original incident were not captured.

Environment

macOS, ARM64. Investigation performed from the Codex harness in T3 Code. No private repository names, home-directory paths or credentials are included.

Supporting evidence and related work

• DiffPanel.tsx, lines 238–255 resolves one activeCwd from the thread worktree or project workspace and queries Git status for that cwd. The current component has no multi-repository selector.
• Linked pull requests documentation supports several PRs in a thread, including other repositories. That is a published-review surface, not a local cross-repository change inventory.
• [Feature]: Show changed files from repositories modified by the agent #12089 describes invisible edits in a separate repository. It is currently closed as completed, but the current source still scopes this review to one cwd. This report adds the practical consequence for pre-push review and informed approval, rather than claiming the older issue remains open.
• feat: one project can hold several Git repositories #15752 is currently open and unmerged. Its proposed multi-repository support covers repositories inside a shared project folder and explicitly excludes repositories outside that folder. It therefore does not yet provide a shipped solution for this scenario.
• Earlier proposals feat(web): support multi-repository diff workspaces #9816 and feat(workspace): support explicit repositories across source control #11251 are closed without being merged.

Workaround

Open each affected checkout/worktree as a separate project, review its diff independently, and request an explicit push approval naming that repository, branch and remote. This is manual and relies on knowing the second repository was touched in the first place.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Closing as a duplicate of open Ideas #17989 (show changed files from repositories the agent modified). Same multi-repo review gap: Diff / Changed files stay on the thread's one Git cwd, so edits in a sibling repo stay invisible before push.

Please continue there. Open #15752 covers multi-repo inside a project folder and still excludes paths outside that folder, so it is related progress but not a full substitute for the #17989 ask (including the pre-push / per-repo approval UX called out here). Issue #18906 was already closed when this Ideas thread was opened.