claude-code - 💡(How to fix) Fix Notarize the macOS claude CLI binary — un-notarized binary causes syspolicyd / XProtect YARA scanning storm on Sequoia (15+)

Summary

The claude binary installed via the standard installer (~/.local/share/claude/versions/<ver>) is signed by Anthropic (TeamIdentifier=Q6L2SF6YDW) but not Apple-notarized. On macOS Sequoia (15+), this causes severe system performance issues when the CLI is invoked frequently (e.g. by schedulers, agent loops, IDE integrations, CI runners), because each spawn triggers a full XProtect / YARA scan of the binary.

Evidence

Binary location:

/Users/<user>/.local/share/claude/versions/2.1.145

codesign -dv confirms the binary is signed:

Identifier=com.anthropic.claude-code
Format=Mach-O thin (arm64)
TeamIdentifier=Q6L2SF6YDW
Timestamp=May 19, 2026
Runtime Version=14.5.0

But spctl --assess rejects it (= no Notarization):

$ spctl --assess --type execute ~/.local/share/claude/versions/2.1.145
~/.local/share/claude/versions/2.1.145: rejected (the code is valid but does not seem to be an app)

Symptom

When parent processes (custom scheduler daemons, launchd jobs, cron, agent loops, IDE integrations) repeatedly spawn short-lived claude processes, macOS syspolicyd sustains 150-200% CPU continuously, because secassessment cannot cache the evaluation result for an un-notarized binary.

Confirmed via sudo sample <syspolicyd-pid> — hot threads include:

DispatchQueue_120: com.apple.security.syspolicy.yara  (concurrent)
DispatchQueue_145: syspolicyd.secassessment.xpc  (concurrent)
DispatchQueue: trust  (serial)

Dominant cost is YARA malware-rule scanning of the binary on every fork/exec, plus repeated certificate trust evaluation.

Knock-on effect: trustd runs at 60-70%, systemstatusd and WindowServer get dragged up, system idle drops below 5% even with no user activity. M3 Max chassis becomes uncomfortably hot. Reproduces on every reboot — this is not a transient bug but a permanent consequence of un-notarized distribution on Sequoia+.

Why this matters

• Claude Code is designed to be invoked frequently (agent sessions, sub-agent spawns, IDE integrations, automation loops).
• Every invocation = full YARA scan on Sequoia+.
• This is not a niche edge case — any developer wiring Claude Code into automation hits it.
• macOS 14+ progressively tightened scan caching for un-notarized binaries; the situation will only get worse on macOS 26.
• Anthropic is in the security business — shipping un-notarized binaries on macOS sets a poor example and creates avoidable thermal/perf issues for power users.

Workarounds tried (all failed)

• xattr -dr com.apple.quarantine — no quarantine attributes set (Sequoia uses com.apple.provenance instead)
• codesign --force --sign - ad-hoc resigning — spctl still rejects
• sudo spctl --add --label ClaudeCode <path> — hangs (deadlock with overloaded syspolicyd); effectively deprecated on macOS 15+
• sudo launchctl kickstart -k system/com.apple.security.syspolicy — blocked by SIP
• Adding parent processes to "Developer Tools" privacy whitelist — does not affect YARA scanning of child processes
• Disabling SIP — works but is a security non-starter

The only real fix is notarization on Anthropic's side.

Requested fix

Submit the macOS claude binary for Apple Notarization as part of the release pipeline.

Anthropic already has Apple Developer signing infrastructure (the binary is signed under Q6L2SF6YDW). Adding a notarization step is straightforward:

# after codesigning
xcrun notarytool submit claude.zip --apple-id <id> --team-id Q6L2SF6YDW --wait
xcrun stapler staple /path/to/claude

Once notarized:

• spctl --assess returns accepted: Notarized Developer ID
• secassessment caches the result
• YARA does not re-scan on every spawn
• syspolicyd CPU returns to baseline

This single change fixes the issue for every developer using Claude Code in automation.

Environment

• macOS Sequoia 15.5
• Apple M3 Max
• Claude Code version: 2.1.145

Happy to provide more sampling data, profiling traces, or test pre-release notarized builds.

Related: opened a parallel issue against openai/codex (#23649) — same root cause, same fix.