[BUG] Windows: project-key migration in ~/.claude.json drops hasTrustDialogAccepted → every side-effectful command prompts despite allowlist

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?

Environment
OS: Windows 11 Pro 10.0.26200
Claude Desktop (Claude Code): version installed via auto-update on 2026-07-01 (Claude 1.17377.2 (e0ea9e) 2026-07-01T05:51:58.000Z)
Model: claude-fable-5 (also reproduced on Opus 4.8 in same project)
Project: a local git repo on an NTFS path (cloud-synced folder, but reproduced independent of that)

Summary
After a Desktop app update, per-project state in ~/.claude.json was re-keyed from BACKSLASH paths (C:\Users\<user>\...\Project) to FORWARD-SLASH paths (C:/Users/<user>/.../Project). The migration did NOT carry hasTrustDialogAccepted to the new key: the new forward-slash entry was created with hasTrustDialogAccepted: false, while the accepted trust lived (orphaned) on the old backslash entry.

An untrusted project apparently forces "This command requires approval" on every SIDE-EFFECTFUL shell command (git add/commit/push, npm run, pytest, formatters, curl, touch...) REGARDLESS of permissions.allow rules in .claude/settings.json or .claude/settings.local.json. Read-only commands (git status/log/diff) continue to honor the allowlist. No trust dialog is ever shown to re-accept.

The result is an extremely confusing failure mode: a fully-correct allowlist that "randomly" works (reads) and doesn't (writes), and "Always allow" clicks that write rules into settings.local.json which then appear to have no effect.

Steps to reproduce
On Windows, have a project with accepted trust and a working permissions.allow list under the pre-update build (project keyed as C:\Users\... in ~/.claude.json).
Update the Desktop app (the build that re-keys projects to C:/Users/...).
Open a session in that project and run an allowlisted side-effectful command, e.g. git push with Bash(git push:) / PowerShell(git push:) in .claude/settings.json permissions.allow.
Expected
Command runs without a permission prompt (allowlist honored), as pre-update.

Actual
Every side-effectful command prompts with "This command requires approval", including commands covered by exact-match allow rules.
"Always allow" appends rules to .claude/settings.local.json, but identical commands keep prompting (behavior consistent with a per-approval cache only).
Read-only commands (git status/log/diff/show) honor the allowlist normally.
No trust dialog is offered anywhere in the UI to re-establish trust.

Diagnosis evidence
~/.claude.json contains BOTH keys for the same project:

"C:\\Users\\<user>\\...\\Project": {
"hasTrustDialogAccepted": true, // legacy entry, no new-build fields
...
},
"C:/Users/<user>/.../Project": {
"hasTrustDialogAccepted": false, // entry the new build actually reads
"hasUnseenTeamArtifacts": false, // new-build-only fields present here
...
}
A second project on the same machine that had its forward-slash entry effectively trusted showed none of the symptoms, which is what isolated the flag.

Workaround (confirmed fix)
Quit Claude Desktop completely.
Edit ~/.claude.json: on the FORWARD-SLASH key of the affected project, set "hasTrustDialogAccepted": true.
Relaunch. All allowlist behavior (both settings files, cmd: and cmd syntaxes, wildcards, bare commands) is restored immediately.

Suggested fixes
Migrate hasTrustDialogAccepted (and other per-project flags) when re-keying project paths, or treat the two separator spellings as the same key on Windows.
If a project is untrusted, SHOW the trust dialog instead of silently degrading to per-command approval - the silent mode is indistinguishable from a broken allowlist matcher and cost us two days of bisecting.
Consider surfacing "this project is untrusted" in the permission prompt itself.

Impact
All Windows users whose projects were re-keyed by the update lose allowlist functionality for write commands with no visible cause and no UI path to recover; "Always allow" appears broken, which trains users toward blanket bypass modes.

What Should Happen?

No endless allow-promts should fire while a valid settings.json file is present

Error Messages/Logs

Steps to Reproduce

Steps to reproduce
On Windows, have a project with accepted trust and a working permissions.allow list under the pre-update build (project keyed as C:\Users\... in ~/.claude.json).
Update the Desktop app (the build that re-keys projects to C:/Users/...).
Open a session in that project and run an allowlisted side-effectful command, e.g. git push with Bash(git push:) / PowerShell(git push:) in .claude/settings.json permissions.allow.
Expected
Command runs without a permission prompt (allowlist honored), as pre-update.

Claude Model

Other

Is this a regression?

Yes, this worked in a previous version

Last Working Version

two versions ago, don't know the number

Claude Code Version

Claude 1.17377.2 (e0ea9e) 2026-07-01T05:51:58.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_