[BUG] Claude Code Homebrew cask hangs on startup on macOS 26.3 (arm64)

Status Closed — not planned
Reported on v2.1.49
Maintainer reply None cached
Activity 13 comments · opened Feb 20, 2026 · closed Jun 5, 2026

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?

Environment:

  • claude-code 2.1.49 (Homebrew cask)
  • macOS 26.3 (25D125)
  • Apple Silicon (arm64)

Description:
Claude Code hangs on startup — all commands including claude --version hang indefinitely. The binary never reaches main().

Debugging performed:

  • Reinstalling via brew reinstall claude-code doesn't help
  • Removing ~/.claude doesn't help
  • Removing quarantine xattrs doesn't help
  • lsof shows no open files/sockets beyond stdin/stdout/stderr
  • sample shows the process stuck in _dyld_start (dyld) — the dynamic linker never finishes

Sample output:
Call graph:
7808 Thread_82181: Main Thread
7808 _dyld_start (in dyld) + 0 [0x10ddfc9c0]

Linked libraries (all system):
/usr/lib/libicucore.A.dylib
/usr/lib/libresolv.9.dylib
/usr/lib/libc++.1.dylib
/usr/lib/libSystem.B.dylib

Workaround:
Installing via npm (npm install -g @anthropic-ai/claude-code) works.

What Should Happen?

Claude Code should not hang on startup

Error Messages/Logs

Steps to Reproduce

  1. Install claude-code via Homebrew on MacOS 26.3: brew install --cask claude-code
  2. Run any command: claude --version
  3. The process hangs indefinitely — no output, no crash, requires manual kill

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.49

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

12 Comments

github-actions[bot] · 6 months ago

Found 2 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/24324
  2. https://github.com/anthropics/claude-code/issues/20407

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

boinger · 6 months ago

I think I'm having a similar issue.

macOS 26.4 beta (25E5218f)
native installer v2.1.58
Apple M4 Max

Interactive mode takes ~60-120 minutes (!!) to start. It does eventually succeed -- the tcsetattr call isn't hanging forever, it's blocking for an extremely long time. claude --print also eventually returns after ~2 hours. claude doctor and claude --version work normally (presumably don't enter raw mode).

sample below shows the main thread blocked on:

tcsetattr  (in libsystem_c.dylib) + 172
  ioctl  (in libsystem_kernel.dylib) + 36
    __ioctl  (in libsystem_kernel.dylib) + 8

This is likely tcsetattr(TCSADRAIN) which blocks until pending terminal output drains. macOS 26.4 appears to have a regression where this drain takes 60-120 minutes.

What I've ruled out:

  • Not terminal-specific; reproduces in Terminal.app, Kitty, and SSH to localhost (completely different PTY)
  • Not network; API is reachable, --print mode works (slowly)
  • Not conversation-specific; hangs on fresh claude with no flags, --continue, --resume, any directory
  • stty sane, TERM=dumb, CLAUDE_CODE_SIMPLE=1, CLAUDE_CODE_SKIP_UPDATE_CHECK=1 all exhibit the same delay
  • Reboot didn't help
  • Older native binaries (2.1.53, 2.1.55, 2.1.56) same behavior

Potential fix: Could Claude Code use TCSANOW instead of TCSADRAIN for raw mode setup? TCSANOW applies changes immediately without waiting for output to drain. The drain behavior is clearly broken on macOS 26.4 beta.
Workaround: Waiting ~60-120 minutes for startup to complete.

Note: once interactive mode actually starts, the TUI is fully functional with no further delays or issues. This is consistent with TCSADRAIN blocking on a spurious pending-output condition that eventually resolves, after which the terminal settings are applied correctly.

Also notable: libRosetta.dylib is loaded in the binary images, which is unusual for a native ARM64 process. This may indicate the binary is running under Rosetta translation, or that Rosetta is loaded as a dependency. Either way, it's a potentially relevant difference from the npm-installed path which runs under native ARM node.

<details>
<summary>Full sample trace</summary>

Sampling process 67598 for 3 seconds with 1 millisecond of run time between samples
Sampling completed, processing symbols...
Sample analysis of process 67598 written to file /tmp/claude_2026-02-25_140014_kLPj.sample.txt

Analysis of sampling claude (pid 67598) every 1 millisecond
Process: 2.1.58 [67598]
Path: /Users/USER/*/2.1.58
Load Address: 0x104810000
Identifier: 2.1.58
Version: 0
Code Type: ARM64
Platform: macOS
Parent Process: bash [66832]
Target Type: live task

Date/Time: 2026-02-25 14:00:14.043 -0800
Launch Time: 2026-02-25 13:59:50.166 -0800
OS Version: macOS 26.4 (25E5218f)
Report Version: 7
Analysis Tool: /usr/bin/sample

Physical footprint: 53.2M
Physical footprint (peak): 53.2M
Idle exit: untracked
----

Call graph:
2521 Thread_663793 DispatchQueue_1: com.apple.main-thread (serial)

  • 2521 start (in dyld) + 6992 [0x18cd9bda4]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x560d78 [0x104d70d78]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x564aa0 [0x104d74aa0]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x36ac8 [0x104846ac8]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x833f8c [0x105043f8c]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x89bba0 [0x1050abba0]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x8a0dd0 [0x1050b0dd0]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x436634 [0x104c46634]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x2779420 [0x106f89420]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x1af414 [0x1049bf414]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x27793c4 [0x106f893c4]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x2544f50 [0x106d54f50]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x2f7b9b8 [0x10778b9b8]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x2fa3dbc [0x1077b3dbc]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x2fa3dbc [0x1077b3dbc]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x2fa2884 [0x1077b2884]
  • 2521 ??? (in <unknown binary>) [0x120c6403c]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x2784a4 [0x104a884a4]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x42632c [0x104c3632c]
  • 2521 tcsetattr (in libsystem_c.dylib) + 172 [0x18d017cfc]
  • 2521 ioctl (in libsystem_kernel.dylib) + 36 [0x18d118324]
  • 2521 __ioctl (in libsystem_kernel.dylib) + 8 [0x18d118338]

2521 Thread_663794: JavaScriptCore libpas scavenger

  • 2521 thread_start (in libsystem_pthread.dylib) + 8 [0x18d152c1c]
  • 2521 _pthread_start (in libsystem_pthread.dylib) + 136 [0x18d157c58]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x2bd72f4 [0x1073e72f4]
  • 2521 _pthread_cond_wait (in libsystem_pthread.dylib) + 980 [0x18d158128]
  • 2521 __psynch_cvwait (in libsystem_kernel.dylib) + 8 [0x18d11750c]

2521 Thread_663795: Heap Helper Thread

  • 2521 thread_start (in libsystem_pthread.dylib) + 8 [0x18d152c1c]
  • 2521 _pthread_start (in libsystem_pthread.dylib) + 136 [0x18d157c58]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x17f20d8 [0x1060020d8]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x17a5b44 [0x105fb5b44]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x1766bac [0x105f76bac]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x1781268 [0x105f91268]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x17f2794 [0x106002794]
  • 2521 _pthread_cond_wait (in libsystem_pthread.dylib) + 980 [0x18d158128]
  • 2521 __psynch_cvwait (in libsystem_kernel.dylib) + 8 [0x18d11750c]

2521 Thread_663796: Heap Helper Thread

  • 2521 thread_start (in libsystem_pthread.dylib) + 8 [0x18d152c1c]
  • 2521 _pthread_start (in libsystem_pthread.dylib) + 136 [0x18d157c58]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x17f20d8 [0x1060020d8]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x17a5b44 [0x105fb5b44]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x1766bac [0x105f76bac]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x1781268 [0x105f91268]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x17f2794 [0x106002794]
  • 2521 _pthread_cond_wait (in libsystem_pthread.dylib) + 980 [0x18d158128]
  • 2521 __psynch_cvwait (in libsystem_kernel.dylib) + 8 [0x18d11750c]

2521 Thread_663797: Heap Helper Thread

  • 2521 thread_start (in libsystem_pthread.dylib) + 8 [0x18d152c1c]
  • 2521 _pthread_start (in libsystem_pthread.dylib) + 136 [0x18d157c58]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x17f20d8 [0x1060020d8]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x17a5b44 [0x105fb5b44]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x1766bac [0x105f76bac]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x1781268 [0x105f91268]
  • 2521 ??? (in 2.1.58) load address 0x104810000 + 0x17f2794 [0x106002794]
  • 2521 _pthread_cond_wait (in libsystem_pthread.dylib) + 980 [0x18d158128]
  • 2521 __psynch_cvwait (in libsystem_kernel.dylib) + 8 [0x18d11750c]

2521 Thread_663798: JIT Worklist Helper Thread
2521 thread_start (in libsystem_pthread.dylib) + 8 [0x18d152c1c]
2521 _pthread_start (in libsystem_pthread.dylib) + 136 [0x18d157c58]
2521 ??? (in 2.1.58) load address 0x104810000 + 0x17f20d8 [0x1060020d8]
2521 ??? (in 2.1.58) load address 0x104810000 + 0x17a5b44 [0x105fb5b44]
2521 ??? (in 2.1.58) load address 0x104810000 + 0x1766bac [0x105f76bac]
2521 ??? (in 2.1.58) load address 0x104810000 + 0x1781268 [0x105f91268]
2521 ??? (in 2.1.58) load address 0x104810000 + 0x17f2794 [0x106002794]
2521 _pthread_cond_wait (in libsystem_pthread.dylib) + 980 [0x18d158128]
2521 __psynch_cvwait (in libsystem_kernel.dylib) + 8 [0x18d11750c]

Total number in stack (recursive counted multiple, when >=5):
5 __psynch_cvwait (in libsystem_kernel.dylib) + 0 [0x18d117504]
5 _pthread_cond_wait (in libsystem_pthread.dylib) + 980 [0x18d158128]
5 _pthread_start (in libsystem_pthread.dylib) + 136 [0x18d157c58]
5 thread_start (in libsystem_pthread.dylib) + 8 [0x18d152c1c]

Sort by top of stack, same collapsed (when >= 5):
__psynch_cvwait (in libsystem_kernel.dylib) 12605
__ioctl (in libsystem_kernel.dylib) 2521

Binary Images:
0x104810000 - 0x10800d2b3 +2.1.58 (0) <5A999DFB-FE2B-39F4-A07B-DCEAD65A4E37> /Users/*/2.1.58
0x18ccf4000 - 0x18cd46b7b libobjc.A.dylib (951.6) <3965C785-7F37-3648-8640-38C0CF47DE88> /usr/lib/libobjc.A.dylib
0x18cd47000 - 0x18cd7bb34 libdyld.dylib (1376.6) <03FC95BE-DB5E-3E55-ADC5-43321839B499> /usr/lib/system/libdyld.dylib
0x18cd7c000 - 0x18ce21ecb dyld (1.0.0 - 1376.6) <765DE06E-47F3-39D7-8820-FB7F64CBBFD8> /usr/lib/dyld
0x18ce22000 - 0x18ce25228 libsystem_blocks.dylib (96) <FEACC835-DA51-3E36-8E25-1A776E8D1AD1> /usr/lib/system/libsystem_blocks.dylib
0x18ce26000 - 0x18ce7a51f libxpc.dylib (3102.100.101.501.1) <68F37C82-19B7-3F67-85A1-F47D397FEEE3> /usr/lib/system/libxpc.dylib
0x18ce7b000 - 0x18ce9b9bf libsystem_trace.dylib (1861.100.19) <13F8829D-B377-38DF-9EC1-04BFFB8434B3> /usr/lib/system/libsystem_trace.dylib
0x18ce9c000 - 0x18cf49d8f libcorecrypto.dylib (1922.100.99) <B5E315EC-02D2-3D66-9148-551DF7228B2C> /usr/lib/system/libcorecrypto.dylib
0x18cf4a000 - 0x18cf9a1d7 libsystem_malloc.dylib (812.100.30) <704A3EA7-FED2-3CF8-B1A8-7BE2B46B8588> /usr/lib/system/libsystem_malloc.dylib
0x18cf9b000 - 0x18cfe223f libdispatch.dylib (1542.100.32) <A8CAB0C9-1FA2-3BB6-A4B2-F6093743CF08> /usr/lib/system/libdispatch.dylib
0x18cfe3000 - 0x18cfe5ffb libsystem_featureflags.dylib (103) <8312EE4D-10AE-3630-906F-EEF505439A91> /usr/lib/system/libsystem_featureflags.dylib
0x18cfe6000 - 0x18d066ef7 libsystem_c.dylib (1752.100.10) <F3C70EC5-99FB-3F94-9534-017F06ABA58A> /usr/lib/system/libsystem_c.dylib
0x18d067000 - 0x18d0f7ae7 libc++.1.dylib (2100.41) <6F16BEA8-C576-37C7-B0D0-2B4D6EA19564> /usr/lib/libc++.1.dylib
0x18d0f8000 - 0x18d11275f libc++abi.dylib (2100.41) <848625ED-FA18-3002-ABF3-1BFF7D715788> /usr/lib/libc++abi.dylib
0x18d113000 - 0x18d15029f libsystem_kernel.dylib (12377.100.625.0.3) <25C6C5E3-C70D-341A-A241-1400EB496308> /usr/lib/system/libsystem_kernel.dylib
0x18d151000 - 0x18d15db3b libsystem_pthread.dylib (539.100.3) <A77F77F9-9B4E-3646-BDDD-5213A08F3AA7> /usr/lib/system/libsystem_pthread.dylib
0x18d15e000 - 0x18d1668f3 libsystem_platform.dylib (375.100.10) <B61AB5EF-9716-3BF9-B467-BE014C4FEA41> /usr/lib/system/libsystem_platform.dylib
0x18d167000 - 0x18d1966eb libsystem_info.dylib (600) <41845494-D88D-35D1-B20C-6E3A70B5DA72> /usr/lib/system/libsystem_info.dylib
0x190e51000 - 0x191126d33 libicucore.A.dylib (76142.4.6) <30CB7AC3-08A5-3714-AA4F-5C594DF91094> /usr/lib/libicucore.A.dylib
0x191127000 - 0x191130e5f libsystem_darwin.dylib (1752.100.10) <00B4FAEA-85C8-3FDA-A444-CFCD1FE8F64A> /usr/lib/system/libsystem_darwin.dylib
0x191592000 - 0x1915a3f5b libsystem_notify.dylib (348.100.7) <729640B6-C7E2-3759-9A20-B10926755EEA> /usr/lib/system/libsystem_notify.dylib
0x193856000 - 0x193870f5b libsystem_networkextension.dylib (2226.100.30.0.1) <AA06936A-6058-3578-83DE-7AF527A8C401> /usr/lib/system/libsystem_networkextension.dylib
0x1938f3000 - 0x19390afdf libsystem_asl.dylib (406) <EA0B2295-9D22-3370-9604-B2658D7C7E11> /usr/lib/system/libsystem_asl.dylib
0x19548d000 - 0x195495387 libsystem_symptoms.dylib (2169.100.30) <62A9DAC6-36F8-3612-9C32-8F42CC8FB8F7> /usr/lib/system/libsystem_symptoms.dylib
0x199705000 - 0x19973d25f libsystem_containermanager.dylib (725.100.37) <A383FFAE-8657-3E61-A318-9374258888A6> /usr/lib/system/libsystem_containermanager.dylib
0x19ac1b000 - 0x19ac1f5d7 libsystem_configuration.dylib (1405.100.8) <4D016EF1-8CA7-3F8E-AF91-71A0588155EA> /usr/lib/system/libsystem_configuration.dylib
0x19ac20000 - 0x19ac266b7 libsystem_sandbox.dylib (2680.100.170.0.1) <9E3100A2-8D5D-344F-8B75-0643EA0DA826> /usr/lib/system/libsystem_sandbox.dylib
0x19c248000 - 0x19c24b1fb libquarantine.dylib (196.100.8) <67DA2D5B-0CDA-352C-8036-9543D4EE678C> /usr/lib/system/libquarantine.dylib
0x19c9e7000 - 0x19c9edd03 libsystem_coreservices.dylib (191.4.5) <9B12AB5F-95B8-3AE1-9B08-6202E749D54E> /usr/lib/system/libsystem_coreservices.dylib
0x19cf6b000 - 0x19cfa8a77 libsystem_m.dylib (3312.100.1) <9BDFC8A3-C6C9-3E0E-9CF4-0D439BDA4391> /usr/lib/system/libsystem_m.dylib
0x19cfaa000 - 0x19cfad527 libmacho.dylib (1376.6) <4F655C67-1BE4-365E-BBDE-095F43F95E61> /usr/lib/system/libmacho.dylib
0x19cfc7000 - 0x19cfd43a7 libcommonCrypto.dylib (600035) <1D431E4B-AA2A-31B0-A1CE-38C2569D3CEC> /usr/lib/system/libcommonCrypto.dylib
0x19cfd5000 - 0x19cfdeca3 libunwind.dylib (2100.2) <83E59FA7-229B-31D8-A557-4C4EADB28BB3> /usr/lib/system/libunwind.dylib
0x19cfe7000 - 0x19cff17ff libcopyfile.dylib (240) <A0A8817C-ED2C-32AA-A2D2-BC9F7010348F> /usr/lib/system/libcopyfile.dylib
0x19cff2000 - 0x19cff5987 libcompiler_rt.dylib (103.3) <B5D927F9-EF03-3EF5-AE95-FD45D5D188B8> /usr/lib/system/libcompiler_rt.dylib
0x19cff6000 - 0x19cffa78b libsystem_collections.dylib (1752.100.10) <97C288BD-C9E7-3894-9139-EF4BF1A0D524> /usr/lib/system/libsystem_collections.dylib
0x19cffb000 - 0x19cffe4cf libsystem_secinit.dylib (168.100.7) <AA373207-7909-302D-A533-5F09007B4A7D> /usr/lib/system/libsystem_secinit.dylib
0x19cfff000 - 0x19d001bf7 libremovefile.dylib (85.100.6) <B3617CD1-39CC-3F3A-98D0-D7DBD218E65F> /usr/lib/system/libremovefile.dylib
0x19d002000 - 0x19d002f27 libkeymgr.dylib (31) <E7FBCEDC-5623-316F-8415-D77CA8574D65> /usr/lib/system/libkeymgr.dylib
0x19d003000 - 0x19d00be37 libsystem_dnssd.dylib (2881.100.56) <980410F1-D9A4-3C07-9BB9-D23CAEF460A7> /usr/lib/system/libsystem_dnssd.dylib
0x19d00c000 - 0x19d01109b libcache.dylib (95) <36919663-9EBE-3DBA-A2F0-6DB84CA06A5B> /usr/lib/system/libcache.dylib
0x19d012000 - 0x19d013ce3 libSystem.B.dylib (1356) <FC4CD02F-B695-3CC5-9D3B-33AF3874B4C8> /usr/lib/libSystem.B.dylib
0x1a19b9000 - 0x1a19d519b libresolv.9.dylib (96) <34594853-36AD-39A8-98B0-6DE050F7BFDA> /usr/lib/libresolv.9.dylib
0x291535000 - 0x29153c339 libRosetta.dylib (367.3) <6E193869-6FB3-3F40-80A7-03CE734C57D8> /usr/lib/libRosetta.dylib
0x293243000 - 0x293246a4b libsystem_darwindirectory.dylib (122) <F200265D-E2DB-316B-B601-5E3CADCD2C54> /usr/lib/system/libsystem_darwindirectory.dylib
0x293247000 - 0x2932505a7 libsystem_eligibility.dylib (319.100.56) <69E31851-E836-31F2-B663-D9C45CBA1F50> /usr/lib/system/libsystem_eligibility.dylib
0x293251000 - 0x2932588db libsystem_sanitizers.dylib (26) <1210864E-8162-37B1-913B-557302EBE9B7> /usr/lib/system/libsystem_sanitizers.dylib
0x293259000 - 0x293259bb7 libsystem_trial.dylib (474.2.17) <244862C7-F3DD-38FD-8C2C-89421BE7870E> /usr/lib/system/libsystem_trial.dylib

</details>

stevenschlansker · 6 months ago

I think the original report and the tcsetattr problem might be different problems with the same symptom.
The stack traces are not the same: the OP reports hanging in dyld, before main is ever reached, which I think would preclude any calls to tcsetattr under programmer control. (unless it's dyld doing the tcsetattr?)

I think this issue also is broader than Claude - I have reproduced what could be the exact same hang using both Redis server as well as Apache Maven. I strongly suspect this is a Mac OS bug. The stack in my case looks like:

 Thread 0x36077    1001 samples (1-1001)    priority 31 (base 31)    last ran 772.170s ago
  1001  _dyld_start + 0 (dyld + 18880) [0x1052e49c0]
   *1001  ??? (kernel.release.t6031 + 17036) [0xfffffe000887828c]
     *1001  ??? (kernel.release.t6031 + 662900) [0xfffffe0008915d74]
       *1001  ??? (kernel.release.t6031 + 9732120) [0xfffffe00091bc018]
         *1001  AppleSystemPolicy::procNotifyExecComplete(proc*) + 3740 (AppleSystemPolicy + 37628) [0xfffffe000a4ae8fc]
           *1001  AppleSystemPolicy::waitForEvaluation(syspolicyd_evaluation*, int, ASPEvaluationInfo*, vnode**, evaluation_results*, long long*, char const*) + 88 (AppleSystemPolicy + 27824) [0xfffffe000a4ac2b0]
             *1001  ASPEvaluationManager::waitOnEvaluation(syspolicyd_evaluation*) + 56 (AppleSystemPolicy + 14100) [0xfffffe000a4a8d14]
               *1001  lck_mtx_sleep + 232 (kernel.release.t6031 + 458712) [0xfffffe00088e3fd8]
                 *1001  ??? (kernel.release.t6031 + 569060) [0xfffffe00088feee4]
                   *1001  ??? (kernel.release.t6031 + 574024) [0xfffffe0008900248]

Is your problem mitigated (temporarily) by rebooting?
I filed a Feedback request with Apple about 6 months ago on this subject, but no response...

boinger · 6 months ago

Reboot didn't mitigate at all for me -- I tried a few times (blocking suspect things from loading on boot)...nothing helped until I turned off the Radio Silence Network Extension! I'd been running that for years with no issue...Now all is back to normal with Claude.

So....if you're running, like Little Snitch, Radio Silence, etc...try disabling.

But, I agree, seems like MacOS's fault at this point.

jarnesjo · 5 months ago

Same issue on macOS 26.3.1 (25D2128), Apple Silicon ARM64.

The npm workaround (npm install -g @anthropic-ai/claude-code) does not work either on this version — process hangs identically at _dyld_start.

Patslatts · 5 months ago

Same issue on macOS 26.3.1 (25D2128), Mac Mini M4 Pro. Both Homebrew cask and npm install hang identically. Process hangs before any logging initialises. Started after macOS update on 2026-03-11. claude --version works fine but interactive session hangs indefinitely.

jonmaaku-rev · 5 months ago

Any workaround for this bug?

hannoschulz · 4 months ago

Same issue here with native installer. Sometimes the cli starts after a few hours ..

macOS, 26.4.1, BuildVersion: 25E253
2.1.114 (Claude Code)

jonmaaku-rev · 4 months ago

Not sure if this will help anyone, but my issue was authentication related:

When I ran claude command like claude doctor,claude, claude auth; I get no response (it hangs).
But when I ran claude --help and claude -v; they works.

What fixed mine is removing the claude.json, and running claude again

hannoschulz · 4 months ago
Same issue here with native installer. Sometimes the cli starts after a few hours .. macOS, 26.4.1, BuildVersion: 25E253 2.1.114 (Claude Code)

I'm sorry, but it seems my problem was actually caused by something else.
An external tool kept automatically syncing a corrupted and very large CLAUDE.md file. This caused the system to freeze for several hours, unfortunately without any helpful error messages.

joe1chief · 3 months ago

Adding a data point on macOS 26.3.1 (release, not beta): same tcsetattr →
ioctl → __ioctl stack, but the process immediately goes to STAT=T (stopped),
never recovering. Long-running pre-existing sessions remain healthy, only
newly-launched ones are affected. Reported with fuller diagnostic in #57254.

github-actions[bot] · 2 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

Showing cached comments. Read the full discussion on GitHub ↗