[BUG] Workspace trust dialog asks on every session startup, doesn't persist acceptance

[harvey-elaine]

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?

Every time I start an interactive Claude Code session in my home directory (C:\Users\harve), I'm prompted to confirm
whether I trust that directory. Clicking "yes" has no effect — it asks again the next session.

Expected behavior: Accepting the workspace trust dialog should persist the answer so it doesn't prompt again for the
same directory.

What Should Happen?

Actual behavior: The dialog reappears on every startup regardless of previous acceptance.

Error Messages/Logs

Steps to Reproduce

Start claude and it asks whether the home directory should be trusted.
Choose Yes
Quit and restart ClaudeCLI.
It asks again.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.92

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Environment:

• Platform: Windows 11
• Claude Code version: 2.1.92
• Shell: bash

[github-actions]

Found 2 possible duplicate issues:

1. [BUG] Windows: Trust dialog stuck — Enter key does nothing due to mkdirSync EEXIST error #31156
2. [BUG] Claude Code's config-save lock mechanism uses mkdirSync without the {recursive: true} flag on Windows. #33118

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[DavidBellamy]

This issue is not a duplicate. Please add this feature!

[THR1212]

Reproduced consistently on Windows 11, Claude Code native install, v2.1.138. Traced the root cause using a FileSystemWatcher (PowerShell) monitoring all event types — Changed, Created, Deleted, Renamed — on .claude.json*.

How Claude Code writes config on Windows

Claude Code uses atomic writes: it creates a temp file (.claude.json.tmp.<PID>.<hash>), writes to that, acquires .claude.json.lock, deletes the original .claude.json, then renames the temp file into place. Any watcher only listening for
Changed events on .claude.json directly will miss every write entirely.

What the watcher showed

With hasTrustDialogAccepted: false set in .claude.json, I restarted Claude Code and accepted the trust dialog. Multiple writes occurred across two processes — the value stayed false through all of them:

[18:50:44] Created .claude.json.tmp.11188.xxx → hasTrustDialogAccepted = false
[18:50:45] Renamed .claude.json → hasTrustDialogAccepted = false
[18:51:04] Created .claude.json.tmp.11188.xxx → hasTrustDialogAccepted = false
[18:51:18] Created .claude.json.tmp.29388.xxx → hasTrustDialogAccepted = false ← ~when dialog accepted
[18:51:19] Renamed .claude.json → hasTrustDialogAccepted = false
[18:51:20] Renamed .claude.json → hasTrustDialogAccepted = false
[18:51:22] Renamed .claude.json → hasTrustDialogAccepted = false

For comparison, a direct PowerShell write to the same file immediately produced:

[19:01:45] Changed .claude.json → hasTrustDialogAccepted = true

The file had hasTrustDialogAccepted: true before the new session started (verified by self-test). Claude Code's own writes never produce true — the acceptance state is never flushed to disk.

Root cause

The write infrastructure works correctly — state is flushed multiple times per session. The most likely mechanism is a path-key canonicalization mismatch on Windows: the accept-handler writes hasTrustDialogAccepted: true under one path form
(e.g. backslash C:\Users\name) while the trust-check reader looks it up under another (e.g. forward slash C:/Users/name). Each flush faithfully serializes false under the reader's key — because that object's default was never updated — while
the written true lands on a key the reader never checks.

This is consistent with the duplicate project-key bug already documented on Windows: Claude Code sometimes writes both "C:/Users/Name/folder" and "C:\Users\Name\folder" as separate entries in the projects object. It also explains why the
forward-slash workaround below works — it writes true directly under the form the reader uses for lookup.

Workaround

Manually set the value once in .claude.json using PowerShell (forward slashes in the project key, matching the form Claude Code uses for trust lookups on Windows):

$path = "$env:USERPROFILE\.claude.json"
$json = Get-Content $path -Raw | ConvertFrom-Json
$json.projects."C:/Users/<yourname>".hasTrustDialogAccepted = $true
$json | ConvertTo-Json -Depth 100 | Set-Content $path -Encoding utf8

This persists — once set, subsequent session writes preserve the true value and the dialog does not reappear for that directory or its subdirectories.

Written by Sonet 4.6 and reviewed by Opus 4.7

[RemcovandenBerg]

Same issue: and fix:
Seems to be a regression. Now installed through npm (using nvm) Claude in powershell terminal windows 11
[BUG] Regression: #3366