[BUG] Windows: claude --bg / agent view refuses a trusted folder when the trust key's casing differs from disk, and the suggested fix never shows a prompt

Status Open
Reported on v2.1.281
Maintainer reply None cached
Activity 0 comments · opened Sep 25, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Code

What's Wrong?

on windows, claude --bg (and new sessions from the agent view) refuse a folder that is already trusted, when the trust key in ~/.claude.json is spelled with different casing than the folder on disk.

the --bg trust check resolves the cwd to its on-disk casing (C:\Users\me\Areas\myproject) and then looks up projects[...] by exact string. if the stored key is C:/Users/me/areas/myproject, it misses and exits with:

Workspace not trusted. Run `claude` in C:\Users\me\Areas\myproject once and accept the trust prompt, then retry.

the advice is a dead end: running plain claude in that folder shows no trust prompt at all (the interactive check treats the folder as trusted), so nothing new gets written and --bg keeps refusing. the only way out is hand-editing ~/.claude.json.

my setup: i launch sessions through a directory junction whose target is spelled lowercase (...\areas\myproject, real folder is Areas), and past sessions recorded that spelling. it worked fine until 2.1.281 added the trust check to --bg.

same root cause as #95791 (case-sensitive trust lookup on a case-insensitive filesystem, drive letter there, path segment here), different surface.

What Should Happen?

trust lookups on windows should compare paths case-insensitively, or canonicalize the stored key the same way the cwd is canonicalized. at minimum, the interactive and --bg checks should agree, so the fix the error message suggests actually works.

Error Messages/Logs

Workspace not trusted. Run `claude` in C:\Users\me\AppData\Local\Temp\cc-trust-case\CaseDemo once and accept the trust prompt, then retry.

Steps to Reproduce

deterministic, uses an isolated CLAUDE_CONFIG_DIR so your real config is untouched, and exits at the trust check before any API call:

$root = Join-Path $env:TEMP 'cc-trust-case'
$cfg  = Join-Path $root 'cfg'
$dir  = Join-Path $root 'CaseDemo'          # on-disk name has capitals
New-Item -ItemType Directory -Force $cfg, $dir | Out-Null

# trust record for the same folder, stored with different casing
$key = (Join-Path $root 'casedemo').Replace('\', '/')
@{ hasCompletedOnboarding = $true; projects = @{ $key = @{ hasTrustDialogAccepted = $true } } } |
  ConvertTo-Json -Depth 5 | Set-Content (Join-Path $cfg '.claude.json')

$env:CLAUDE_CONFIG_DIR = $cfg
Set-Location $dir
claude --bg 'reply ok'
# -> Workspace not trusted. Run `claude` in ...\CaseDemo once and accept the trust prompt, then retry.

stored key vs launch spelling, same folder:

| stored trust key | launched from | --bg result |
|---|---|---|
| .../casedemo | casedemo | refused |
| .../casedemo | CaseDemo | refused |
| .../CaseDemo | casedemo | starts |
| .../CaseDemo | CaseDemo | starts |

so the cwd gets canonicalized to on-disk case, the stored key doesn't.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.280 (before --bg checked trust at all)

Claude Code Version

2.1.282 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

workaround: add a second projects entry with the on-disk casing and "hasTrustDialogAccepted": true.

View original on GitHub ↗