`entire` hangs in `_dyld_start` when `syspolicyd` is wedged, blocking Claude Code session-start hooks

Summary

On macOS 26.3.1, every entire subcommand (including entire --version) can hang indefinitely if the system's syspolicyd is in a bad state. This silently blocks Claude Code's SessionStart hook, which in turn blocks Claude Code from starting in any repo where entire hooks claude-code session-start is wired in.

Mechanically this is a macOS bug, not a CLI bug — but the impact for entire users is severe (Claude Code becomes unusable across every enabled repo), and the workaround documented in #380 (xattr -d com.apple.provenance) no longer works on macOS 14+ because that attribute is now SIP-protected.

Environment

• macOS 26.3.1 (25D2128), arm64
• entire 0.5.6 (c9fedb4b), installed via brew install --cask entire
• Standard SessionStart hook calling entire hooks claude-code session-start

Symptom

• Claude Code hangs silently at session start
• entire --version from any shell hangs indefinitely
• Stale entire processes accumulate (in my case, 8 of them, oldest 18+ hours old, all in state S with 0% CPU)
• sample <pid> shows every one stuck in _dyld_start — the binary never reaches main()

Root cause

syspolicyd was wedged. PID had been alive for 42 days, 4 hours.

Kernel:

kernel: (AppleSystemPolicy) ASP: Security policy would not allow process: <pid>, /opt/homebrew/Caskroom/entire/0.5.6/entire

syspolicyd looping:

syspolicyd: [com.apple.syspolicy.exec:default] Unable to initialize qtn_proc: 3
syspolicyd: [com.apple.syspolicy.exec:default] dispatch_mig_server returned 268435459

When syspolicyd can't init the quarantine subsystem, dyld stalls every new process that triggers a policy check.

Fix

sudo kill <syspolicyd-pid>   # launchd respawns it within ~1s

launchctl kickstart -k system/com.apple.security.syspolicy does not work — SIP blocks it (150: Operation not permitted while System Integrity Protection is engaged). kill does work because SIP doesn't restrict signaling root processes.

Suggested CLI improvements

1. Self-imposed timeout in hook entry points. entire hooks claude-code session-start should bound itself to ~5s. A wedged syspolicyd currently cascades into permanently broken Claude Code sessions; a timeout + stderr would degrade gracefully.
2. Update troubleshooting docs. The xattr -d com.apple.provenance advice from #380 doesn't work on current macOS. Include the syspolicyd diagnostic (kernel log signature + kill <pid>).
3. entire doctor health probe. Attempt a self-launch with a short timeout; if it hangs, surface the kernel log signature so users can diagnose this in minutes instead of hours.

Start with the entire hooks claude-code session-start entry point and reproduce the hang described for macOS 26.3.1 with a wedged syspolicyd. Compare the three suggested directions—hook timeout, troubleshooting documentation, and an entire doctor health probe—and define which scope is intended. Done means the selected path degrades gracefully or guides diagnosis without blocking Claude Code startup.