Permissions error with git fsmonitor

Open 💬 7 comments Opened Mar 11, 2026 by dgilmanAIDENTIFIED

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.114.0

What subscription do you have?

Plus

Which model were you using?

n/a

What platform is your computer?

Darwin 25.3.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

iterm2

What issue are you seeing?

I have the git fsmonitor on (the core.fsmonitor setting enabled). All of my non-codex terminals are running under my regular Unix user account and codex is running under the same account.

Occasionally, if I do a git command in another terminal, and later if codex tries to run a git command of its own it runs into some issue with the fsmonitor IPC. My hunch is that you're running codex as some sandboxed user and the lack of permissions to the socket file causes IPC to error?

• Ran git diff -- myfile.txt
  └ error: fsmonitor_ipc__send_query: unspecified error on '.git/fsmonitor--daemon.ipc'
    diff --git myfile.txt myfile.txt
    … +15 lines

codex usually stumbles around until it gets a working command of some sort. Sometimes the LLM says something about a git error.

What steps can reproduce the bug?

I am not sure exactly how to reproduce it but it's some interleave of me running git commands outside of codex and codex running some as part of its own operation.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

7 Comments

etraut-openai contributor · 4 months ago

This is likely due to the sandbox policy enforcement in Codex.

dgilmanAIDENTIFIED · 4 months ago

If it is sandbox related is it possible to whitelist the IPC for this, or possibly invoke git with cli args that shut off fsmonitor?

etraut-openai contributor · 4 months ago

You'd need to determine whether what's being blocked. It could be a particular system call, a file system access, or a network access. You might find this documentation useful.

dgilmanAIDENTIFIED · 4 months ago

I can pretty reliably reproduce it with codex sandbox macos --log-denials git diff.

=== Sandbox denials ===
(git) sysctl-read security.mac.lockdown_mode_state
(git) sysctl-read kern.bootargs
(git) file-write-data /dev/dtracehelper
(git) network-outbound /Users/[...]/.git/fsmonitor--daemon.ipc
(less) sysctl-read security.mac.lockdown_mode_state
(less) sysctl-read kern.bootargs
(less) file-write-data /dev/dtracehelper
(less) file-write-create /Users/[...]/.lesshsQ

ghostflyby · 2 months ago

Is it possible to configure it manually as a workaround? I have tried without success.

hansdeutsch · 1 month ago

Running codex sandbox --log-denials git diff . shows various fsmonitor ipc connections denied. These are in fact unix sockets, so --allow-unix-socket .git seems to help. There are still "error: daemon terminated" though, and then eventually "error: fsmonitor_ipc__send_query: unspecified error on '.git/fsmonitor--daemon.ipc'"

More thorough logging can be achieved, with filtering to kernel messages including deny (which arise from sandbox violations), and some sbpl will be tinkered with to resolve that. I must now sleep, and let my terminal close.

0xdevalias · 1 month ago

This may be affected by #26880 in rust-v0.140.0, but it depends on the exact fsmonitor mode involved.

#26880

That change distinguishes Git's built-in fsmonitor daemon from helper/path-style or malformed fsmonitor values, and centralizes what Codex passes to internal Git reads. If the failure was caused by a helper/path-style fsmonitor being invoked inside the sandbox, current builds may avoid it by forcing core.fsmonitor=false.

If the failure is the built-in daemon IPC socket being denied by the macOS sandbox, this may still reproduce, because built-in fsmonitor can still be preserved when Git reports it as supported and enabled. A retest on 0.140+ with sandbox denial logging would be useful.