[BUG] hasTrustDialogAccepted reverts to false for previously-trusted, actively-used projects (macOS, 2.1.283)

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?

Summary

hasTrustDialogAccepted in ~/.claude.json reverts to false for
projects that were already trusted and used extensively — not newly
created ones, not ones inheriting trust from a parent (different from
#97048). This re-triggers the workspace trust dialog on --resume, and
in one case caused herdr agent start ... --resume <id> (via the herdr
terminal multiplexer) to fail with agent_not_ready because the resumed
process was blocked on the trust prompt instead of accepting input.

Environment

• Claude Code 2.1.283
• macOS 15.8 (Darwin 24H23), Intel
• Two real occurrences within a 4-day window, different projects

Evidence

Dumped every project entry in ~/.claude.json (27 total) and compared
hasTrustDialogAccepted, lastVersionBase, and lastGracefulShutdown.
Two concrete cases:

Case 1 — project path redacted, ~2026-09-24: hasTrustDialogAccepted
was false despite a full prior session (MCP servers linked and used,
project actively developed). Re-approving MCP servers in the CLI prompt
did not fix it — the flag itself had to be corrected.

Case 2 — project path redacted, lastStartTime: 2026-09-27T09:17:33Z,
lastGracefulShutdown: true, lastCost: $80.57, 912 lines added in that
session (a real, substantial, cleanly-closed session — not an interrupted
one). Despite that, hasTrustDialogAccepted was false the next day,
causing herdr agent start --resume <session-id> to return:

{"error":{"code":"agent_not_ready","message":"agent <name> is blocked
during startup and is not ready for prompts"}}

The underlying pane showed Claude Code's own workspace-trust prompt
("Quick safety check: Is this a project you created or one you trust?"),
confirming the trust dialog had reappeared for a project that was
unambiguously already trusted and worked in.

What we ruled out

• Not a symlink issue — os.path.realpath() on both affected paths

resolves to themselves.

• Not version-specific — multiple other projects at the exact same

lastVersionBase: 2.1.283 have hasTrustDialogAccepted: true. If a
version bump reset the flag, all projects on that version would be
affected equally.

• Not caused by an abrupt/interrupted shutdown — Case 2 has

lastGracefulShutdown: true and a full, completed, costly session
logged after the (presumed) original trust acceptance.

Suspected mechanism

Likely the same class of bug as #92908 (".claude.json is saved behind a
best-effort lock that is abandoned after 15s") — a stale in-memory
snapshot of ~/.claude.json, held by one claude process for the
duration of a long session, gets written back on exit and clobbers a
newer hasTrustDialogAccepted: true that was persisted by another
process in the meantime. #92908 is filed as Windows-specific, but the
lock/write mechanism described there is not obviously OS-specific, and
#97048 (macOS) shows a related trust-persistence inconsistency on this
platform. We suspect this is a third symptom of the same root cause
across platforms, not three unrelated bugs.

Our own tooling launches claude --resume <id> in rapid succession when
reattaching to reused terminal panes, which may make the race easier to
hit than typical interactive use — but the underlying data-loss mechanism
appears to be in Claude Code's own config persistence, not something a
downstream tool should need to work around.

Workaround we shipped

Since we could not find a way to prevent the flag from reverting, we now
proactively re-check and correct hasTrustDialogAccepted for any project
that already has an entry in ~/.claude.json (i.e., has genuinely been
trusted before) immediately before every relaunch/resume. This masks the
symptom but obviously isn't a real fix, since the config file is the
qualified source of truth for a security decision and shouldn't need
external correction.

Related

• #92908 — .claude.json best-effort lock abandoned after 15s
• #97048 — hasTrustDialogAccepted stays false for child folders under a trusted parent
• #97726 — Trust prompt reappears on every launch (home directory)

What Should Happen?

hasTrustDialogAccepted should stay true for a project that has already
been trusted and used in a full, successfully-completed session. It
should not revert to false on its own for a project that already has
an entry in ~/.claude.json from prior real use.

Error Messages/Logs

{"error":{"code":"agent_not_ready","message":"agent <name> is blocked during startup and is not ready for prompts"},"id":"cli:agent:start"}

Steps to Reproduce

This is an intermittent config-persistence bug, not a deterministic
one-shot repro — but here is the exact sequence that triggered it twice:

1. Create/open a project folder with Claude Code, accept the workspace

trust dialog ("Yes, I trust this folder").

1. Work a full, real session in it (in our case: hundreds of lines

changed, tens of dollars of usage), then exit cleanly
(lastGracefulShutdown: true in ~/.claude.json afterward).

1. Some time later (hours to ~1 day), relaunch Claude Code in the SAME

folder with claude --resume <session-id>.

1. Observe: the workspace trust prompt reappears, even though

~/.claude.json already has a full project entry from step 2 — i.e.
hasTrustDialogAccepted has reverted to false on its own between
step 2 and step 3, despite no manual edit and a clean prior exit.

We could not find a way to force this on demand — it happened naturally
twice within 4 days across different projects on the same machine. Full
evidence (27-project comparison ruling out symlinks/version/abrupt-exit
as causes) is in the issue body under "What's Wrong?".

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.283

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

_No response_