Codex App: allow the diff viewer to follow or select the repository being modified

What variant of Codex are you using?

App

What feature would you like to see?

Codex App: allow the diff viewer to follow or select the repository being modified

What variant of Codex are you using?

Codex App

What feature would you like to see?

I would like the Codex App’s diff viewer to support repositories other than the project directory where a task was initially created.

Codex tasks can involve multiple repositories. A task may begin in one repository but require changes in a related service, library, dependency, documentation repository, or adjacent checkout. Codex can make those changes using an explicit working directory, but the diff viewer remains attached to the task’s original project.

As a result, the App may show no relevant changes—or changes from the wrong repository—even though Codex has modified files elsewhere.

My workflow

I frequently initiate Codex tasks from a local orchestration repository. That repository contains my reusable agent workflows, task tracking, and coordination tooling, while the actual code changes are made in other Git repositories.

Keeping the Codex task attached to the orchestration repository is useful because it provides the task’s operating context. However, the App’s diff viewer also remains attached to that repository, rather than showing the repository where Codex is implementing the requested change.

This means I can use my orchestration workflow or the App’s integrated diff-review experience, but not both together.

Requested behavior

• Allow users to select which repository the diff viewer displays.
• Optionally follow the thread’s effective working directory when it changes.
• Show a repository selector when a task accesses or modifies multiple Git repositories.
• Keep the selected repository sticky across subsequent turns.
• Continue using the original project as the default when no other repository is selected.

An explicit selector should remain available even if automatic detection is supported. Inferring the repository solely from the latest shell command could be unreliable because tasks commonly read or execute commands in repositories they do not modify.

Example

1. Create a task in repository A, which provides orchestration and task context.
2. Ask Codex to implement a change in repository B.
3. Codex edits files in repository B using that repository as its working directory.
4. git diff in repository B shows the changes.
5. The App’s diff viewer continues displaying repository A.

Expected result

The task can retain repository A as its original context while the diff viewer is switched to—or follows—repository B.

Additional information

This would also benefit general multi-repository development, service-and-library changes, related frontend/backend changes, dependency updates, documentation work, and other workflows involving adjacent checkouts.

The app-server protocol appears to contain relevant building blocks: the Git diff request accepts a cwd, and thread/turn settings can carry a working-directory override. This may allow the feature to reuse existing backend functionality.

I would be happy to provide additional examples or validate a proposed UX.