[BUG] dyld Symbol not found (_DNSServiceGetAddrInfoEx) crash on macOS 12.7.6 — claude-code 2.1.255

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

The claude-code helper binary bundled with the Claude desktop app crashes immediately on launch with a dyld dynamic linker error (exit code 134 / SIGABRT). The binary references the symbol _DNSServiceGetAddrInfoEx, which does not exist in this system's /usr/lib/libSystem.B.dylib.

This happens on macOS 12.7.6 (Monterey), which is the final macOS version supported on this hardware (2016 15" MacBook Pro — Apple's Ventura release dropped support for this model). The machine cannot upgrade past Monterey, so there is no OS-side fix available.

What Should Happen?

The claude-code binary should launch normally, or at minimum the app should detect an incompatible macOS/binary combination and fail gracefully with a clear message (e.g. "this build requires macOS 13+") instead of a raw dyld symbol crash.

Error Messages/Logs

Claude Code process exited with code 134. stderr:
dyld[18579]: Symbol not found: (_DNSServiceGetAddrInfoEx)
  Referenced from: '<home>/Library/Application Support/Claude/claude-code/2.1.255/claude.app/Contents/MacOS/claude'
  Expected in: '/usr/lib/libSystem.B.dylib'
dyld[18579]: Symbol not found: (_DNSServiceGetAddrInfoEx)
  Referenced from: '<home>/Library/Application Support/Claude/claude-code/2.1.255/claude.app/Contents/MacOS/claude'
  Expected in: '/usr/lib/libSystem.B.dylib'

Steps to Reproduce

1. Install/run the Claude desktop app (v1.40609.1) on macOS 12.7.6 (Monterey), on an Intel x64 Mac (MacBook Pro 15-inch, 2016).
2. Start a Cowork/Claude Code session and link it to this Mac (or otherwise trigger the app to launch its embedded claude-code helper, e.g. via the local device bridge).
3. The helper process crashes immediately on launch with the dyld error above; the local device bridge / Claude in Chrome integration never becomes available on this machine.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

Unknown for this specific machine. Similar reports (#50383, #50456) show the native binary's minimum macOS target moved to 13.0 starting around v2.1.104, with v2.1.112 and v2.1.3 respectively being the last versions that worked on macOS <13. This may be a related/same-class regression.

Claude Code Version

2.1.255 (from the crashing binary's path: .../claude-code/2.1.255/claude.app)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

N/A — crash occurs in the desktop app's embedded claude-code helper process, not invoked from an interactive terminal.

System: MacBook Pro (15-inch, 2016), Intel Core i7 2.6GHz, 16GB RAM, macOS 12.7.6 Monterey (last macOS supported on this hardware — Ventura dropped support for this model).
Claude desktop app version: 1.40609.1 (Electron 42.10.0, Node 24.18.1).

This looks like the same class of bug as:

• #50383 (v2.1.113 broken on macOS 11: dyld symbol not found — _ubrk_clone in ICU)
• #50456 (auto-updater silently broke Claude Code on macOS 11 — same root cause, closed as "not planned")
• #69928 (dyld symbol not found on macOS 13.x — libc++ symbol mismatch, closed as "not planned")

In each case the native binary's minimum macOS SDK target moved to 13.0+, breaking on systems below that line. This report is for the desktop app's bundled helper specifically (not the standalone npm CLI), on hardware that is permanently capped at Monterey and can never update past 12.7.6.

Requesting either: restoring macOS 12 compatibility for this component, or having the auto-updater check OS compatibility before pushing an incompatible build (as previously requested in #50456).