Codex App worktree creation hangs on macOS when forcing core.fsmonitor=true

What version of Codex is running?

Codex App 26.527.31326 (CFBundleVersion 3390)

What subscription do you have?

Pro

What platform is your computer?

macOS 26.3.1 (Build 25D771280a), arm64

What issue are you seeing?

Codex App can hang indefinitely while creating a managed worktree. The UI shows worktree creation has started and then stops after Git prints:

[info] Starting worktree creation
Preparing worktree (detached HEAD <sha>)

Local process inspection shows Codex App launched Git with core.fsmonitor=true:

git -c attr.tree= \
    -c core.attributesFile= \
    -c core.hooksPath=/dev/null \
    -c core.fsmonitor=true \
    worktree add --detach "$HOME/.codex/worktrees/<id>/<repo>" main

The parent git worktree add process waits for a child process:

git reset --hard --no-recurse-submodules

Sampling the stuck child process shows it blocked in Git's built-in fsmonitor IPC path:

cmd_reset
  repo_read_index
    read_index_from
      add_fsmonitor / tweak_fsmonitor
        refresh_fsmonitor
          fsmonitor_ipc__send_query
            ipc_client_send_command_to_connection
              read_packetized_to_strbuf
                read

Trace2 shows the fsmonitor daemon starts and accepts the request, then does not return a response:

git fsmonitor--daemon run --detach --ipc-threads=8
ipc-client send-command
fsmonitor handle_client
fsmonitor request <token>
# no response; client remains blocked

This leaves half-created Codex worktrees in locked initializing state and detached git fsmonitor--daemon processes.

Steps to reproduce

On the same repo, these two commands differ only by core.fsmonitor:

# Succeeds quickly
mkdir -p "$HOME/.codex/worktrees/probe-false"
git -c attr.tree= \
    -c core.attributesFile= \
    -c core.hooksPath=/dev/null \
    -c core.fsmonitor=false \
    worktree add --detach "$HOME/.codex/worktrees/probe-false/repo" main

git worktree remove -f "$HOME/.codex/worktrees/probe-false/repo"

# Hangs indefinitely at the internal reset step
mkdir -p "$HOME/.codex/worktrees/probe-true"
git -c attr.tree= \
    -c core.attributesFile= \
    -c core.hooksPath=/dev/null \
    -c core.fsmonitor=true \
    worktree add --detach "$HOME/.codex/worktrees/probe-true/repo" main

I reproduced this with both:

git version 2.50.1 (Apple Git-155)
git version 2.54.0 (Homebrew)

The same small test repository does not reproduce the hang, so this appears to require a larger/multi-worktree repo shape. However, the failing path is specifically enabled by Codex passing -c core.fsmonitor=true.

Expected behavior

Codex App should create the worktree without hanging. If fsmonitor is enabled for performance, Codex should either:

• avoid forcing core.fsmonitor=true during git worktree add, especially before the first checkout/reset in a new linked worktree; or
• make this behavior configurable; or
• add a timeout/fallback to retry with core.fsmonitor=false if Git's fsmonitor IPC blocks.

Workaround

A local wrapper that rewrites only -c core.fsmonitor=true to -c core.fsmonitor=false makes the same Codex-style worktree command complete successfully.

Additional context

This resembles existing macOS Git fsmonitor reports where commands hang or detached git fsmonitor--daemon run --detach --ipc-threads=8 processes accumulate. The key Codex-specific behavior is that the app appears to force core.fsmonitor=true for its Git subprocesses, which can trigger this path even when the user's repo config does not enable fsmonitor.