[BUG] Updating to Claude 1.1.7714 (3bd6f6) causes Claude Code to stop responding to any prompts

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/36362
2. https://github.com/anthropics/claude-code/issues/36419
3. https://github.com/anthropics/claude-code/issues/35032

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

This bug is extra frustrating, since downgrading to 1.1.4088 fixes it--at least there are responses to prompts, but then immediately updates to 1.1.7714 and it's broken again. Arrgh!

Happens on Windows as well.

Same issue on macOS after updating to v1.1.7714.

Chat works fine but Code and Cowork hang indefinitely.
Claude Code CLI unaffected on same machine.

Logs show two relevant errors:

1. Repeated subagent session errors:

[LOCAL_SESSION] Subagent parent not found for user message - possible out of order processing [object Object]

1. Unknown SDK message type:

[LOCAL_SESSION] unknown sdk message type: rate_limit_event

The rate_limit_event error may be the root cause — looks like
the new build doesn't handle this API message type, which then
breaks the subagent session queue.

same exact issue on mac desktop app (i don't have auto update, i just updated manually). macOS 15.7.4

Btw downgrading to previous version, or further doesn't solve the issue.

after update Cowork + rate limit + Pro plan + version 1.1.7714 stop working

Same issue. 1.1.7714 not working on mac os

Did anyone found a way to solve it?

Apparently the solution is to wait for someone at Anthropic to fix it. Perhaps begging would help move this along.

? Bug Fix: Claude Code tab not responding in Desktop App
What happened: The Claude Desktop app stopped responding in the Code tab. Messages would disappear with no response. Everything looked fine — usage limits were OK, Claude Code worked perfectly in Terminal, but the Desktop app was completely dead.
Root cause: The Desktop app bundles its own internal Claude Code binary at: ~/Library/Application Support/Claude/claude-code/2.1.78/claude.app
This internal binary (v2.1.78) became corrupted or outdated and was failing silently with: Claude Code process exited with code 1
The app was using this broken internal binary instead of the working system-installed version at /usr/local/bin/claude.
The fix: Replace the broken internal binary with the working one:
bash
cp /usr/local/bin/claude ~/Library/Application\ Support/Claude/claude-code/2.1.78/claude.app/Contents/MacOS/claude
Note: You need to give Terminal Full Disk Access first in System Settings → Privacy & Security → Full Disk Access, otherwise macOS will block the operation.
Steps if this happens to you:

1. Give Terminal Full Disk Access (System Settings → Privacy & Security → Full Disk Access → + → Terminal)
2. Run the cp command above
3. Restart the Claude Desktop app

Hope this helps someone! ?

Thanks @SBT75. This sounds promising, however it doesn't seem to work for me. A couple of datapoints: there is a new release of Claude Desktop today (1.1.8629). This doesn't fix the issue. (How does this get released if it doesn't work, or am I the only one with the problem?) Copying over the file as you suggest doesn't help: 1) the destination file is actually claude.app, which appears to be different from the terminal version, and 2) as soon as you run Claude Desktop it reinstalls it's copy of claude.app, even if you delete or overwrite it with something else.

So, at least in my case, no progress.

FWIW, today's release, Claude 1.1.8986, does not fix this problem.

Today's release, Claude 1.1.9310, does not fix this problem. Has anyone made this work?

Today's release, Claude 1.1.9493, does not fix this problem. It continues unabated.

Here is some more info on this bug:

Current version works fine on a new Apple-silicon laptop. The system it fails on is a Intel-silicon iMac. I have tried removing all traces of Claude, both CLI and desktop, downloading a fresh copy, and reinstalling on the iMac. This installation also fails as above. Note that a CLI version on this system works (worked) fine.

Perhaps this is related to the Intel-silicon?

Today's release, Claude 1.2.234, does not fix this problem. I wish someone would respond to any contact attempts about this.

I've had Claude (running under vscode) check Claude Desktop to see what's happening (or not). Here is the report:

Root Cause: Bug in Claude Desktop's CCD session launcher since March 28

Timeline:

Before March 28 (binary v2.1.74): Flat binary, sessions worked perfectly
March 28 (binary v2.1.85+): Binary format changed to app bundle (claude.app/Contents/MacOS/claude), every local session has failed since
Two separate but concurrent issues:

Utility Process crash (Utility process exited with code: 1) — Claude Desktop's shell environment extraction is failing on macOS 16 (Darwin 25.4.0), likely a macOS 16 / Electron 40.8.5 compatibility issue. This causes Claude Desktop to fall back to its own minimal environment (PATH=/usr/bin:/bin:/usr/sbin:/sbin).

CCD session failure — Despite the binary working perfectly when invoked directly from any context, Claude Desktop's internal session launcher is failing to get a response from it within 3 seconds. This started exactly when the binary packaging changed from a flat file to an app bundle.

What rules out as causes:

Authentication (keychain has valid token, binary runs fine)
Path/environment (tested with exact Claude Desktop minimal env — works)
Directory or permissions (tested from DMG dir — works)
The binary itself (runs correctly in all tested scenarios)
Likely actual cause: Claude Desktop 1.2.234 has a bug in how it invokes app bundle binaries for local sessions — either in the stdio/pipe setup, the process spawn call, or the SDK initialization handshake specific to that launch context.

Recommended actions:

Check for a Claude Desktop update — go to Claude Desktop menu → Check for Updates. A newer version may fix this.
Report the bug to Anthropic at https://github.com/anthropics/claude-code/issues — include the app version (1.2.234), macOS 16 (Darwin 25.4.0), and that sessions started failing after binary v2.1.85.
Workaround: Use the VSCode extension (v2.1.89, working correctly) for local sessions in the meantime.

I've found a fix (or, Claude Code found a fix):

Found it. The debug log reveals the exact root cause:

pwd: error retrieving current directory: getcwd: cannot access parent directories: Operation not permitted
The cause: macOS TCC (privacy) is blocking com.anthropic.claude-code from reading ~/Documents.

The new binary (2.1.85+) is packaged as an app bundle with its own bundle identifier com.anthropic.claude-code. Unlike the old flat binary (2.1.74) which inherited Claude Desktop's filesystem permissions, this app bundle gets its own TCC context — and it's never been granted access to ~/Documents.

Node.js crashes on startup because process.cwd() calls getcwd() which fails when the working directory is under ~/Documents. Our wrapper script proved this: it ran fine but the same getcwd failure appeared.

Also captured from the log — now we know the exact invocation Claude Desktop uses:

--output-format stream-json --verbose --input-format stream-json --effort medium
--model claude-sonnet-4-6 --permission-prompt-tool stdio --allowedTools mcp__computer-use
--setting-sources user,project,local --permission-mode acceptEdits
--allow-dangerously-skip-permissions --include-partial-messages --plugin-dir ...
There are two fixes:

Fix 1 (Permanent) — Grant Full Disk Access:

Open System Settings → Privacy & Security → Full Disk Access
Click +, press ⌘⇧G, paste this path and hit Go:

~/Library/Application Support/Claude/claude-code/2.1.87/
Select claude.app and add it**
This will persist across future binary updates since macOS tracks by bundle ID (com.anthropic.claude-code).

Fix 2 (Quick test — no System Settings needed) — Try a project outside ~/Documents:

Open a new Claude Desktop local session from a directory that's NOT inside ~/Documents (e.g., ~/Desktop or ~/Downloads). If it works, it confirms TCC is the issue and Fix 1 is all you need.

@PaulGlass666 thanks! Worked for me. Weird because my claude app already had my full disk access, but selecting the specific version like you said worked for me

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