[BUG] Claude Code unusable on macOS — desktop Trust save fails silently, CLI exits 130 on launch

Resolved 💬 1 comment Opened Apr 22, 2026 by skibum444 Closed May 27, 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?

Claude Code is unusable on my Mac through BOTH entry points. I believe these are two independent bugs that may share a root cause, so I'm filing them together — happy to split into two issues if triage prefers.

Symptom 1 — Desktop app (Code mode): the "Trust this workspace?" dialog fails with "Trust settings couldn't be saved. You can try again." on every attempt, for every folder (local or cloud). The error text appears below the composer. ~/Library/Application Support/Claude/config.json is never updated on disk (last-modified timestamp does not change), so the save attempt never reaches disk. No entries appear in log show matching trust, denied, EACCES, or EPERM for the Claude sender. The app swallows the error silently.

Symptom 2 — Terminal CLI (claude binary): launches, then exits silently with code 130 (SIGINT) before rendering the TUI. I never sent Ctrl+C. claude --version works and prints 2.1.116 (Claude Code), so the binary itself is fine. claude doctor hangs indefinitely. claude --debug produces no output before exiting.

Both failure modes persist after extensive client-side remediation (detailed in "What I've already ruled out" below).

What Should Happen?

Desktop app: Clicking "Trust Workspace" should either (a) persist trust state to ~/Library/Application Support/Claude/config.json and proceed, or (b) surface a specific, actionable error message (e.g. the underlying exception, the file path it failed to write, or a permissions hint).

CLI: Running claude in a trusted workspace should render the TUI and wait for input — not self-terminate with SIGINT before any output is produced.

Error Messages/Logs

$ /Users/todddriver/.nvm/versions/node/v20.20.2/bin/claude
$ echo $?
130

$ claude --version
2.1.116 (Claude Code)

$ claude doctor
# (hangs indefinitely, no output)

$ claude --debug
# (no output, exits 130)

# Desktop app error (appears in UI, not logs):
"Trust settings couldn't be saved. You can try again."

# `log show --predicate 'sender == "Claude"'` during Trust click:
# No entries matching trust|denied|EACCES|EPERM

Steps to Reproduce

Symptom 1 — Desktop app Trust save

  1. Open Claude desktop app → Code mode
  2. Select any local folder (tested: ~/Projects/claude-work) via the folder chip's "Open folder…" option
  3. Type any message in the composer and press Enter
  4. "Trust this workspace?" dialog appears with the correct folder path
  5. Click "Trust Workspace"
  6. Dialog remains; error text appears below the composer: "Trust settings couldn't be saved. You can try again."
  7. ls -la ~/Library/Application\ Support/Claude/config.json — last-modified timestamp does NOT change, confirming the save never reaches disk

Symptom 2 — CLI exits 130

  1. Open Terminal.app
  2. cd ~/Projects/claude-work
  3. /Users/todddriver/.nvm/versions/node/v20.20.2/bin/claude
  4. Process exits immediately; echo $? returns 130 (SIGINT)
  5. No Ctrl+C was sent. claude --version returns 2.1.116 (Claude Code) correctly. claude doctor hangs indefinitely. claude --debug produces no output before exiting.

Backstory

This started when my original Claude Code workspace was inside a Google Drive CloudStorage folder (~/Library/CloudStorage/GoogleDrive-.../My Drive/Claude). Google Drive's cloud sync interfered with trust-state saves (a known failure mode). I have since migrated entirely to a local path and cleaned up all Google Drive references (renamed .claude/ and .claude.json inside the Drive folder to .disabled-gdrive, neutralized stale session files in ~/Library/Application Support/Claude/claude-code-sessions/...). The Google Drive folder is no longer involved, yet both symptoms persist.

What I've already ruled out

  • [x] Google Drive cloud-sync conflict (resolved by moving workspace + disabling old markers)
  • [x] Corrupt ~/.claude.json (restored from backup, valid JSON)
  • [x] Stale session files in ~/Library/Application Support/Claude/claude-code-sessions/ (renamed to .broken-gdrive)
  • [x] Stale .claude/ markers in old Google Drive workspace (renamed to .disabled-gdrive)
  • [x] Missing .claude/settings.local.json in current workspace (manually created with valid JSON {"permissions":{"allow":[],"deny":[]}})
  • [x] macOS Full Disk Access (granted to Claude, node, and Terminal)
  • [x] Filesystem permissions on workspace folder (touch in the target folder succeeds)
  • [x] Node version (v20.20.2 via nvm works to run claude --version)
  • [x] TERM environment variable (xterm-256color does not help)

Hypothesis

The desktop app's Trust save handler is catching an exception and reporting the generic "couldn't be saved" UI without logging. The CLI is receiving SIGINT from somewhere in its own startup path (not from the user) before it can render — possibly an auth/network/file-lock check that's failing and triggering a self-abort. Both bugs may share a root cause (e.g. same config-read path that panics on some state).

Request

  1. Please add more specific error messages to the Trust save failure (currently a dead end for users).
  2. Please investigate why claude CLI can self-SIGINT on startup when --version works fine.
  3. If you need additional diagnostic output from my machine, I'm happy to run any commands you suggest.

Relevant identifiers

  • Anthropic user ID (from ~/.claude.json): 856287b5-7f08-4669-adbc-974953552165
  • Account email: driver.todd@gmail.com

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.116 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Environment details

  • macOS: 26.4.1 (build 25E253)
  • Claude desktop app version: 2.1.116 (Claude Code mode, embedded in desktop app — not a separate CLI install)
  • Node.js: v20.20.2 installed via nvm, claude binary at /Users/todddriver/.nvm/versions/node/v20.20.2/bin/claude
  • Shell: zsh (default macOS)
  • Workspace folder tested: ~/Projects/claude-work (plain local folder, writable, not in any cloud-synced location)

Clarification on "Platform"

I selected "Anthropic API" because I'm signed in with my Anthropic account (driver.todd@gmail.com) — not Bedrock or Vertex. The failures happen before any API call is made, so platform is probably not relevant to these specific symptoms.

Clarification on "Terminal/Shell"

I selected "Terminal.app (macOS)" because that's where I reproduced the CLI exit-130 bug. Symptom 1 (Trust save) occurs in the Claude desktop app, not in a terminal — it's a GUI bug. The Terminal.app selection applies only to Symptom 2.

User context

I'm a non-developer end-user (ophthalmologist). I diagnosed this with help from Claude running in Cowork mode, which is how I'm still able to do AI-assisted work while Claude Code itself is broken on my machine.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗