[BUG] Claude Desktop freezes (spinning pinwheel) on Code tab and mic permission prompt on macOS 26.5.2 — reproduces in brand-new macOS user account

Status Open
Reported on v2.1.228
Maintainer reply None cached
Activity 3 comments · opened Aug 20, 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?

What's Wrong?

Claude Desktop becomes completely unresponsive (spinning rainbow pinwheel, nothing clickable, must force quit) whenever the Code tab opens or when the app attempts to show the macOS microphone permission prompt. Because the app relaunches into the Code tab from the last session, it now freezes immediately on launch and regular chat is unreachable.

The freeze reproduces in a brand-new macOS user account on the same machine, so it is not caused by my user account's local state.

The Claude Code CLI works perfectly in Terminal on the same machine and account (claude doctor reports "No installation issues found").

Environment

  • macOS: 26.5.2 (build 25F84)
  • Mac: MacBook Pro (MacBookPro17,1), Apple M1, 16GB RAM
  • Free disk space: ~141GB
  • Claude account: Pro
  • Claude Code CLI: v2.1.228 (working normally in Terminal)
  • No antivirus, VPN, or endpoint security software installed

Steps to Reproduce

  1. Launch Claude Desktop.
  2. Open the Code tab (or, previously, click the microphone button in a chat, which triggers the macOS mic permission request).
  3. App shows the spinning pinwheel, entire UI becomes unresponsive, force quit required.
  4. Reproduces 100% of the time.

Troubleshooting Already Performed (none resolved it)

  1. Restarted the Mac.
  2. Force quit and relaunched repeatedly.
  3. Fully removed and reinstalled Claude Desktop from a fresh installer.
  4. Reset app data: renamed ~/Library/Application Support/Claude and let the app create a fresh folder. Still freezes.
  5. Renamed ~/.claude and ~/.claude.json (CLI config) to rule out shared-state conflict with the CLI. Still freezes.
  6. Checked for ~/Library/Application Support/Claude/vm_bundles to clear the VM bundle: the folder does not exist, suggesting the app hangs before VM bundle creation.
  7. Created a brand-new macOS user account (Standard), launched Claude Desktop there with no dev tools or config: freezes identically in the fresh account.
  8. Ran tccutil reset Microphone com.anthropic.claudefordesktop (succeeded). Clicking the mic button then froze the app before the macOS permission prompt appeared; Claude never appears in System Settings > Privacy & Security > Microphone, so macOS never receives the request.

Logs

~/Library/Logs/Claude/main.log shows a clean startup with no errors: blocklist fetch, growthbook, SkillsPlugin (6 skills), remote-tools-device DO bridge connect, then logging simply stops at the moment of the freeze. Notable line: [download:1] Resuming: 10163678/62204737 bytes already on disk. Two [warn] Blocked permission check { permission: 'background-sync' ... } entries appear but are present on every launch.

Happy to attach full logs or a process sample from Activity Monitor on request.

What Should Happen

Code tab should open (or fail gracefully) without deadlocking the whole app, and the mic button should trigger the macOS permission prompt without freezing.

Possibly Related Issues

#53689 (closed as not planned, matches closely), #32225, #47644, #50627, #26087, #23830

What Should Happen?

Claude Desktop should open the Code tab (or fail gracefully with an error) without deadlocking the entire app, and clicking the mic button should show the macOS microphone permission prompt without freezing. Regular chat should remain usable.

Error Messages/Logs

~/Library/Logs/Claude/main.log shows a clean startup with no errors, then logging simply stops at the moment of the freeze. Notable line: [download:1] Resuming: 10163678/62204737 bytes already on disk. Claude never appears in System Settings > Privacy & Security > Microphone, so macOS never receives the mic permission request before the hang.

Steps to Reproduce

  1. Launch Claude Desktop on macOS 26.5.2 (MacBook Pro M1, 16GB).
  2. Open the Code tab, or click the microphone button in a chat.
  3. App shows the spinning pinwheel, entire UI becomes unresponsive, force quit required.
  4. Reproduces 100% of the time, including in a brand-new macOS user account, after full reinstall, and after resetting all app data.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.228 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

3 Comments

wethecreative · 1 month ago

Resolved when I changed networks; the office network was apparently blocking the component download. The bug is that the app deadlocks with no error or progress indicator when the download stalls.

funajit · 27 days ago

Deadlock in swift_addon.node freezes the app (main thread at 0% CPU)

Related to #88098, #53689, #32169. Reproduces on 2.2553.0, so it is not fixed
in the current version.

Environment

  • Claude Desktop 2.2553.0 (also occurred on 2.110.1; updating did not fix it)
  • macOS 27.2 (build 26B5086k, beta)
  • MacBook Air M4, 16 GB RAM
  • Bundled claude-code 2.1.271
  • Usage: Code tab, 22 MCP servers connected (0 failed)

Symptom

The app freezes and requires force quit. Happens repeatedly, several times per hour.

Evidence: the main thread is blocked, not busy

sample taken during an actual freeze. All 3784 samples land on the same frame,
and the process sits at 0.0% CPU — it is waiting, not looping:

PID   STAT  %CPU %MEM ELAPSED
20362 S      0.0  1.8   17:37

Call graph:
    3784 Thread_220024   DispatchQueue_1: com.apple.main-thread  (serial)
    + 3784 completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*)
            (in libswift_Concurrency.dylib) + 1  [0x2b8d67d41]
    +   3784 ???  (in swift_addon.node)  load address 0x161764000 + 0x67fb1
    +     3784 ???  (in swift_addon.node)  load address 0x161764000 + 0xd2959

A Swift async task inside swift_addon.node never completes, deadlocking the main thread.

Possibly related: repeated media permission probes

The log records 442 Media permission probe entries, all returning granted,
for both audio and video. One fires seconds after the captured freeze:

2026-09-17 22:51:12 [info] Media permission probe {
  result: 'granted', via: 'media_access_check', captureKind: 'audio',
  requestingSite: 'claude', requestingOrigin: 'https://claude.ai',

These probes cross the same native Swift bridge where the deadlock occurs. Permissions
are already granted, so this is not a pending-prompt issue — but the sheer number of
probes seems worth checking. ~/Library/Application Support/Claude/vm_bundles does not
exist, matching what #88098 reports.

Ruled out with data

  • Memory: 68% free, swap only residual
  • Crashes: 0 reports in DiagnosticReports (it hangs, never crashes)
  • System hang reports: 0 spin/hang reports
  • GPU: a WebGL2 not supported warning was fixed by clearing GPUCache; freezes continued with 0 WebGL warnings
  • Disk: 74 GB free
  • MCP: init_mcp=connected:22/pending:0/failed:0

Repro

No deterministic trigger found. Occurs during normal use of the Code tab, including
while the app is idle.

funajit · 27 days ago

Second capture: same deadlock, identical offsets

A second freeze, ~11 minutes after the first, lands on exactly the same code path.
Same offsets despite a different module load address, so this is one reproducible
deadlock, not a coincidence:

| | Freeze 1 (22:50) | Freeze 2 (23:01) |
|---|---|---|
| frame 1 | swift_addon.node + 0x67fb1 | swift_addon.node + 0x67fb1 |
| frame 2 | swift_addon.node + 0xd2959 | swift_addon.node + 0xd2959 |
| samples on that frame | 3784 / 3784 | 3018 / 3018 |
| main thread CPU | 0.0% | 0.1% |

Deeper stack from the second capture:

    3018 Thread_245188   DispatchQueue_1: com.apple.main-thread  (serial)
    + 3018 completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*)
            (in libswift_Concurrency.dylib) + 1  [0x2b8d67d41]
    +   3018 ???  (in swift_addon.node)  load address 0x1340fc000 + 0x67fb1
    +     3018 ???  (in swift_addon.node)  load address 0x1340fc000 + 0xd2959
    +       3018 ???  (in swift_addon.node)  load address 0x1340fc000 + 0xdb2a1
    +         3018 ???  (in swift_addon.node)  load address 0x1340fc000 + 0xd94b5
    +           3018 ???  (in swift_addon.node)  load address 0x1340fc000 + 0x6b551
    +             3018 ???  (in swift_addon.node)  load address 0x1340fc000 + 0x6a1d1

Note: while the main thread is blocked, Claude Helper sits at 29.7% CPU — something
is still running on the other side of the await.

Both freezes happened within ~20 minutes of normal use on 2.2553.0, bundled
claude-code 2.1.274.