Issue Station
Sign In
Tools hereToolbox

codex - 💡(How to fix) Fix Linked worktree git add fails: .git/worktrees index.lock remains read-only despite --add-dir

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Root Cause

Multi-agent and automation workflows commonly use Git linked worktrees for isolated task execution. Without writable linked-worktree metadata, agents can edit files but cannot stage or commit them.

Code Example

/home/tangi/.nvm/versions/node/v24.0.1/bin/codex

---

Linux tangi-t14 6.8.0-111-generic #111-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 11 23:16:02 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

---

fatal: Unable to create '<main-repo>/.git/worktrees/<worktree>/index.lock': Read-only file system

---

<main-repo>/.git/worktrees/<worktree>/index.lock

---

MAIN=$(mktemp -d /tmp/codex-linked-main.XXXXXX)
git init "$MAIN"
printf base > "$MAIN/base.txt"
git -C "$MAIN" add base.txt
git -C "$MAIN" -c user.name=Codex -c user.email=codex@example.invalid commit -m initial
mkdir -p "$MAIN/.worktrees"
git -C "$MAIN" worktree add "$MAIN/.worktrees/task-1" -b task-1

npm exec --yes --package @openai/codex@0.132.0 -- codex exec \
  --sandbox workspace-write \
  -C "$MAIN/.worktrees/task-1" \
  --add-dir "$MAIN/.git" \
  -c 'approval_policy="never"' \
  'Create file smoke.txt containing smoke, run git add smoke.txt, then git status --short. Do not commit. Report the exact output.'

---

sandbox: workspace-write [workdir, /tmp, $TMPDIR, /tmp/liza-codex-0132-nolegacy-main.20rQJ8/.git] (network access enabled)

---

fatal: Unable to create '/tmp/liza-codex-0132-nolegacy-main.20rQJ8/.git/worktrees/task-1/index.lock': Read-only file system

---

?? codex0132-nolegacy-smoke.txt

---

0.125.0 without use_legacy_landlock => FAIL read-only index.lock
0.125.0 with use_legacy_landlock    => PASS git add succeeds
0.126.0-alpha.17 with use_legacy_landlock => FAIL panic before shell command
0.128.0 with use_legacy_landlock => FAIL panic before shell command
0.129.0 with use_legacy_landlock => FAIL panic before shell command
0.130.0 with use_legacy_landlock => FAIL panic before shell command
0.131.0 without use_legacy_landlock => FAIL read-only index.lock
0.131.0 with use_legacy_landlock => FAIL panic before shell command
0.132.0 without use_legacy_landlock => FAIL read-only index.lock
0.132.0 with use_legacy_landlock => FAIL panic before shell command

---

npm exec --yes --package @openai/codex@0.125.0 -- codex exec \
  --enable use_legacy_landlock \
  --sandbox workspace-write \
  -C /tmp/liza-codex-0125-main.qf7fvw/.worktrees/task-1 \
  --add-dir /tmp/liza-codex-0125-main.qf7fvw/.git \
  -c 'approval_policy="never"' \
  'Create file codex0125-legacy-smoke.txt containing codex0125-legacy-smoke-test, run git add, then git status --short.'

---

A  codex0125-legacy-smoke.txt

---

thread 'main' (...) panicked at linux-sandbox/src/linux_run_main.rs:311:9:
permission profiles requiring direct runtime enforcement are incompatible with --use-legacy-landlock
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---

<main-repo>/.git/worktrees/<worktree>/index.lock
RAW_BUFFERClick to expand / collapse

What version of Codex is running?

Tested across multiple npm package versions of @openai/codex:

  • 0.125.0
  • 0.126.0-alpha.17
  • 0.128.0
  • 0.129.0
  • 0.130.0
  • 0.131.0
  • 0.132.0

Current installed binary path in my normal environment:

/home/tangi/.nvm/versions/node/v24.0.1/bin/codex

System:

Linux tangi-t14 6.8.0-111-generic #111-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 11 23:16:02 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

Which model were you using?

gpt-5.5 in the smoke tests below.

What happened?

git add fails inside a Git linked worktree because the sandbox keeps the linked worktree index metadata read-only:

fatal: Unable to create '<main-repo>/.git/worktrees/<worktree>/index.lock': Read-only file system

This happens even when the main repo .git directory is passed with --add-dir and appears in Codex's sandbox summary.

This is related to #7071, but the failure here is specifically for Git linked worktrees. In that case git add does not write .git/index.lock in the worktree directory. It writes under the main repo metadata path:

<main-repo>/.git/worktrees/<worktree>/index.lock

Reproduction

Use a linked worktree and allow the main repository .git directory as an additional writable directory:

MAIN=$(mktemp -d /tmp/codex-linked-main.XXXXXX)
git init "$MAIN"
printf base > "$MAIN/base.txt"
git -C "$MAIN" add base.txt
git -C "$MAIN" -c user.name=Codex -c user.email=[email protected] commit -m initial
mkdir -p "$MAIN/.worktrees"
git -C "$MAIN" worktree add "$MAIN/.worktrees/task-1" -b task-1

npm exec --yes --package @openai/[email protected] -- codex exec \
  --sandbox workspace-write \
  -C "$MAIN/.worktrees/task-1" \
  --add-dir "$MAIN/.git" \
  -c 'approval_policy="never"' \
  'Create file smoke.txt containing smoke, run git add smoke.txt, then git status --short. Do not commit. Report the exact output.'

Observed Codex sandbox summary includes the main .git directory:

sandbox: workspace-write [workdir, /tmp, $TMPDIR, /tmp/liza-codex-0132-nolegacy-main.20rQJ8/.git] (network access enabled)

But git add fails:

fatal: Unable to create '/tmp/liza-codex-0132-nolegacy-main.20rQJ8/.git/worktrees/task-1/index.lock': Read-only file system

git status --short afterwards:

?? codex0132-nolegacy-smoke.txt

Version matrix

Same linked-worktree smoke test, using workspace-write, --add-dir <main repo .git>, and no named permission profile unless noted:

0.125.0 without use_legacy_landlock => FAIL read-only index.lock
0.125.0 with use_legacy_landlock    => PASS git add succeeds
0.126.0-alpha.17 with use_legacy_landlock => FAIL panic before shell command
0.128.0 with use_legacy_landlock => FAIL panic before shell command
0.129.0 with use_legacy_landlock => FAIL panic before shell command
0.130.0 with use_legacy_landlock => FAIL panic before shell command
0.131.0 without use_legacy_landlock => FAIL read-only index.lock
0.131.0 with use_legacy_landlock => FAIL panic before shell command
0.132.0 without use_legacy_landlock => FAIL read-only index.lock
0.132.0 with use_legacy_landlock => FAIL panic before shell command

Passing 0.125.0 legacy run:

npm exec --yes --package @openai/[email protected] -- codex exec \
  --enable use_legacy_landlock \
  --sandbox workspace-write \
  -C /tmp/liza-codex-0125-main.qf7fvw/.worktrees/task-1 \
  --add-dir /tmp/liza-codex-0125-main.qf7fvw/.git \
  -c 'approval_policy="never"' \
  'Create file codex0125-legacy-smoke.txt containing codex0125-legacy-smoke-test, run git add, then git status --short.'

Output:

A  codex0125-legacy-smoke.txt

Failing modern legacy-landlock runs panic before executing shell commands:

thread 'main' (...) panicked at linux-sandbox/src/linux_run_main.rs:311:9:
permission profiles requiring direct runtime enforcement are incompatible with --use-legacy-landlock
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Expected behavior

There should be a supported way for automation to run git add in a linked worktree under sandboxing without danger-full-access.

If --add-dir <main repo .git> is shown as writable in the sandbox summary, git add should be able to create:

<main-repo>/.git/worktrees/<worktree>/index.lock

Alternatively, Codex should document the supported configuration for linked worktrees.

Why this matters

Multi-agent and automation workflows commonly use Git linked worktrees for isolated task execution. Without writable linked-worktree metadata, agents can edit files but cannot stage or commit them.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

There should be a supported way for automation to run git add in a linked worktree under sandboxing without danger-full-access.

If --add-dir <main repo .git> is shown as writable in the sandbox summary, git add should be able to create:

<main-repo>/.git/worktrees/<worktree>/index.lock

Alternatively, Codex should document the supported configuration for linked worktrees.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Linked worktree git add fails: .git/worktrees index.lock remains read-only despite --add-dir