Codex App: support parent workspaces containing multiple Git repositories
What variant of Codex are you using?
App
What feature would you like to see?
would like Codex App to support parent workspace folders that contain multiple independent Git repositories.
Related issues:
- openai/codex#15168
- openai/codex#14218
Both issues describe a valuable workflow where a parent folder is used as the logical workspace, while the actual Git repositories live in child directories. For example:
workspace/
frontend/.git
api/.git
docs/This is common for full-stack projects, OSS work, and related repositories that are developed together but versioned separately.
The current options are awkward:
- Open each child repository as a separate Codex project.
- This gives correct Git behavior, but loses the parent workspace organization and shared context.
- Open the parent folder as the Codex project.
- This keeps the broader context, but the app does not behave like a Git-aware multi-repo workspace.
- Start from one child repository and let Codex edit sibling repositories.
- This can work for file edits, but the Git/diff/review UI remains tied to the starting repository.
Desired behavior could include:
- Detect Git repositories inside a parent workspace folder.
- Treat the parent folder as the workspace context while keeping Git state per child repository.
- Show diffs grouped by repository in one thread.
- Keep Git actions separate per repository, such as status, branch, commit, push, and worktree actions.
- Allow a thread to explicitly attach one or more child repositories.
- Preserve thread/project context when repositories are organized under a parent workspace.
- Optionally allow a saved Codex project to choose or remember a default child repository / working directory for new threads.
I noticed that openai/codex#15168 and openai/codex#14218 were both closed as duplicates. From the visible public links, the duplicate chain appears to lead toward openai/codex#14182 / openai/codex#10347, which seem more focused on Windows/WSL path normalization and Git detection issues. I may have missed the intended canonical issue, but I could not find a public tracker that covers the broader Codex App parent-workspace / multi-repository workflow described above.
If this is already tracked elsewhere, could you please link the canonical public issue? Otherwise, could this issue stay open as the tracker for Codex App support for parent workspaces containing multiple child Git repositories?
Additional information
This is not only about one folder preference. It affects workflows where a single product task often spans multiple repositories, but each repository remains independently versioned.
Solving this broader workflow would also address smaller related cases, such as using one umbrella Codex project for organization while starting most threads from a selected child repository.
7 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Thanks, I reviewed #25454.
However, I think this issue is not an exact duplicate. #25454 is focused on SSH remote host organization, where one remote host contains multiple subprojects and thread history needs to be grouped by remote path / repository.
This issue is focused on the Codex App workflow where a parent local folder contains multiple independent child Git repositories. The main asks here are local sub-repo detection, Git-aware diffs/review grouped by repository, and per-repository Git actions while keeping the parent folder as the workspace context.
If maintainers prefer #25454 to become the broader canonical tracker for both local and remote parent-workspace/subproject support, I’m happy to close this and move the local multi-repo details there. Otherwise, I think this issue is useful as the local Codex App counterpart.
I’d like to add a related use case that is slightly broader than parent-folder multi-repo detection: selecting multiple independent workspace folders directly in the Codex App UI for a single project/thread.
In tools like Claude Cowork, a common workflow is to choose several folders up front because one task naturally spans them: for example an app repo, a shared package repo, a notes/docs folder, and maybe a local scripts/utilities folder. These folders are not always children of one parent directory, and they are not always all Git repositories.
Today the closest Codex workaround seems to be starting from one folder and using CLI/config mechanisms such as
--add-dirorsandbox_workspace_write.writable_roots, but that is less discoverable and does not make the multi-folder workspace visible as a first-class UI concept.A useful version of this feature could include:
--add-dir/writable_rootsprovide, but expose it through the desktop workflow.The mental model I’m asking for is: “this task workspace consists of these folders,” not “this task starts in one folder and may be allowed to reach outside it through hidden config.”
This has been a pain point for me in every single harness/app out there. I'm not sure why everybody focused on single repos. I feel like it has to be less common to have a single repo in a company or never need to work across multiple repos in a single "task" so it's surprising. This would be a very welcome change.
I migrated from cursor, which supports multi-repo workspaces (probably due to vscode). Very unfortunate that codex app doesn't, I'll probably go back to vscode and use codex via the terminal
This functionality is essential for full-stack development.
I know that Codex only adds enhancements with enough upvotes and community support, but there are many related threads outlining the different issues in working on monorepos with submodules in Codex. Hopefully this can be fixed soon so we can leverage worktrees and the built-in committing, branching, etc.