Allow writable gitdir for current worktree in sandboxed workspace-write mode

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #14068

Powered by Codex Action

seems same with #12280

Thanks for the report! This just brings the linux sandbox behavior in line with macOS where writes to .git are not allowed. This was a missing feature on Landlock which is why it was working before.

Before https://github.com/openai/codex/pull/13453, the bubblewrap path was accidentally not re-applying the default .git / resolved gitdir read-only carveout after writable roots, so git metadata writes worked in workspace-write on Linux by accident. https://github.com/openai/codex/pull/13453 fixed bwrap to consume the split filesystem policy directly and re-apply those read-only subpaths.

Additional repro from Codex Desktop (macOS) in workspace-write mode:

• Writable roots include both project root and parent (e.g. /Users/.../Development/Hero-Soccer and /Users/.../Development).
• Normal file writes in repo succeed.
• Any write under .git/ from agent tool calls fails (Operation not permitted / unable to create .git/index.lock).
• Same machine/user can write to .git from external terminal and Codex terminal, so this appears specific to sandboxed tool execution.

Question from field use: does config support a wildcard allow-list for many repos (e.g. /Users/.../Development/*.git), or is explicit per-repo opt-in required once an override exists?

I opened a push-specific variant of this writable-gitdir problem: #21869 .

In workspace-write with network_access=true, I reproduced a case where git push updated the remote branch first, then failed updating the local remote-tracking ref under .git/refs/remotes/origin/* because the sandbox made the gitdir read-only. The command printed the lockfile error but exited 0.

The resulting state is worse than ordinary .git/index.lock failures:

• remote branch equals local HEAD
• local origin/<branch> remains stale
• git status still says [ahead 1]
• git fetch cannot repair because .git/FETCH_HEAD is also read-only

So the fix here is not only “Git cannot write .git”; it is also that Codex should not let/interpret a remote side effect as a failed local-only Git operation. At minimum, after this push-specific failure, Codex should verify with git ls-remote and report “remote push succeeded; local tracking ref is stale” rather than debugging auth/permissions/branch state or retrying blindly.

I ran into the same safety/autonomy tradeoff: I wanted to keep Codex in a safer workspace-write posture, but normal local Git operations need writes under .git, so the options become either repeated approvals/manual Git or relaxing the sandbox much more than I wanted.

I built a small local MCP server as a workaround: codex-safe-git.

Repo: https://github.com/K1-R1/codex-safe-git

It does not make .git broadly writable and it does not expose arbitrary shell/Git access. Instead it gives Codex a narrow, auditable Git tool surface for things like status, diff summaries, branch preparation, and exact-file commits. Remote operations are intentionally out of scope.

Install:

go install github.com/K1-R1/codex-safe-git/cmd/codex-safe-git-mcp@v0.4.3

This is not a replacement for a proper upstream fix/config option, but it may be useful for people who want Codex to stay sandboxed while still letting it handle local Git workflows more autonomously.

Additional impact from Codex Desktop on macOS using a Codex-managed linked worktree:

• The active worktree itself is inside a configured writable root.
• The worktree's resolved gitdir and common Git directory are stored elsewhere, for example:

/path/to/codex-worktrees/<id>/repo
/path/to/main-repo/.git/worktrees/<worktree-id>
/path/to/main-repo/.git

• Normal source edits succeed in workspace-write.
• git add and git commit require writes to the external worktree gitdir/common directory, so the agent requests sandbox escalation and unattended work stops waiting for approval.

The available configuration workaround creates an undesirable security tradeoff: adding the shared /path/to/main-repo/.git directory to writable_roots permits much more than staging and creating an ordinary commit. It also removes the filesystem boundary for refs, repository config, worktree metadata, and other Git state.

The desired capability is narrower than "make .git writable":

1. Allow staging explicitly selected files in the current managed worktree.
2. Allow creating a normal commit after inspecting the staged diff and running hooks.
3. Keep destructive/history-rewriting operations such as reset, rebase, forced ref updates, and hook bypass outside that capability.
4. Resolve the active worktree gitdir/common directory automatically, without requiring users to expose the entire shared .git directory as a generic writable root.

This matters for long-running autonomous tasks: repeated sandbox approval prompts for ordinary local staging/commit operations halt otherwise safe, scoped execution. A Git-aware mediated capability, or an operation-scoped permission for the current worktree, would preserve both autonomy and the intended safety boundary.

All paths above are placeholders; the behavior is not repository-specific.