claude-code - 💡(How to fix) Fix [BUG] Claude Desktop macOS — Helper crash loop in c-ares (`ares_dns_rr_get_ttl`) — false "Endpoint Security blocked Q6L2SF6YDW" dialog (1.8555.2 + 1.9255.0)

Summary

Claude Desktop on macOS enters a continuous SIGTRAP crash loop in Claude Helper due to what appears to be a use-after-free inside ares_dns_rr_get_ttl (c-ares) running on V8's main thread inside node::PrincipalRealm::timers_callback_function.

The crash triggers Electron's restart loop, which after enough failures surfaces the "Endpoint Security blocked Claude Code – Signing Team ID Q6L2SF6YDW" dialog (German fallback locale on cs-CZ systems). This dialog is misleading — there is no actual EDR / endpoint protection on the machine; it's a fallback error string after repeated child crashes.

Affects

• Claude Desktop 1.8555.2 (initial report)
• Claude Desktop 1.9255.0 (latest, downloaded today from downloads.claude.ai/releases/darwin/universal/1.9255.0/Claude-…dmg) — bug still reproduces identically
• macOS 26.5 (build 25F71), Apple Silicon (Mac16,5)
• Fresh OS, no third-party EDR, no kernel extensions outside Apple/Tailscale/ProtonVPN
• Crashes ~1–5 helper processes per minute in bursts; the main Claude process stays up while helpers thrash.

Reproducer

Just launch Claude Desktop on macOS 26.5. Crash loop begins within seconds. Disabling cowork features in the user config reduces frequency but does not eliminate it.

Crash signature

Exception:  EXC_BREAKPOINT (SIGTRAP)
Codes:      0x0000000000000001, 0x000000011e7cb3e4
procName:   Claude Helper
parentProc: Claude Helper
responsibleProc: Claude
bundleID:   com.anthropic.claudefordesktop.helper

Triggered thread — com.apple.main-thread
#0  ares_dns_rr_get_ttl + 3408796
#1  ares_dns_rr_get_ttl + 3408600
#2  v8::Script::GetCompileHintsCollector() const + 26352
#3  ares_dns_rr_get_ttl + 3408980
#4  v8::Object::WrapGlobal(v8::Isolate*, v8::Local<v8::Object> const&, v8::Object::Wrappable*, v8::CppHeapPointerTag) + 348580
#5  node::PrincipalRealm::timers_callback_function() const + 629672
#6  ElectronMain + 80
#7  ?
#8  start + 6992

Image:

name: Electron Framework
path: /Applications/Claude.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework
uuid: 4c4c44e6-5555-3144-a130-9b5b3f8d1c61

Repeats identically across hundreds of crash reports (~150 collected in two hours of attempts to recover).

Likely root cause

ares_dns_rr_get_ttl is part of c-ares (the async DNS resolver bundled with Node.js inside Electron). The repeated appearance of ares_dns_rr_get_ttl near v8::Object::WrapGlobal from node::PrincipalRealm::timers_callback_function matches the well-known c-ares 1.x use-after-free on the resolver ares_dns_record_t that has been fixed in c-ares 1.27.0+.

Specifically the pattern is: a Node.js timer callback dereferences a TTL pointer on a record whose underlying allocation has already been freed. The bug is reachable from very routine periodic DNS lookups (heartbeats, telemetry, MCP-related spawns).

So the Electron build shipped by Claude Desktop appears to be linked against an older c-ares that still has this UAF.

What I tried (none worked)

• Killing all orphan Claude processes
• Clearing GPUCache / Cache / Code Cache / Dawn*Cache / ShaderCache
• Disabling cowork in ~/Library/Application Support/Claude/claude_desktop_config.json:
  • coworkScheduledTasksEnabled: false
  • ccdScheduledTasksEnabled: false
  • coworkWebSearchEnabled: false
  • keepAwakeEnabled: false
  • Removing remoteToolsDeviceName
• Removing bridge-state.json, cowork-enabled-cli-ops.json, buddy-tokens.json (Claude recreates them on next launch)
• defaults write com.anthropic.claudefordesktop SUEnableAutomaticChecks -bool false, SUAutomaticallyUpdate -bool false, SUFeedURL "", DISABLE_TELEMETRY 1, DO_NOT_TRACK 1
• Emptying mcpServers to {} in claude_desktop_config.json
• Manually downloading and installing 1.9255.0 from downloads.claude.ai
• A wrapper that auto-restarts Claude when the crash loop is detected (LaunchAgent, every 60 s)

Disabling cowork reduces the crash rate from ~12/min to ~4–5/min, but the loop never stops. The bug is independent of MCP servers and cowork — the helper crashes even with "mcpServers": {}.

Effective severity

App is unusable without a watchdog: every ~30–60 seconds the renderer is killed by Electron and respawned. The misleading "Endpoint Security blocked" dialog scares users into thinking their EDR is at fault (or that there's actually corporate AV in the way — Anthropic's team ID Q6L2SF6YDW shows up in the dialog, making the false attribution very convincing).

Asks

1. Bump c-ares inside the bundled Electron/Node to ≥1.27.0 (or whichever release contains the UAF fix on ares_dns_record_t).
2. Improve the "child crashed too many times" fallback dialog so it does not say "Endpoint Security blocked Q6L2SF6YDW". Either show the actual crash signature or a neutral "Claude Helper repeatedly crashed — please report this with the diagnostic report" string. The current message generates a lot of false EDR/IT escalations.
3. (Optional, helpful) Expose a config flag to opt out of cowork's persistent heartbeat without resorting to deleting state files.

Environment

• macOS 26.5 (build 25F71), Apple Silicon Mac16,5
• DNS resolver: Tailscale MagicDNS (100.100.100.100)
• No third-party EDR / AV
• System extensions: Tailscale, ProtonVPN WireGuard (both stable, well-known)
• No corporate MDM

I have ~150 crash .ips files I can share privately if useful. Happy to test patches or share a diagnostic bundle.

Thanks!