[max-sixty]

On macOS with the builtin fsmonitor enabled (core.fsmonitor=true), wt list and the wt switch picker fork git fsmonitor--daemon start for every worktree inside the post-skeleton rayon::scope, and the per-row task pool can't start until all of them return. In the steady state nearly every start exits 128 "already running"; in a 128-worktree repo those forks cost 100–300ms before the pool opens.

Repository::start_fsmonitor_daemon_at now first connects to <git-dir>/fsmonitor--daemon.ipc and returns without forking if a daemon answers. That's the check git's own start makes before refusing (ipc_get_active_state connects and closes). Any failure — no daemon, stale socket, unresolvable git dir, or a socket path longer than sun_path — falls through to the existing fork. The git dir is already primed from the worktree list on this path, so the probe runs no git command.

The socket basename is now shared as git::fsmonitor::IPC_SOCKET_NAME with the wt remove stop path.

The new unit test binds a UnixListener at the repo's socket path and checks, via captured trace records, that no git fsmonitor--daemon start runs while it answers and that the start does run for a path with no git dir. It fails with the early return removed.

🤖 Generated with Claude Code

This was written by Claude Code on behalf of max-sixty