You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Codex delegate_task worktree child cannot write Git metadata to stage or commit #26865
Withdrawn after security review. The writable-roots approach below lets a sandboxed child redirect Git configuration used by later unsandboxed Git operations. Do not use this implementation. A server-side commit tool that leaves the sandbox unchanged is now under review in fork PR #6; see the follow-up comment below.
Describe the bug
A Codex child created with delegate_task and isolation: "worktree" can edit its checkout but cannot commit in workspace-write modes. Git stores that checkout's index and HEAD outside the writable checkout, under the main repository's .git/worktrees/<name>.
The observed Windows failure was:
fatal: Unable to create '<main-repo>/.git/worktrees/<name>/index.lock': Permission denied
To reproduce
Start a T3 project backed by a Git repository.
Use delegate_task with Codex, isolation: "worktree", and runtime mode auto (or auto-accept-edits).
Ask the child to edit a tracked file, stage it, and commit. git switch -c also writes the per-worktree index and can fail.
Observe that checkout writes succeed while Git metadata writes fail.
Expected behavior
The child can stage and commit in its assigned worktree without turning off the sandbox or granting writes to the whole main repository.
Withdrawn proposed fix
Resolve the active linked worktree's Git metadata directory and add it to the Codex workspaceWrite.writableRoots, together with the common objects, refs, and logs/refs directories needed for commits. Do not grant the common Git directory or its whole worktrees container: those expose sibling worktree indexes and config/hooks. Read-only and full-access policies and approval settings should remain unchanged. The shared object/ref store is necessarily shared between Git worktrees; this does not promise isolation between branch refs.
Reported on Windows with a T3 delegated Codex workspace-write child. This report is based on the recorded failure; native Windows re-verification of the proposed patch is pending.
The writable-roots approach linked above was withdrawn after security review: it lets a sandboxed child redirect Git configuration used by later unsandboxed Git operations. Please do not copy that implementation. The fork PR is now draft and will not be merged in this form; a replacement approach is undecided.
The replacement under review is a server-side t3_worktree_commit MCP tool, exposed only to delegate_task children with a T3-created worktree. It leaves the Codex sandbox unchanged, validates the worktree against a server-held creation record, and commits only to the child's reserved branch with hooks and other Git callbacks disabled. It does not push. Fork implementation and tests: Fisi-Development#6. Cross-family review and native Windows/macOS verification are pending.
The fork fix has merged: Fisi-Development#6 (commit 759c0f1). Delegated worktrees now commit server-side through t3_worktree_commit, with the Codex sandbox unchanged. Native preview builds and rollout verification are in progress.
Correction to my last comment: we no longer run a T3 fork, so the fork change (Fisi-Development#6) is not deployed anywhere and does not fix this. The bug is still open on upstream builds.
Still reproduces on 2026-11-03 with codex-cli 0.166.0 on Linux, outside T3. In a linked worktree, codex exec --sandbox workspace-write -C <worktree> "git switch -c probe-branch" fails with:
fatal: cannot lock ref 'refs/heads/probe-branch': Unable to create '<main>/.git/refs/heads/probe-branch.lock': Read-only file system
The worktree files are writable. The shared .git directory is not. A T3 delegate_task Codex child with isolation: "worktree" therefore cannot commit. The server-side commit tool described above is one way to fix it without widening the sandbox. We do not recommend widening the writable roots: that lets the child change Git config and refs that later unsandboxed Git runs use.
Our workaround: children leave changes uncommitted and the parent commits.
I tried to reproduce this on the current build and could not.
On origin/main 6ba3de7 (Linux, codex-cli 0.167.2): started a dev server (T3CODE_DEV_SEED=0 vp run dev) whose fresh database had settings defaultRuntimeMode=auto, and added a one-commit test Git repo as a project. Ran t3 thread start --provider codex --model gpt-6-luna --wait with a parent prompt that calls delegate_task (provider codex, isolation "worktree", runtime mode auto). (1) When the child was told to run git add README.md && git commit -m probe once and report the output verbatim, it got fatal: Unable to create '<repo>/.git/worktrees/t3-.../index.lock': Read-only file system, which is the reporter's error. (2) When the child was simply asked to commit, its first sandboxed attempt failed the same way. Codex then requested escalation, its auto reviewer approved, and commit 8a05c35 probe2 landed on the child's branch t3/append-probe2-readme (checked with git log --all). (3) With runtime mode auto-accept-edits, the child's escalated commit stayed in a pending command approval (orchestration_v2_projection_runtime_requests kind=command, status=pending) for over 10 minutes, waiting for a person to approve it, which is how that mode treats any command that leaves the sandbox. Control: codex sandbox -c sandbox_mode="workspace-write" in the repo's main (non-worktree) checkout also fails with .git/index.lock: Read-only file system, so Codex's workspace-write sandbox keeps Git metadata read-only in every checkout, not only linked worktrees. The reporter's standalone probe (codex exec --sandbox workspace-write) runs with approval never, so escalation was never possible there. Windows was not tested.
Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.
Activity
royalaid commentedon Oct 29, 2026
The writable-roots approach linked above was withdrawn after security review: it lets a sandboxed child redirect Git configuration used by later unsandboxed Git operations. Please do not copy that implementation. The fork PR is now draft and will not be merged in this form; a replacement approach is undecided.
royalaid commentedon Oct 29, 2026
The replacement under review is a server-side
t3_worktree_commitMCP tool, exposed only to delegate_task children with a T3-created worktree. It leaves the Codex sandbox unchanged, validates the worktree against a server-held creation record, and commits only to the child's reserved branch with hooks and other Git callbacks disabled. It does not push. Fork implementation and tests: Fisi-Development#6. Cross-family review and native Windows/macOS verification are pending.royalaid commentedon Oct 29, 2026
The fork fix has merged: Fisi-Development#6 (commit 759c0f1). Delegated worktrees now commit server-side through
t3_worktree_commit, with the Codex sandbox unchanged. Native preview builds and rollout verification are in progress.royalaid commentedon Nov 3, 2026
Correction to my last comment: we no longer run a T3 fork, so the fork change (Fisi-Development#6) is not deployed anywhere and does not fix this. The bug is still open on upstream builds.
Still reproduces on 2026-11-03 with codex-cli 0.166.0 on Linux, outside T3. In a linked worktree,
codex exec --sandbox workspace-write -C <worktree> "git switch -c probe-branch"fails with:The worktree files are writable. The shared
.gitdirectory is not. A T3delegate_taskCodex child withisolation: "worktree"therefore cannot commit. The server-side commit tool described above is one way to fix it without widening the sandbox. We do not recommend widening the writable roots: that lets the child change Git config and refs that later unsandboxed Git runs use.Our workaround: children leave changes uncommitted and the parent commits.
juliusmarminge commentedon Nov 12, 2026
I tried to reproduce this on the current build and could not.
On origin/main 6ba3de7 (Linux, codex-cli 0.167.2): started a dev server (
T3CODE_DEV_SEED=0 vp run dev) whose fresh database had settings defaultRuntimeMode=auto, and added a one-commit test Git repo as a project. Rant3 thread start --provider codex --model gpt-6-luna --waitwith a parent prompt that calls delegate_task (provider codex, isolation "worktree", runtime mode auto). (1) When the child was told to rungit add README.md && git commit -m probeonce and report the output verbatim, it gotfatal: Unable to create '<repo>/.git/worktrees/t3-.../index.lock': Read-only file system, which is the reporter's error. (2) When the child was simply asked to commit, its first sandboxed attempt failed the same way. Codex then requested escalation, its auto reviewer approved, and commit8a05c35 probe2landed on the child's branch t3/append-probe2-readme (checked with git log --all). (3) With runtime mode auto-accept-edits, the child's escalated commit stayed in a pending command approval (orchestration_v2_projection_runtime_requests kind=command, status=pending) for over 10 minutes, waiting for a person to approve it, which is how that mode treats any command that leaves the sandbox. Control:codex sandbox -c sandbox_mode="workspace-write"in the repo's main (non-worktree) checkout also fails with.git/index.lock: Read-only file system, so Codex's workspace-write sandbox keeps Git metadata read-only in every checkout, not only linked worktrees. The reporter's standalone probe (codex exec --sandbox workspace-write) runs with approvalnever, so escalation was never possible there. Windows was not tested.Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.