Linux sandbox mounts linked worktree gitdir read-only after writable ancestor bind

What version of Codex CLI is running?

codex-cli 0.125.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.5

What platform is your computer?

Linux 6.8.0-110-generic x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

Mate terminal

What issue are you seeing?

On Linux, Codex CLI's workspace-write sandbox makes linked Git worktree metadata read-only when the worktree's .git file points to a sibling repo's common Git directory.

PII-redacted setup:

• Current workspace: /home/user/projects/repo-1
• .git is a file containing:

gitdir: /home/user/projects/repo/.git/worktrees/repo-1

• The Codex filesystem profile makes the projects directory writable:

[permissions.example.filesystem]
"/home/user/projects" = "write"

Inside codex sandbox linux, the common repo becomes visible and writable, but the active worktree-specific gitdir is mounted read-only.

Observed inside the sandbox:

gitdir=/home/user/projects/repo/.git/worktrees/repo-1
common=/home/user/projects/repo/.git

TARGET                                          SOURCE                                                     OPTIONS
/home/user/projects/repo/.git/worktrees/repo-1  /dev/...[/home/user/projects/repo/.git/worktrees/repo-1]  ro,nosuid,nodev,relatime

GITDIR_NOT_WRITABLE

The effective mount policy appears to make the broad projects directory writable, then make the active linked-worktree gitdir read-only. The later, more specific read-only mount wins for that path.

This breaks git add. Confirmed failure:

fatal: Unable to create '/home/user/projects/repo/.git/worktrees/repo-1/index.lock': Read-only file system

Codex CLI version tested: codex-cli 0.125.0

Platform: Linux x86_64

Install method: npm global package

Sandbox mode: workspace-write

What steps can reproduce the bug?

Minimal reproduction, using only temporary paths:

set -euo pipefail

rm -rf /tmp/codex-worktree-repro
mkdir -p /tmp/codex-worktree-repro/projects
cd /tmp/codex-worktree-repro/projects

git init repo
cd repo
git config user.email "test@example.invalid"
git config user.name "Test User"
printf 'initial\n' > file.txt
git add file.txt
git commit -m initial

git worktree add ../repo-1 -b repo-1
cd ../repo-1

cat .git
git rev-parse --path-format=absolute --git-dir
git rev-parse --path-format=absolute --git-common-dir

printf 'change\n' > new.txt

Then configure Codex so the projects directory is writable. Example shape:

[permissions.example.filesystem]
"/tmp/codex-worktree-repro/projects" = "write"

Run this from /tmp/codex-worktree-repro/projects/repo-1:

codex sandbox linux -- bash -lc '
  pwd
  cat .git
  gitdir=$(git rev-parse --path-format=absolute --git-dir)
  common=$(git rev-parse --path-format=absolute --git-common-dir)
  printf "gitdir=%s\ncommon=%s\n" "$gitdir" "$common"
  findmnt -T "$gitdir" -o TARGET,SOURCE,OPTIONS
  findmnt -T "$common" -o TARGET,SOURCE,OPTIONS
  test -w "$gitdir" && echo GITDIR_WRITABLE || echo GITDIR_NOT_WRITABLE
  git add new.txt
'

Actual result:

GITDIR_NOT_WRITABLE
fatal: Unable to create '/tmp/codex-worktree-repro/projects/repo/.git/worktrees/repo-1/index.lock': Read-only file system

What is the expected behavior?

When the active workspace is writable and is a linked Git worktree, Codex should ensure the active worktree-specific gitdir is writable.

Specifically, this path should be writable inside the sandbox:

git rev-parse --path-format=absolute --git-dir

Expected result inside codex sandbox linux:

GITDIR_WRITABLE

Expected Git behavior:

git add new.txt

should succeed instead of failing to create index.lock.

Implementation-wise, either of these would satisfy the expectation:

1. Do not make the active worktree gitdir read-only when it is already under a writable root.
2. Add a later/more-specific writable rule for git rev-parse --path-format=absolute --git-dir.

Deny rules for secret-like files such as .env should still take precedence.

Additional information

This affects generic linked worktree layouts such as:

/home/user/projects/repo
/home/user/projects/repo-1
/home/user/projects/repo-2

The problem is not specific to one repo name. It happens because the linked worktree .git file points outside the active worktree to a sibling common repo:

gitdir: /home/user/projects/repo/.git/worktrees/repo-1

Making /home/user/projects visible/writable solves common-dir visibility and allows git status, but it does not allow Git write operations because the active worktree gitdir remains read-only.

This appears to be a Linux workspace-write sandbox policy bug for linked Git worktrees.