claude remote-control: workspace trust flag reverts to false despite accepting the trust dialog

Open 💬 2 comments Opened Jun 24, 2026 by protocol-pixel

Claude Code version: 2.1.187
OS: Windows 11 Home Single Language, build 10.0.26200
Shell: PowerShell / cmd

Steps to reproduce:

  1. Open a normal terminal and run claude in C:\Users\Asus.
  2. Accept the workspace trust dialog when prompted.
  3. Exit or leave that session running.
  4. In a terminal, run claude remote (alias for claude remote-control) in the same directory.

Expected behavior:
Remote Control activates, since the trust dialog was already accepted for this workspace.

Actual behavior:
The command fails with:
Error: Workspace not trusted. Please run claude in C:\Users\Asus first to review and accept the workspace trust dialog.

Inspecting ~/.claude.json, the project entry for "C:/Users/Asus" shows "hasTrustDialogAccepted": false, even immediately after re-accepting the dialog.

Suspected root cause:
Another Claude Code session was concurrently active in the same directory (started without going through the standard terminal trust prompt, so it held hasTrustDialogAccepted: false in memory). Each time that session persists its state to the shared ~/.claude.json, it appears to overwrite the true value just set by the other session — a race condition between concurrent sessions writing the same global config file for the same project path.

Suggestion: trust state writes should either merge per-field instead of overwriting the whole project object, or re-read the on-disk value before writing back hasTrustDialogAccepted.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗