Misleading 'Blocked by endpoint security' popup on personal Mac with no endpoint-security software
Misleading "Blocked by endpoint security" popup on a personal Mac with no endpoint-security software
Environment
- Claude (desktop app) version
1.7196.0 - macOS
26.5(build25F71), Apple Silicon - Personal Mac, no third-party endpoint-security software installed (no CrowdStrike, SentinelOne, Carbon Black, etc.)
- No corporate MDM — personal Mac, not enrolled in any device management
The popup
A red error dialog reading:
× Blocked by endpoint security Your endpoint-security software blocked Claude Code. Ask your IT team to allowlist signing Team IDQ6L2SF6YDW. ``Claude Code process terminated by signal SIGKILL``
(The signing Team ID Q6L2SF6YDW is correct — codesign -dv /Applications/Claude.app confirms TeamIdentifier=Q6L2SF6YDW, Identifier=com.anthropic.claudefordesktop.)
The misleading part
For a personal Mac without third-party endpoint-security software AND without enterprise MDM, the message points at fixes that don't exist for the user:
- There is no "IT team."
- There is no consumer macOS settings panel for "allowlist signing Team ID Q6L2SF6YDW." (Gatekeeper / EndpointSecurity framework allowlists are enterprise/MDM concepts, not exposed in System Settings.)
- An operator hits this popup with no actionable next step on a personal Mac.
What the macOS unified log + diagnostic reports actually show
I dug through the last 6 hours of unified log + ~/Library/Logs/DiagnosticReports/ and /Library/Logs/DiagnosticReports/:
/usr/bin/log show --last 6h --predicate 'eventMessage CONTAINS "SIGKILL" OR eventMessage CONTAINS "killed" OR eventMessage CONTAINS "terminated" OR eventMessage CONTAINS "blocked"' | grep -iE "claude|endpoint|amfi|gatekeeper|jetsam"
- Zero SIGKILL events for Claude Code. (The only jetsam kill in the window was
spotlightknowledged.updater [1111], unrelated.) - Zero crash reports for Claude Code in either DiagnosticReports directory. Most recent reports are from days earlier and are for unrelated processes (
calaccessd,recentsd,transparencyd,SimLaunchHost). - Zero AMFI / Gatekeeper / EndpointSecurity blocks of Claude Code in the logs.
- Only kernel chatter for the
claudePIDs is routineunnest of range … of DYLD shared regionmessages, which the kernel itself notes are "not abnormal for debuggers" and are expected for any process that spawns many subprocesses (Claude Code spawns one per tool call).
So the "Claude Code process terminated by signal SIGKILL" message in the popup does not correspond to any SIGKILL the OS actually delivered. The popup is firing but the underlying claim is false.
Why this matters
The misleading popup sends operators chasing nonexistent settings on consumer Macs. In our case, the operator and I (as the assistant agent helping diagnose) both spent significant time looking for a "macOS settings panel to allowlist Team ID Q6L2SF6YDW" before realizing it doesn't exist for personal Macs. The popup misattributes whatever the actual underlying failure is (network blip? internal timeout? IPC error? websocket disconnect?) to "endpoint security blocked us."
Suggested fix
Either:
- Diagnose the actual underlying condition correctly. If the popup is showing for non-endpoint-security causes (network drops, internal timeouts, etc.), surface those instead.
- Gate the message on actual endpoint-security indicators. If macOS truly blocked the process via EndpointSecurity framework / AMFI / Gatekeeper, the message is fine — but only show it when those events are actually in the log. Otherwise show a generic "Claude Code process exited unexpectedly" message that doesn't send users chasing enterprise allowlists.
- At minimum, qualify the message for non-MDM machines: detect whether MDM is active and only show the "ask IT team / allowlist Team ID" framing on MDM-managed Macs.
Reproduction frequency
Intermittent — observed multiple times during a several-hour Claude Code session (running scheduled-task cron cycles + interactive operator work). Each occurrence is followed by the Claude Code session pausing until the operator manually intervenes.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗