False positive "Blocked by endpoint security" SIGKILL screen on clean personal Mac (no MDM/EDR)

Summary

Claude Desktop shows a misleading "Blocked by endpoint security" error screen with text "Your endpoint-security software blocked Claude Code. Ask your IT team to allowlist signing Team ID Q6L2SF6YDW. Claude Code process terminated by signal SIGKILL" on a personal Mac that has no MDM, no EDR, no system extensions, no security agents at all. The wording sends users to a non-existent "IT team" and away from the real cause.

Root-cause appears to be a catch-all wrapper that converts any SIGKILL of the Claude Code child process into the endpoint-security message — including cases where the SIGKILL is from the macOS kernel itself (resource limit termination), or from any other cause.

Environment

• macOS 26.4.1 (Build 25E253), Mac15,9 (Apple Silicon, arm64e), 48 GB RAM
• Personal MacBook, single user, admin access, no MDM enrolled
• Claude.app version 1.7196.0 (most recent SIGKILL clusters); crash report cited below is from prior version 1.6608.2
• No endpoint-security software installed (verified — see "Evidence" below)

Reproduction

The error reappears regularly during long Claude Desktop sessions. Internal ~/Library/Logs/Claude/main.log shows the SIGKILL clustering every 20-30 minutes during heavy sessions (17 events between 19:39 and 23:40 on 2026-05-12).

Evidence — Mac is clean

| Check | Command | Result |
|---|---|---|
| Endpoint Security System Extensions | systemextensionsctl list | 0 extension(s) |
| Configuration profiles (MDM) | profiles list | no configuration profiles installed |
| Running EDR processes | ps aux \| grep -iE 'sophos\|crowdstrike\|sentinel\|falcon\|jamf\|kandji\|...' | none |
| Security apps | ls /Applications | none |
| Kernel extensions | ls /Library/Extensions/*.kext | only HP printer / SoftRAID / Movavi — not security |
| Gatekeeper | spctl --status | assessments enabled |
| Code signature | codesign -dvvv /Applications/Claude.app | accepted, Notarized Developer ID, TeamIdentifier=Q6L2SF6YDW ✅ |
| macOS log of SIGKILL/jetsam events for Claude | log show --last 24h --predicate ... | 0 events (filtered hits were usernoted notifications-denied, unrelated) |

So nothing on the Mac is killing Claude through Apple's EndpointSecurity API.

Evidence — what's actually happening

Internal Claude main.log (~/Library/Logs/Claude/main.log)

The SIGKILL message comes from Claude's own JS code wrapping a child-process exit:

2026-05-12 19:39:24 [error] Session local_a444c7f6-... query error:
  Claude Code process terminated by signal SIGKILL {
    stack: 'Error: Claude Code process terminated by signal SIGKILL
      at CDi.getProcessExitError (/Applications/Claude.app/Contents/Resources/app.asar/.vite/build/index.js:397:8437)
      at ChildProcess.<anonymous> (/Applications/Claude.app/Contents/Resources/app.asar/.vite/build/index.js:397:8213)
      at ChildProcess.emit (node:events:521:24)
      at ChildProcess._handle.onexit (node:internal/child_process:295:12)'
  }

This error message is what the UI screen turns into "Blocked by endpoint security ... allowlist Team ID Q6L2SF6YDW". The mapping from "child got SIGKILL" → "endpoint security blocked you" is unsound: SIGKILL can come from many sources (OOM/jetsam, RLIMIT_*, resource-limit termination, parent calling kill, etc.).

macOS DiagnosticReport (/Library/Logs/DiagnosticReports/Claude_2026-05-11-232517_*.diag)

Event:            disk writes
Action taken:     none
Writes:           34.36 GB of file backed memory dirtied over 85090 seconds
                  (403.80 KB per second average), exceeding limit of 397.68 KB per second over 86400 seconds
Writes limit:     34.36 GB
Duration:         85089.95s

Heaviest stack (sampled 2361/2425 times):

v8::ArrayBuffer::GetBackingStore() ...
  temporal_rs_PlainTime_second ...
    v8::EmbedderStateScope::EmbedderStateScope ...
      v8::CpuProfiler::CollectSample ...
        fontations_ffi$cxxbridge1$194$font_ref_is_valid + 5710280
          write   (libsystem_kernel.dylib)

This is the Electron renderer dirtying file-backed memory at a sustained ~400 KB/s for 23 hours, triggering a kernel-imposed resource limit. Whether that's the same root cause as the 17 SIGKILLs in main.log is unclear, but it's at minimum a legitimate non-endpoint-security source of SIGKILL.

Expected vs Actual

Expected: the error UI should show the real exit reason — "child process exited with signal SIGKILL, likely resource limit / OOM / crash; check ~/Library/Logs/Claude/main.log and DiagnosticReports". A specific endpoint-security message should only be shown when EndpointSecurity API actually rejected execution (e.g. by reading the es_event_exec_t result, or by checking for installed system extensions of type endpoint-security).

Actual: every SIGKILL of the child process is reported as endpoint-security blockage, with instructions to contact an IT team. On a clean personal machine this is both alarming and actionable-in-the-wrong-direction.

Suggested fix

Two layers:

1. Don't conflate sources of SIGKILL. In CDi.getProcessExitError (app.asar/.vite/build/index.js:397:8437), don't bucket all SIGKILL into "endpoint security". Differentiate at least: (a) parent-initiated kill (the wrapper sent it), (b) macOS resource-limit/jetsam (check proc_pid_rusage / RUSAGE_INFO_*), (c) signal from an external party.

1. Gate the endpoint-security UI behind actual detection. Show the EDR-blocked screen only when there's positive evidence: systemextensionsctl list returns ≥1 extension whose category is endpoint-security, or profiles list shows an MDM profile that contains restrictions, or the kernel's audit subsystem actually reports an EndpointSecurity denial. Otherwise show a generic crash UI that links to ~/Library/Logs/Claude/ and /Library/Logs/DiagnosticReports/.

The current behavior also undermines the message for users who do have legitimate EDR blocks — they may now ignore it.

Side-note

The macOS crash report suggests Claude.app may have a separate underlying issue with sustained write-rate to file-backed memory in the V8/fontations/cpu-profiler path. Filing that as part of this issue for visibility — happy to split if maintainers prefer.