[BUG] `claude rc` on the home directory: accepting the trust dialog never persists (`hasTrustDialogAccepted` stays false), trust loops forever

Status Fixed / completed

Reported on v2.1.210

Maintainer reply ✓ Yes — bcherny

Activity 3 comments · opened Jul 15, 2026 · closed Aug 17, 2026

💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

What happened

When I try to start claude rc for my home directory (/home/spe), it tells me I need to accept the workspace trust dialog. I accept the dialog, but nothing changes: it still refuses and keeps asking me to accept the trust dialog. I can never get past it for the home directory.

Trust works fine for other (non-home) directories: accepting the dialog there persists and claude rc works.

Expected

Accepting the trust dialog for the home directory should persist and let claude rc start, or if trusting the home directory as a workspace root is intentionally disallowed, the error should say so clearly instead of repeatedly showing a trust dialog that has no effect.

Actual

The trust dialog reappears every time. Accepting it does not persist. Inspecting ~/.claude.json, the home directory entry stays at hasTrustDialogAccepted: false no matter how many times I accept:

"/home/spe": {
  "hasTrustDialogAccepted": false,
  "hasCompletedProjectOnboarding": null,
  "hasClaudeMdExternalIncludesApproved": false
}

For contrast, other directories in the same ~/.claude.json show hasTrustDialogAccepted: true and work as expected. In my file, 8 entries are true and 16 are false; the home directory is one of the ones stuck at false even after accepting.

Steps to reproduce

cd ~ (home directory).
Run claude rc.
It asks to accept the workspace trust dialog. Accept it.
claude rc still refuses and asks to accept the trust dialog again.
Check ~/.claude.json: the home directory entry is still hasTrustDialogAccepted: false.

Notes

This may be related to #70501 (trust flag reverts to false despite accepting the dialog), but that report is on Windows. Mine is on Linux/WSL2 and appears specific to the home directory.
Possibly the home directory is being special-cased (many tools refuse to treat $HOME as a workspace root). If so, the messaging should reflect that rather than looping on an ineffective trust dialog.

Environment

Claude Code version: 2.1.210
OS: Linux (WSL2, 6.18.33.1-microsoft-standard-WSL2)
Shell: bash
Directory: /home/spe (user home)

View original on GitHub ↗

3 Comments

xg-gh-25 · 3 months ago

We reproduced this on Linux (non-WSL, Ubuntu 22.04) — same symptom: accepting the trust dialog for ~ never persists, hasTrustDialogAccepted stays false in ~/.claude.json, and claude rc loops forever asking to accept.

Pattern we observed across all stuck-at-false entries in our .claude.json: they're all either /home/user itself OR directories with symlinks in their resolved path (e.g., /home/user/workspace → /mnt/nvme/workspace).

Non-home, non-symlinked directories (/tmp/test-project) accepted and persisted immediately.

Hypothesis: The trust persistence logic may be comparing the path BEFORE and AFTER resolution (e.g., user passed ~ but the trust check resolved it to /home/spe, or vice versa), and the mismatch causes the write to miss or be rejected.

Debugging suggestions:

Check path normalization in the trust dialog handler. If the dialog accepts one form (e.g., ~ or a symlink) but the persistence layer expects the fully resolved path, the write will target the wrong key.

Inspect the trust write call. Add logging around the code that updates ~/.claude.json to see what path key it's trying to write and whether the write succeeds or silently fails (permissions, JSON corruption, write-after-read race, etc.).

Check for a hardcoded exclusion list. If the home directory is intentionally blocked (many tools do this — e.g., VS Code warns about trusting ~), the error message should reflect that instead of showing an ineffective dialog.

Quick test to isolate symlink vs. home-directory cause:

# Test 1: Non-home, non-symlink (should work)
mkdir -p /tmp/test-project && cd /tmp/test-project && claude rc

# Test 2: Non-home, WITH symlink (likely fails)
mkdir -p /tmp/real-dir && ln -s /tmp/real-dir /tmp/symlink-dir
cd /tmp/symlink-dir && claude rc

# Test 3: Home directory (known to fail)
cd ~ && claude rc

If Test 2 also loops, the bug is symlink-related (path normalization mismatch). If only Test 3 fails, it's specific to the home directory.

User impact: This blocks claude rc for any dev whose projects live under ~ (which is most Linux users). The workaround — moving projects outside ~ — is not discoverable from the error loop.

If the home directory is intentionally blocked, the dialog should say so upfront: "claude rc cannot run in your home directory. Navigate to a project subdirectory and try again." If it's a bug, the path normalization fix should be straightforward (canonicalize the path ONCE before both the trust check and the persistence write, and use the canonicalized form as the key).

Let me know if you need a traced repro (strace/logs showing the file write succeeding or failing).
---
We've debugged trust-persistence bugs on Linux for long-running daemon sessions. SwarmAI. Discussion: T-MEM

bcherny collaborator · 1 month ago

Thanks for the detailed report — tested this on 2.1.233 (Linux, tmux).

Two things are going on:

hasTrustDialogAccepted staying false for your home directory is intentional. For security, Claude Code never saves workspace trust for $HOME itself — accepting the dialog there grants trust for that session only. I confirmed on 2.1.233 that a subdirectory persists trust normally while the home directory does not; that part is by design and not changing.
The real bug — claude rc telling you to accept a dialog whose acceptance can never persist, looping forever — was fixed in 2.1.214. Running claude rc from the home directory now explains that home-directory trust is never saved and suggests running it from a project directory instead. See the changelog.

Closing as fixed — if you still see the loop on 2.1.214 or later, reply here and we'll reopen.

🤖 Generated with Claude Code

github-actions[bot] · 8 days ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.