Codex Desktop selects enclosing repository’s branches for a project rooted in an independent nested Git repository

What version of the Codex App are you using?

26.901.51231 (build 8109), read from the installed application bundle with identifier com.openai.codex.

What subscription do you have?

Not provided. This issue occurs in local project Git controls before starting a model task.

What platform is your computer?

macOS 26.5.1 (25F80), arm64. Git 2.52.0.

What issue are you seeing?

I created a separate local Codex project with exactly one source folder: an independent Git repository nested inside another Git repository.

The project saves the correct source folder, but its repository label and branch picker show the enclosing parent repository. The branch picker includes branches that exist only in the parent.

Sanitized layout:

workspace/
  .git/                 # parent repository
  child/
    .git/               # independent child repository, actual directory
    ...

The child has a different origin remote and its own branch history. Direct Git discovery inside child/ correctly resolves the child root.

Observed in the project UI:

• Source folder: /path/to/workspace/child
• Repository label: <owner>/parent
• Branch search heading: Search parent branches
• Available branches: parent branches, including parent-only feature branches
• Local mode selected

The child has only one local branch, main, so the extra parent-only branches are not ambiguous.

What steps can reproduce the bug?

These describe the observed project setup; I have not independently reproduced this in a fresh synthetic repository.

1. Have a parent Git repository already saved as a local Codex project.
2. Place a separate Git repository with its own .git/ directory and different origin inside a child directory of the parent.
3. Leave that child directory untracked by the currently checked-out parent branch.
4. Add a new Codex local project selecting only the child repository directory.
5. Inspect Edit project: the sole source folder is the child.
6. Inspect the project repository label and open the branch picker in Local mode.
7. Compare against direct Git discovery:

git -C /path/to/workspace/child rev-parse --show-toplevel
git -C /path/to/workspace/child remote get-url origin
git -C /path/to/workspace/child branch --format='%(refname:short)'

The direct commands identify the child repository, while the UI displays the parent repository and parent branch choices.

Relevant setup detail: the parent is a superproject containing other submodules. The child was intended for submodule integration, but the locally checked-out parent branch currently has no gitlink entry for it. Therefore this report demonstrates independent nested-repository handling; behavior after checking out a parent commit that registers the child as a submodule has not been tested.

What is the expected behavior?

When the sole project source folder is itself a valid Git root, repository identity and Git controls should resolve to that repository.

If Codex intentionally selects an enclosing repository, it should clearly expose that selection and allow the user to choose the child repository before presenting branch, commit, push, review, or worktree actions.

The official Projects documentation says the primary folder is the default for Git operations and that PR/worktree actions target the primary repository:
https://learn.chatgpt.com/docs/projects

Additional information

Impact: the project name and source folder suggest child-only work, while the branch picker represents the parent. This makes it easy to select or create a branch in the wrong repository. I have not exercised the other mutation controls to test whether they share the same wrong association.

Current workaround: stay in Local mode and perform Git operations with an explicit child working directory after verifying its root and origin. Avoid relying on the desktop Git controls while they display the parent identity.

A standalone child checkout outside the parent is another potential workaround, but it has not been validated for this report. An external linked worktree is also untested.

Possible cause: repository association may be resolving or retaining the enclosing saved project rather than the selected nested Git root. This is a hypothesis, not a source-level diagnosis.

Related but apparently distinct:

• #26338: broader multi-repository parent workspace support.
• #33304: nested project sidebar organization.
• #14865: submodule diff path handling.
• #14894: monorepo subdirectory diff scoping; this child has its own Git root.

Private repository names, local usernames, file contents, and unrelated working-tree changes have been omitted. Screenshots have been transcribed into sanitized text.

Start by reproducing the nested-repository layout and compare the Edit project repository and branch picker with the listed git -C ... discovery commands. Trace how the selected source folder is associated with the repository used by Local-mode Git controls. Done means the child repository supplies the label and branches, or the UI clearly lets users choose the intended repository before Git actions.