[BUG] Windows: remote-control trust check normalizes cwd to forward slashes but misses backslash keys in ~/.claude.json projects

Environment

• Claude Code version: v2.1.168 (native install)
• OS: Windows 11 Pro, build 10.0.26200
• Shell: PowerShell

Problem

claude remote-control exits with:

Error: Workspace not trusted. Please run `claude` in <dir> first to review and accept the workspace trust dialog.

even for directories whose ~/.claude.json projects entry has hasTrustDialogAccepted: true.

Running interactive claude in that directory shows no trust dialog — it considers the folder already trusted — so the suggested remediation does nothing and the user is stuck in a loop: interactive mode says trusted, server mode says not trusted.

Steps to reproduce

1. On Windows, have a projects entry in ~/.claude.json whose key uses backslashes (e.g. "C:\\Users\\<user>\\Claude") with hasTrustDialogAccepted: true. Entries written by the Claude Desktop app (and possibly older CLI versions) are stored this way.
2. Run claude remote-control in that directory.
3. It fails with "Workspace not trusted".
4. Run interactive claude in the same directory — no trust dialog appears (already trusted), so there is no way to satisfy the check.

Root cause

Verified by strings in the binary and by experiment: the server-mode trust check normalizes the cwd to forward slashes (e.g. C:/Users/FormDT1/Claude) before looking up projects keys — including during the parent-directory walk. But entries written by the Claude Desktop app (and possibly older CLI versions) use backslash keys (C:\Users\FormDT1\Claude), so the lookup never matches.

Supporting evidence:

• A project whose key happened to be stored with forward slashes (C:/Users/FormDT1/Claude/ruflo) worked with remote-control immediately.
• Manually duplicating the backslash entry under a forward-slash key fixed the broken folder.

Relevant snippets found via grep on the binary:

if(H.projects?.[K]?.hasTrustDialogAccepted)return!0;let K=Xd(u8());

and the parent-walk variant:

let K=Xd(gw.resolve($,".."));if(K===$)return!1

Workaround

Duplicate the affected projects entry in ~/.claude.json under a forward-slash key (keeping the original backslash entry).

Suggested fix

Normalize path separators consistently on both write and lookup — or compare projects keys separator-insensitively on Windows.

Related issues

• #39065 — same symptom (closed as completed, but the separator root cause was never identified; likely this bug)
• #70501 — different root cause (trust flag reverts to false; here the flag stays true but the lookup misses it)