CLI sandbox: cannot commit because .git is read-only (“Unable to create .git/index.lock”)

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

• #6797
• #6688

Powered by Codex Action

This a model tuning issue that can be ameliorated with a prompt. Add this to your AGENTS.md:
If a command fails due to insufficient permissions, you must elevate the command to the user for approval.

This is emphatically not fixed.

Bro codex can’t even run bash commands 🤣 light years behind Claude.

This is how people are commenting on Codex about this problem on Reddit. It's _extremely_ damaging for the reputation of OpenAI!

Personally, I've just installed Codex, I've no idea what the problem is with 'sandboxing', I do not want any git commands 'escalated' to me- in fact, I'd rather never touch a git commit again, all other LLMs are _perfectly_ equipped to do this automatically, so why can't GPT? It's the kind of thing that will make me never use it again.

This is an urgent and awful bug.

Yeah this is a huge pain, anyone got a workaround?

Same issue, codex suggested and applied a workaround to use a tmp folder outside the workspace to push

I was able to workaround this by adding .git as an additional directory when spawning codex via the sdk/cli

@jacobsapps, @lemieapp,

As mentioned in a older related issue, you could use a "git-shadow-dir". It is a writable, self referencing git worktree.

https://github.com/openai/codex/issues/5034#issuecomment-3529984021

Sadly this is intended: https://github.com/openai/codex/blob/a1b8e34938a26b3910de2abdb2e984aa12624354/codex-rs/protocol/src/protocol.rs#L753-L774

The subpaths are read-only sub-directory exceptions even when a directory is writable under workspace-write. Right now it includes .git (also gitdir when using worktree), .codex and .agents.

The rationale does not make sense to me. When I use codex CLI/TUI, the git repo is mostly a local copy. I will use rules in remote repo to guard against dangerous operations (protected main, no force push, etc.).

The "workaround" for me is simply comment out these lines and rebuild from source. But I would suggest to add a knob in workspace_write option to bypass this. Or, add a black list option explicitly with the current list as a default. A hidden hardcoded list is never a good practice in the long run.

Adding a approval rule for git also works some time, but it works poorly under approval-policy = never in environments where interaction is not possible. I have to tell agent again and again to "run command with escalation, without shell wrapper or bash script", etc.

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.

It's kinda odd that there isn't a way to specify in the config file that agents should have permission to commit without prompting the human. Committing is such a cornerstone of coding tasks. Just let me manually specify that .git is writable, please.

Also, allowing agents to run git outside the sandbox is such a bad idea. Actually running anything outside the sandbox is a bad idea. It gives much broader access than merely making .git writable.

@K1-R1 @dlight you can already do these things. See the rules docs.

@miraclebakelaser I want Codex to still run git sandboxed. I just don't want the sandbox to make .git read only. However this sandboxing rule appears to be hardcoded.

The problem with allowing commands to run outside the sandbox is that there isn't a way to say "give this command write to .git, and nothing more". Instead, the command will bypass the sandbox entirely. So for example, if the sandbox doesn't allow network access, when you add an exception for a command, it will allow network access for that command too.

Ideally I want zero exceptions on sandboxing, but instead tweak the sandbox to allow or disallow operations for all commands. Just like one can enable/disable networking for all commands inside the sandbox, marking .git writable should be possible, too.

Analysis (community)

Thanks for tracking this — attempting a residual-focused analysis aligned with docs/contributing.md (invitation-only: analysis in-thread, no unsolicited PR).

• Issue under review: #7071 — CLI sandbox: cannot commit because .git is read-only (“Unable to create .git/index.lock”)
• Theme / radar cluster: sandbox RO .git blocks commits (sandbox-git)
• Reporter posture: static + local evidence where available; not claiming a maintainer invite.

Observed (from issue + public residual signal)

What version of Codex is running? codex-cli 0.61.0 ### What subscription do you have? Plus ### Which model were you using? gpt-5.1-codex-max (Medium) ### What platform is your computer? Darwin 24.6.0 arm64 arm ### What issue are you seeing? On the Codex CLI, git commit fails with fatal: Unable to create '/path/.git/index.lock': Operation not permitted. The .git directory appears read-only to the assistant process (even touch .git/test-permission fails). This blocks committing from the CLI. N

Root-cause hypothesis (multi-surface)

Reports mix at least three mechanisms that should be one analysis story:

1. Intentional RO mount of .git under workspace-write / sandbox policy.
2. Empty RO .git directory injection that poisons external tools.
3. Windows Deny-ACL residue after unelevated/elevated sandbox transitions.

High-level fix outline (not a PR)

• Document intentional policy clearly if RO is required.
• Never leave empty RO .git behind; prefer gitdir allowlist or redirect.
• Windows: clear residual Deny ACEs after sandbox teardown.
• Fail-first: commit/status under workspace-write with real repo fixture.

Related open threads (cross-link, do not fork new)

#7071, #15505, #14338, empty-.git cluster (#29492 family), Windows ACL #32880.

Questions for maintainers

1. Is the intended long-term policy documented for this area (especially sandbox gitdir / log TRACE defaults)?
2. Preferred residual anchor issue if several open threads describe the same mechanism?
3. If the high-level outline above is roughly aligned, would an invited PR with failing-first tests be welcome later — or is an internal fix preferred?

Happy to refine with more measurements or code pointers. No unsolicited PR from me.

Analysis (community)

Residual analysis for #7071 (cannot commit: .git read-only under sandbox) — invitation-only.

Deterministic evidence (code on 5dd992acd3)

• codex-rs/protocol/src/permissions.rs:
• PROTECTED_METADATA_GIT_PATH_NAME = ".git"
• FileSystemSandboxPolicy::workspace_write always calls

append_default_read_only_project_root_subpath_if_no_explicit_rule(..., ".git") (≈L608)

• forbidden_agent_metadata_write(...) blocks agent writes into protected metadata under restricted FS policy (≈L46–L80)
• Seatbelt tests explicitly expect .git carveouts / blocked hooks: codex-rs/sandboxing/src/seatbelt_tests.rs (comments around pre-commit hook risk).

This is policy-shaped, not a random mount glitch: workspace-write grants project write then re-asserts RO on .git.

Root-cause hypothesis

Three user-visible failure modes share this policy core:

1. Intentional RO .git (security: hooks/config).
2. Empty RO .git directory confusion for external tools.
3. Windows Deny-ACL residue (separate but adjacent).

High-level fix outline (not a PR)

• Document “why .git is RO” in user-facing sandbox docs.
• Prefer gitdir redirect / allowlisted git operations over silent RO failures.
• Never leave empty RO .git that breaks git status outside the agent.
• Fail-first: workspace-write fixture repo must git commit via approved path OR emit a clear policy error.

Questions for maintainers

1. Is RO .git still non-negotiable security policy?
2. Preferred UX: explicit error vs allow worktree gitdir writes?
3. Would an invited PR for clearer errors + tests be useful?

No unsolicited PR from me.