.git is mounted read-only even though Codex is configured for workspace-write

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

• #14338

Powered by Codex Action

likely has something to do with the bwrap migration,

you can run ``codex features enable use_legacy_landlock`` to switch to the old behavior.

source: https://github.com/openai/codex/issues/14936#issuecomment-4101842750

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 #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. #13453 fixed bwrap to consume the split filesystem policy directly and re-apply those read-only subpaths.

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.

Thanks for the response! However, it raises the question: "why should writes to .git _not_ be allowed in workspace-write mode?" And if not, could an elevated mode be added that is not quite "yolo", but which allows writes to .git? It is a quite common workflow in my organisation to have agents perform git actions.

yea this basically means that codex cannot perform git commit within the sandbox. It's common in my workflow to have codex create a git commit and then create a pull request / merge request.

I think one workaround is to add

/path/to/my/project/.git

to writable_roots but it's a little annoying to do so when you have worktrees since you need to do it once for each worktree. Maybe we can have a configuration entry to allow git operations within the sandbox that binds .git as readwrite instead of read-only?

I was redirected here from #16794

I modified my app's config.toml to try to use the workaround:

model = "gpt-5.4"
model_reasoning_effort = "xhigh"
sandbox_mode = "workspace-write"
approval_policy = "never"
network_access = true

[windows]
sandbox = "elevated"

sandbox_workspace_write.writable_roots = ["C:\\<path>\\.git"]

The agent still can't write to .git:

Same result again: git commit -m "test" --dry-run fatal: Unable to create 'C:/<path>/.git/index.lock': Permission denied Nothing changed on this attempt.

I got the same problem on ubuntu 24.04 with the latest codex version (0.128.0).
As codex is good at debugging i let it do the digging :)

Here is what codex came up with and it worked for me (~/.codex/config.toml changes):

I was able to work around this by using a custom permissions profile instead of only [sandbox_workspace_write].writable_roots. The important bit is to explicitly grant write access to the active project’s .git via :project_roots: ``toml default_permissions = "workspace-git" [permissions.workspace-git.filesystem] ":root" = "read" ":tmpdir" = "write" "/tmp" = "write" [permissions.workspace-git.filesystem.":project_roots"] "." = "write" ".git" = "write" ".agents" = "read" ".codex" = "read" [permissions.workspace-git.network] enabled = true ``

But please fix that, doesn't make sense that .git is read only in the sandbox

Even codex cli is annoyed by this. This is part of my transcript:

  Only minor friction: the sandbox has .git read-only by default, so branch/commit operations needed escalation.
  Also the first nested branch creation hit a refs issue until running outside the sandbox. After that, it was normal.

› The .git permissions is a codex thing so you should talk to your owners :D

• Fair. I’ll file that with management.

  The practical effect is manageable, but it does make normal Git hygiene noisier than it needs to be: read-only .git
  means even harmless operations like creating a branch, staging, committing, or deleting a branch need escalation.
  For a coding agent, those are core workflow operations, not exceptional ones.

  At least the approval model kept it explicit, and once approved the branch/PR path worked fine.

› Yeah but that was annoying wasn't it?

• Yes, a bit.

  The annoying part is not the approval itself, it is that routine Git operations get broken into extra steps: try, fail, explain,
  rerun escalated. That interrupts the flow and adds noise around work that is already low-risk and expected in a PR workflow.

  A cleaner setup would allow .git metadata writes inside the workspace, while still requiring escalation for network pushes
  or destructive commands.

Confirming on macOS Codex CLI (workspace-write). Reproduced today:

$ git add scratch_file.md
fatal: Unable to create /Users/.../tool/.git/index.lock: Operation not permitted

$ git commit -m "test: scratch commit"
fatal: Unable to create /Users/.../tool/.git/index.lock: Operation not permitted

touch tool/.git/test_write fails the same way ("Operation not permitted"), but touch tool/test_write succeeds — so the restriction is on .git/ specifically, not the workspace root.

Tried both with and without sandbox_permissions: require_escalated; both fail with the same error. require_escalated bypasses network/UI restrictions but not the hardcoded .git read-only carveout.

My ~/.codex/config.toml uses a custom project-edit profile that extends :workspace, enables network, and scopes filesystem rules back to :workspace_roots with the standard **/.env deny. Full config:

default_permissions = "project-edit"

[permissions.project-edit]
description = "Project editing with OpenAI API access."
extends = ":workspace"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.filesystem.":workspace_roots"]
"**/.env" = "deny"

Even with that, git add / git commit still fail with the same .git/index.lock: Operation not permitted error — the .git read-only carveout wins.

Gotcha on the fix: the policy engine rejects **/.git for write:

Error loading configuration: filesystem glob path `**/.git` only supports `deny` access;
use an exact path or trailing `/**` for `write` subtree access

So the working lines are either of these (the .git/** form also covers files inside .git):

[permissions.project-edit.filesystem.":workspace_roots"]
"**/.env" = "deny"
".git"     = "write"   # exact path → main repo
# or, to also write into files inside .git (index, refs, objects, etc.):
# ".git/**" = "write"

Without one of those, the default .git read-only carveout wins and git add / git commit is impossible inside the sandbox.

It would be much nicer if Codex could stage/commit inside the workspace by default in workspace-write. Git metadata writes are core workflow operations, not exceptional ones, and the explicit escalation model already covers the riskier surface (push, force-push, etc.).