claude-code - 💡(How to fix) Fix [BUG] Claude Code unusable on macOS — desktop Trust save fails silently, CLI exits 130 on launch [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#51834Fetched 2026-04-23 07:43:43
View on GitHub
Comments
0
Participants
1
Timeline
6
Reactions
0
Author
Participants
Timeline (top)
labeled ×5cross-referenced ×1

Error Message

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. 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).

Error Messages/Logs

Desktop app error (appears in UI, not logs):

  1. Dialog remains; error text appears below the composer: "Trust settings couldn't be saved. You can try again." 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).
  2. Please add more specific error messages to the Trust save failure (currently a dead end for users).

Root Cause

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.

Fix Action

Fix / Workaround

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

Code Example

$ /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
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • 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

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

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 ([email protected]) — 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.

extent analysis

TL;DR

The most likely fix or workaround involves investigating and resolving the underlying issue causing the "Trust settings couldn't be saved" error in the desktop app and the SIGINT exit in the CLI, potentially related to configuration or permission issues.

Guidance

  1. Verify configuration files: Check the ~/.claude.json and ~/Library/Application Support/Claude/config.json files for any corruption or incorrect settings that might be causing the trust save failure.
  2. Check permissions: Ensure that the Claude desktop app and CLI have the necessary permissions to write to the ~/Library/Application Support/Claude/ directory and the workspace folder.
  3. Run diagnostic commands: Run claude doctor and claude --debug with increased verbosity to gather more information about the errors occurring during startup and trust save attempts.
  4. Test with a clean configuration: Try resetting the Claude configuration to its default state by removing the ~/.claude.json and ~/Library/Application Support/Claude/ directory, then reconfigure the app and CLI to see if the issues persist.

Example

No specific code snippet is provided as the issue seems to be related to configuration and permissions rather than code.

Notes

The exact cause of the issue is unclear, and further investigation is needed to determine the root cause. The provided information suggests that the issue may be related to configuration or permission issues, but more diagnostic output is required to confirm this.

Recommendation

Apply a workaround by resetting the Claude configuration to its default state and reconfiguring the app and CLI, as this may resolve any configuration-related issues causing the errors.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Claude Code unusable on macOS — desktop Trust save fails silently, CLI exits 130 on launch [1 participants]