Skip to content

Codex App: support parent workspaces containing multiple Git repositories #26338

Open

Description

@WaterWhisperer

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:

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:

  1. Open each child repository as a separate Codex project.
    • This gives correct Git behavior, but loses the parent workspace organization and shared context.
  2. 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.
  3. 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 #15168 and #14218 were both closed as duplicates. From the visible public links, the duplicate chain appears to lead toward #14182 / #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.

Activity

  1. github-actions commented on Jun 4, 2026

    @github-actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  2. WaterWhisperer commented on Jun 4, 2026

    @WaterWhisperer
    Author

    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.

  3. jesperrix commented on Jun 12, 2026

    @jesperrix

    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-dir or sandbox_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:

    • Allow a Codex App project or thread to attach multiple local folders as workspace roots.
    • Show those roots explicitly in the UI, so the user can see what Codex can read/write.
    • Support per-root permissions, ideally read-only vs writable.
    • Let users add/remove attached roots when starting a thread, or from project/thread settings.
    • Keep Git/diff/review behavior grouped by repository where a root is a Git repo, while still allowing non-Git folders as context or editable support files.
    • Preserve the same sandbox clarity that --add-dir/writable_roots provide, 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.”

  4. nesl247 commented on Jul 1, 2026

    @nesl247

    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.

  5. willofferfit commented on Jul 3, 2026

    @willofferfit

    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

  6. Inaki-Nunsys commented on Jul 16, 2026

    @Inaki-Nunsys

    This functionality is essential for full-stack development.

  7. Falven commented on Jul 17, 2026

    @Falven

    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.

  8. BriceFab commented on Jul 23, 2026

    @BriceFab

    +1

    Same need here. Cursor’s Agents multi-workspace / multi-root UX is a great reference for how this can feel polished and useful when a task spans several repos under one workspace.

  9. willofferfit commented on Jul 23, 2026

    @willofferfit

    I've been doing multi-repo development using the codex app on MacOS, and agents are able to do it, but I need to deliberately tell them what repos to work with and to create new worktrees, as the app doesn't do it by itself. Also, the review pane for changes outside a project's repo is broken, so I just ask agents to create draft PRs and then I review on github.

    Telling you this just to show how much friction exists. Should be easily solvable by OpenAI's team (just ask GPT 5.6 Sol ultra to solve)

  10. EklipZgit commented on Aug 1, 2026

    @EklipZgit

    This is desperately needed, cmon guys... Is codex for vibe coders or for serious development? This will never get taken seriously by any organization with any sort of development scale if you can't work effectively in a workspace that contains multiple relevant repositories for cross repo work. The undo buttons wont even work if you're in a dir with multiple repos in it

  11. ViniciusLeviVL commented on Aug 31, 2026

    @ViniciusLeviVL

    +1

    I'm using the codex extension on Cursor and same issue here

  12. emeagenciadigital commented on Sep 6, 2026

    @emeagenciadigital

    +1 cursor does allows it on the IDE and Window UI .

    Now that open ai is leaving cursor I still don't get why they don't allow real developers to work correctly.

    I have separate repos like frontend backend and react native so a mono repo is not ideal in anyway .

  13. willofferfit commented on Sep 8, 2026

    @willofferfit

    I completely gave up using the app's native code review features, completely unusable if you're working with multiple repos and/or worktrees in the same session. Now I only use the app as a chat window, and use GitHub for reviews

  14. kie-kei commented on Sep 15, 2026

    @kie-kei

    +1

    i'm using codex desktop. i rly need native support for this feature

  15. pythonuntermensh commented on Sep 16, 2026

    @pythonuntermensh

    ++
    my friend's using codex desktop. he rly needs native support for this feautre

  16. ccmgitrepo commented on Sep 28, 2026

    @ccmgitrepo

    Adding a concrete Windows desktop use case for this request. I work in a parent directory containing several related but independently versioned repositories, and a single task often needs changes across them:

    C:\projects\          # workspace, not a Git repository
      backend\.git
      frontend\.git
      shared-library\.git
    

    The agent can work across these repositories, but reviewing the resulting changes in the native Review panel has been problematic:

    • The Review panel initially remained empty with a spinner; another attempt showed "No matching files" under Uncommitted, despite changes in the child repositories.
    • I explicitly added the child repository folders to the project. Their attachment was confirmed in the saved project configuration, but this did not make the changes reviewable. The panel picker subsequently showed only Files, Side chat, Browser, and Terminal.
    • A combined Markdown diff was provided as a workaround, but it is much harder to read and review than native diffs.

    The request is simple: let a parent workspace discover or explicitly attach independent child Git repositories, and reliably review changes across them within the same task. A repository selector and an all-repositories view with diffs grouped by repository would cover this workflow. Git actions should remain scoped to each repository.

    This should not require turning the parent directory into a Git repository or splitting one cross-repository task into separate tasks. If a configuration is unsupported or Git detection fails, an actionable explanation would help much more than an empty panel, persistent spinner, or missing Review option.

    The current documentation describes attached folders and multi-repository review, so this may also represent a gap between the documented workflow and the Windows app behavior we encountered. Please consider this additional reproduction and support for the existing feature request.

  17. pagrzybe commented on Oct 22, 2026

    @pagrzybe

    I need this a lot.

    Workspace-root:

    • .worktrees/
    • global_agent_rules/
    • project_one/
      ---- repo1/ (.git)
      ---- repo2/ (.git)
    • project_two/
      ---- repo3/ (.git)
      ---- repo4/ (.git)

    I need to be able to set each git repo, or any worktrees item, as a root for branch comparison.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appenhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions