[Bug] Claude Desktop Code mode unresponsive - no loading indicator after message send

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/28373
2. 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

Same issue here. MacBook Pro 16" M4 Max, 64 GB, macOS Tahoe 26.3.1 (a), Claude Desktop v[your version]. Code tab completely unresponsive — no spinner, no error. Chat and Cowork modes work fine. Claude Code CLI works in Terminal. Tried force quit, clearing ~/Library/Application Support/Claude, and reinstalling. No plugin cache present.

I'm experiencing the same issue on macOS Apple Silicon. Code mode is unresponsive after sending a message — no loading indicator, no response. Chat and Cowork modes work fine. Claude Code binary works fine in Terminal. Tried clearing plugin cache, clearing app cache, updating to latest Desktop app version, and disabling MCP servers — issue persists.

I just updated the app to Version 1.1.8308 (2498e4) and was hoping this would fix but iam experiencing the same issue still.

Additional investigation: Root cause analysis (Desktop App v1.1.8359, macOS)

Same symptom here — Code mode completely unresponsive after message send, Chat/Cowork work fine. Terminal SSH → claude works perfectly. Spent several hours debugging today, here's what I found.

Environment

• Desktop App: 1.1.8359 (latest), also tested 1.1.7714
• Last working version: 1.1.6041
• Bug introduced in: 1.1.6679 (March 13)
• macOS: Multiple Macs (iMac, MacBook Air, Mac Studio) — all affected
• Servers: 3 different VPS instances (Ubuntu 24.04) — all show same behavior
• Plan: Claude Max 20x
• Remote ccd-cli version: 2.1.78

Root cause: LocalSessionManager.checkGitStatus doesn't skip remote paths

The app has two separate code paths for git operations on SSH sessions:

1. getGitDiff / getSSHGitInfo — correctly skips non-local paths:

``
[LocalSessionManager] Skipping git info for non-local path: /root/contract-guardian
[gitDiff] Skipping git diff for non-local path: /root/contract-guardian
``

1. checkGitStatus — does NOT skip and attempts to spawn local git with the remote path as cwd:

``
[LocalSessionManager] Failed to check git status: Failed to spawn /usr/bin/git: spawn /usr/bin/git ENOENT
`
This causes Claude Code process exited with code 1`.

The ENOENT is not about git being missing — it's because Node.js child_process.spawn throws ENOENT when the cwd directory doesn't exist locally. I confirmed this:

subprocess.run(['/usr/bin/git', 'status'], cwd='/root/contract-guardian')
# FileNotFoundError [Errno 2] No such file or directory: '/root/contract-guardian'

Partial workaround attempt: making the remote path exist locally

I used macOS synthetic.conf to create /root locally:

# /etc/synthetic.conf (tab-separated)
root	/Users/nobbie/fake_root

After reboot, /root/contract-guardian exists locally. The spawn /usr/bin/git ENOENT error disappeared from logs, but the session still crashes with Claude Code process exited with code 1 — there is a second failure point.

Additional finding: disclaimer binary issue (March 18 logs)

Older logs show a different error message for the same code path:

Failed to check git status: Failed to spawn git (disclaimer binary not found): 
Failed to spawn /Applications/Claude.app/Contents/Helpers/disclaimer: 
spawn /Applications/Claude.app/Contents/Helpers/disclaimer ENOENT

The disclaimer binary does exist at that path, so this may be an intermittent issue.

Remote ccd-cli works perfectly in isolation

Direct invocation of ccd-cli on the remote server works fine:

printf '{"request_id":"test","type":"control_request","request":{"subtype":"initialize","hooks":{}}}\n{"type":"user","uuid":"test","session_id":"test","message":{"role":"user","content":"hello"}}\n' | /root/.claude/remote/ccd-cli
# Returns normal response

But when spawned by the Desktop App, the remote server log shows 93 bytes written to stderr before exit code 1. The same command works fine when run directly — the difference is the Desktop App's spawn environment.

Desktop App process environment

• PATH: /usr/bin:/bin:/usr/sbin:/sbin (minimal, but git is at /usr/bin/git)
• NOT sandboxed (no com.apple.security.app-sandbox entitlement)
• git works fine with this minimal PATH

Summary

The fix should be straightforward: checkGitStatus (and checkGhAvailable) need to skip execution for SSH remote sessions, just like getGitDiff and getSSHGitInfo already do. This is a regression introduced in v1.1.6679.

Working workaround

Terminal SSH → claude → /remote-control → paste URL into Desktop App Code tab. Works but requires manual SSH + claude startup each time.

I'm having the exact same issue....and after asking Opus to diagnose, it's saying there's a bug, below is its response:

The Code tab in the Claude Desktop app (macOS, Apple Silicon) has been completely non-functional since around March 8. Chat and Cowork tabs work fine. The CLI works fine in Terminal.

Symptom: Messages send but produce no response — no loading indicator, no error, just silence.

Root cause from logs (~/Library/Logs/Claude/claude.ai-web.log):

The app's Content Security Policy is blocking the API endpoint. The log shows:

"Connecting to 'https://a-api.anthropic.com/v1/m' violates the following Content Security Policy directive: connect-src 'self' https://api.segment.io/ https://.segment.io https://.segment.com https://a-cdn.anthropic.com/ https://.google.com https://.facebook.com https://.facebook.net https://.doubleclick.net"

Followed by: "[LOCAL_SESSION] Failed to send message [object Object]"

The CSP connect-src whitelist doesn't include a-api.anthropic.com, so the Code tab's API requests are silently blocked by the browser engine. Chat and Cowork presumably use a different API path that is whitelisted.

Update after app update (v2.1.85 bundled):
The latest app update partially fixed the CSP issue — the main API endpoint is no longer blocked. However, the Code tab still doesn't work. Two new findings:

SDK doesn't handle rate_limit_event — the log shows dozens of [LOCAL_SESSION] unknown sdk message type: rate_limit_event warnings. These aren't actual rate limits (my usage is at 8% session / 4% weekly). The API sends rate limit metadata with every response, but the app's SDK doesn't recognize the message type and drops the response silently.
App fails to launch the bundled Claude Code process — after restarting the app, ps aux | grep claude shows no Claude process running. The log shows [REACT_QUERY_CLIENT] QueryClient error: Error: Not found, confirming the Code tab can't find anything to connect to. However, launching the bundled binary manually from Terminal works perfectly:

~/Library/Application\ Support/Claude/claude-code/2.1.85/claude.app/Contents/MacOS/claude
It connects, authenticates, and is fully functional. So the bug is in the app's process spawning/IPC layer — not the CLI, API, or auth.

UPDATE:
Compared logs with another user on same app version (2.1.87). They have the same CSP errors but zero rate_limit_event warnings and a working Code tab. My account receives rate_limit_event messages that theirs doesn't. Something in my account's API routing or configuration is different.

Update after app update (v2.1.85 bundled): The latest app update partially fixed the CSP issue — the main API endpoint is no longer blocked. However, the Code tab still doesn't work. Two new findings: SDK doesn't handle rate_limit_event — the log shows dozens of [LOCAL_SESSION] unknown sdk message type: rate_limit_event warnings. These aren't actual rate limits (my usage is at 8% session / 4% weekly). The API sends rate limit metadata with every response, but the app's SDK doesn't recognize the message type and drops the response silently. App fails to launch the bundled Claude Code process — after restarting the app, ps aux | grep claude shows no Claude process running. The log shows [REACT_QUERY_CLIENT] QueryClient error: Error: Not found, confirming the Code tab can't find anything to connect to. However, launching the bundled binary manually from Terminal works perfectly: ~/Library/Application\ Support/Claude/claude-code/2.1.85/claude.app/Contents/MacOS/claude It connects, authenticates, and is fully functional. So the bug is in the app's process spawning/IPC layer — not the CLI, API, or auth.

same issue only installed CLI today:

Bug: Claude Code GUI (Code mode in Claude Desktop) fails with exit code 1 when CLI is also installed

Code mode in Claude Desktop is completely non-functional. Every message results in an immediate crash with no response.

Environment

• Claude Desktop bundled Claude Code binary: 2.1.87
• Claude Code CLI (separate install): 2.1.89 at ~/.local/bin/claude
• OS: macOS

What happens

1. Open Code mode in Claude Desktop
2. Select a project folder
3. Type a message and send
4. Occasionally a brief flash of a response appears, then disappears
5. Subsequent messages don't appear in the chat at all

Error in ~/Library/Logs/Claude/main.log

Using Claude Code binary at: .../claude-code/2.1.87/claude.app/Contents/MacOS/claude
[error] Session query error: Claude Code process exited with code 1
[CCD CycleHealth] unhealthy cycle (0s, hadFirstResponse=false, reason=no_response)

Suspected cause
The CLI (2.1.89) and the Desktop app's bundled binary (2.1.87) share the same config files (~/.claude.json and ~/.claude/). The CLI wrote a fresh config in 2.1.89 format, and the older bundled binary appears to be crashing when it reads it. The binary itself responds correctly to --help and --version, so the crash is specific to how the GUI invokes it with session/plugin arguments.

Workaround
Using the CLI directly works fine. Code mode in Claude Desktop does not.

Had this issue for the first time week ago, I managed to resolve the issue only by downgrading to older version, and blocking updates.
Today I made an update again and caused same issue. Only workaround atm is to use CLI.

Version: Claude 1.1617.0 (8d6345)
iOS: 15.7.4 (24G517)

+1 on same issue.

same issue here for over 2 weeks now

Guys there is a fix for this in another thread, it worked for me just make sure you match your version
https://github.com/anthropics/claude-code/issues/36422#issuecomment-4173667922

PaulGlass666
2 weeks ago
Author
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.

This worked for me thanks @IndroLogik

I fixed it.

Pardon, on not giving exact commands.

But i asked Claude app to help with and it asked me to check Console on my Mac. And then i send a message on Claude Code via app, and it showed the error in console.

Paste that into Claude app itself, and it gave few commands to run and then it worked.

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