Codex sandbox mounts empty .git at non-repo workspace root, breaking Git discovery in multi-repo workspaces

No source files or entry points are named. Reproduce with a non-repository parent containing multiple Git repositories, then run findmnt /.git and git -C rev-parse --show-toplevel; done means no fake root .git is created or mounted, child repository discovery remains intact, and the UI uses the selected folder basename when root Git metadata is unavailable.

Summary

Codex appears to create or mount an empty .git directory at the selected workspace root even when that root is not itself a Git repository and only contains multiple child Git repositories.

This can break normal Git discovery for tools such as VS Code and Git CLI. It may also cause Codex UI to display an internal/hash-like identifier instead of the selected workspace folder name.

Environment

• Platform: Linux x86_64
• Codex version observed in local thread state: 0.144.5
• Workspace shape:
  • selected root: <workspace-root>
  • <workspace-root> is a container directory, not a Git repository
  • multiple child directories under <workspace-root> are independent Git repositories

Example abstract layout:

<workspace-root>/
  repo-a/.git/
  repo-b/.git/
  repo-c/.git/

<workspace-root> itself should not contain .git.

What happened

During Codex usage, a .git entry appeared at the selected non-repo workspace root.

Inside the active Codex task sandbox, it appeared as a read-only tmpfs mount:

TARGET                  SOURCE FSTYPE OPTIONS
<workspace-root>/.git   tmpfs  tmpfs  ro,nosuid,nodev,relatime,mode=555,inode64

Running Git from the selected root failed:

git -C <workspace-root> rev-parse --show-toplevel
fatal: not a git repository (or any of the parent directories): .git

The local Codex thread state correctly recorded the workspace cwd as the selected workspace root, but Git metadata fields were empty.

The sandbox policy for the same task included <workspace-root>/.git as a read path even though the selected root was not a real Git repository.

In the UI, the selected workspace folder was correct, but the compose/workspace bar displayed an internal/hash-like identifier instead of the selected folder name. This appears to be a secondary symptom after Git metadata discovery fails.

Expected behavior

• Codex should not create or mount a fake/empty .git directory at a selected workspace root that is not a Git repository.
• If the selected root is a multi-repo container directory, Codex should preserve that structure and discover child repositories without poisoning the root with .git.
• Git discovery in VS Code and Git CLI should continue to work normally for child repositories.
• If Git metadata for the selected root is unavailable, Codex UI should fall back to the selected folder basename, not an internal workspace/task identifier.

Actual behavior

• A .git entry appears at the non-repo workspace root.
• In the active sandbox, that .git is a read-only tmpfs mount.
• Git commands at the workspace root fail with fatal: not a git repository.
• VS Code Git discovery can be confused by the fake root .git.
• Codex UI may display an internal/hash-like identifier instead of the selected workspace folder name.

Reproduction outline

1. Use a parent workspace directory that is not itself a Git repo.
2. Put multiple independent Git repositories underneath it as child folders.
3. Open/select the parent directory in Codex Desktop/Work or a Codex-attached VS Code session.
4. Start a Codex task.
5. Inspect the selected root and Git behavior:

findmnt <workspace-root>/.git
git -C <workspace-root> rev-parse --show-toplevel

6. Observe whether Codex exposes or mounts an empty .git at the parent root and whether Git discovery fails.

User impact

This is not only a cosmetic project-name display issue. It can break Git behavior for users who organize work as a parent directory containing multiple independent Git repositories, which is a common workspace layout. The fake root .git can interfere with VS Code source control, Git CLI discovery, Codex workspace naming, and tooling that walks up the directory tree looking for .git.

Notes

A real empty .git directory may also remain on the host in some cases. After removing that host-side empty directory, the active Codex sandbox may still show <workspace-root>/.git as a read-only tmpfs mount until the task environment refreshes. This suggests both persistent residue and per-task sandbox mounting may be involved, or that a stale host directory can be transformed into a sandbox mount for the running task.

Related but not identical: openai/codex#29408 covers repeated/stuck Git polling processes in Windows multi-repo workspaces. This report is specifically about an empty/fake .git at a non-repo workspace root breaking repository discovery and UI naming.