[BUG] Code tab "Trust settings couldn't be saved" on Windows MSIX — saveTrust logs success but no config.json is created

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?

Clicking "Trust Workspace" in the Code tab of Claude Desktop on Windows (MSIX build) fails with the UI error:

Trust settings couldn't be saved. You can try again.

This blocks all Code-tab work in any folder. Retrying produces the same error indefinitely.

The desktop log shows LocalSessions.saveTrust completing with "Config file written" — but no config.json exists anywhere under the MSIX package after the click. Instead, the saves land in LocalLow\<SHA-256-hash> files in Windows ADI (App Data Isolation) INSC binary format, which the app's read path does not appear to consume.

Net effect: the save logs as successful, but the trust list is never persisted to a location the app reads from on next access.

What Should Happen?

After clicking "Trust Workspace" on a folder, the trust setting should be persisted to the expected config location, the folder should be marked as trusted, and the Code session should start without further prompts.

Specifically: a config.json file should appear at the expected MSIX-virtualized path (%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\config.json) containing a trustedFolders entry for the folder I just trusted.

Error Messages/Logs

UI error:
Trust settings couldn't be saved. You can try again.

main.log (relevant lines):
[MSIX] Filesystem virtualization active
...
LocalSessions.saveTrust: Config file written

Filesystem state immediately after Trust Workspace click:

PS> Get-ChildItem "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Force `
    -ErrorAction SilentlyContinue |
  Where-Object {
    -not $_.PSIsContainer -and
    ($_.Name -like "*config*" -or $_.Name -like "*trust*" -or
     $_.Name -like "*.json"   -or $_.Name -like "*.db"    -or
     $_.Name -like "*.sqlite*")
  }
# (no output — no config.json, no *.json, no database files anywhere in the package)

Files actually modified at the moment of the click:

FullName                                                                                                                                                  LastWriteTime
--------                                                                                                                                                  -------------
...\Packages\Claude_pzs8sxrjxfjjc\LocalCache\LocalLow\5e51d5475ec88d1267dc1cd5cd93dfbd107313381ab54d6068f20575523d9e02   01/05/2026 14:04:52
...\Packages\Claude_pzs8sxrjxfjjc\LocalCache\LocalLow\307d5d191a959f13b38af9dcfb0215c46454c4685d8dc9e3a758d0e9796dbaf1   01/05/2026 14:02:51
...\Packages\Claude_pzs8sxrjxfjjc\LocalCache\LocalLow\35651d1cc0bebe018d4b9e5255930cdb555974270ba5d6c7b621f5e303950689   01/05/2026 14:02:51
...\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat                                                          01/05/2026 14:02:47
...\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\UserClasses.dat                                                   01/05/2026 14:02:47
...\Packages\Claude_pzs8sxrjxfjjc\Settings\roaming.lock                                                                  01/05/2026 14:02:47

Hex header of the most recent SHA-256-named file (the file written at the exact moment of the Trust Workspace click):

49 4E 53 43 D1 7D 03 00 00 02 00 4E 6F 76 32 36
32 30 32 35 30 32 30 37 32 30 A7 D7 39 CE F5 91
4F A1 0E 1F A0 0C 95 0C A5 2D 00 00 00 00 00 00
...

The "INSC" magic bytes (0x49 0x4E 0x53 0x43) identify this as a Windows App Data Isolation integrity record, not a Claude-format config file. A new INSC blob is created on each Trust Workspace attempt.

Steps to Reproduce

1. On Windows 11, install Claude Desktop via Microsoft Store (MSIX, version 1.5354.0). Direct MSIX install from https://claude.ai/api/desktop/win32/x64/msix/latest/redirect reproduces identically.
2. Sign in.
3. Open the Code tab.
4. Select any local folder. Tested with C:\Users\<user>\Documents\GitHub\<project> (deliberately outside OneDrive to rule out OneDrive interference).
5. Click "Trust Workspace" on the trust prompt.

Expected: Trust persists, Code session starts.
Actual: UI shows "Trust settings couldn't be saved. You can try again." Retrying produces identical results indefinitely.

Verification:

• Run the PowerShell command in the Error Messages section to confirm no config.json is created anywhere under %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\.
• Note that an INSC-format binary blob does get written at the moment of the click, but it is not in a location or format that the app's read path uses.

Things ruled out (none of these resolve the bug):

• Reinstalling MSIX from a fully clean state (uninstall, Get-AppxPackage *Claude* | Remove-AppxPackage, manually delete leftover Packages\Claude_pzs8sxrjxfjjc\ folder, reinstall)
• Adding trustedDirectories to %USERPROFILE%\.claude\settings.json
• Renaming ~/.claude.json to force regeneration
• Running Claude as Administrator
• Moving the project folder out of OneDrive
• Confirming Controlled Folder Access is off (it was already off)
• Confirming AppData is not redirected to OneDrive (verified via registry User Shell Folders — AppData and Local AppData resolve to the standard C:\Users\<user>\AppData\ paths)

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

(Unsure - Last update?)

Claude Code Version

N/A — Claude CLI not installed. This bug is in Claude Desktop, version 1.5354.0, MSIX package Claude_1.5354.0.0_x64__pzs8sxrjxfjjc.

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

This bug is in Claude Desktop (the app, not the CLI). The form is CLI-oriented, so several fields don't fit cleanly — apologies for the awkward mappings.

Environment details

• OS: Windows 11
• Install method: MSIX from Microsoft Store (also reproducible via direct MSIX from https://claude.ai/api/desktop/win32/x64/msix/latest/redirect)
• Package: Claude_1.5354.0.0_x64__pzs8sxrjxfjjc
• Claude Desktop version: 1.5354.0
• AppData redirection: None — %APPDATA% and %LOCALAPPDATA% resolve to standard C:\Users\<user>\AppData\ paths (verified via registry User Shell Folders)
• OneDrive: Active on machine but not redirecting AppData. ~/.claude/ is on OneDrive but moving project folders out of OneDrive has no effect on the bug.
• Controlled Folder Access: Off
• EDR / corporate AV: None

Hypothesis

LocalSessions.saveTrust appears to call a write API that Windows MSIX silently routes through App Data Isolation's INSC integrity layer instead of persisting to the expected virtualized Roaming\Claude\config.json path. The write returns success (hence the misleading "Config file written" log line), but the file never lands where the read path looks for it. The UI's "couldn't be saved" error is therefore correct on the read-back check — the data genuinely isn't where the app expects it.

This is consistent with a known class of MSIX virtualization bugs where Electron / Node fs writes against paths the package manifest hasn't explicitly declared get redirected into ADI rather than the package's writable mount.

Suggested investigation

1. Check the package manifest (AppxManifest.xml) for the file capabilities and writable path declarations. The Roaming\Claude\ path may not be declared as a writable virtualized location, causing Windows to fall back to ADI redirection.
2. Verify whether LocalSessions.saveTrust's "Config file written" log fires on a successful fs.writeFile callback, or whether it's logging optimistically before the OS has actually persisted the file to a readable location.
3. Add a post-write read-back verification step in saveTrust that confirms the trust list is actually retrievable after the write — this would surface the failure earlier and give a clearer error to users.

Workaround status

None viable. The Squirrel .exe installer (served from https://claude.ai/api/desktop/win32/x64/exe/latest/redirect) is the only alternative install path, but:

• Cowork is feature-gated off on Squirrel ("Cowork requires a newer installation" — points back at the MSIX download)
• Per #25162, there is no automatic upgrade path from Squirrel to MSIX, so falling back to Squirrel locks users out of future MSIX-only fixes
• The Squirrel build has its own reported bugs (e.g. formatjs crash on 1.1.4173)

Affected users on Windows have no working configuration for both Code and Cowork.

Related issues

This appears to be part of a wider pattern of MSIX-rollout and trust-persistence issues:

• #21283 — Workspace trust prompt appears repeatedly, settings not persisting
• #12227 — Workspace trust not persisting in CLI (similar class of bug)
• #25385, #26457, #47877 — MSIX installer / Cowork-deployment cluster
• #25162 — No automatic upgrade path from Squirrel to MSIX

<img width="786" height="253" alt="Image" src="https://github.com/user-attachments/assets/ddf75b09-4213-4a50-bcbd-4e9dc5e4b7be" />