Summary
A desktop-app session whose cwd is a git worktree under an already-trusted repo can get permanently stuck on "This workspace isn't trusted" — the trust dialog never appears, and "Try again" can never succeed. The app and the CLI disagree about what "trusted" means, and each waits for the other.
Environment
- Claude Code desktop app (macOS, Darwin 25.6.0)
- CLI v2.1.144 on the same machine
- Session created by the app in
.claude/worktrees/<name> under a repo whose root is trusted (hasTrustDialogAccepted: true in ~/.claude.json)
What happens
- Desktop session's cwd is
<repo>/.claude/worktrees/<name>. That exact path has no entry under projects in ~/.claude.json (sibling worktrees have entries; this one was missed — cause unknown, session dates from June).
- Opening the session shows the toast: "This workspace isn't trusted. If you trust this workspace, try again and choose Trust workspace when asked."
- Clicking Try again re-fails with the same toast. The promised trust prompt never appears.
- Internally the failure is
"Workspace requires trust approval before starting a session." (surfaced verbatim when another session tried send_message to the stuck one).
Why it can never self-resolve (the deadlock)
- The desktop app requires an exact per-path
hasTrustDialogAccepted: true entry for the session's cwd.
- The CLI inherits trust from the parent repo directory: running
claude (interactive or -p) inside the worktree starts immediately, never shows the folder-trust prompt, and therefore never writes the per-path entry.
- Result: the only flow that writes the entry the app demands is a prompt that will never be shown, because by the CLI's rules the folder is already trusted.
Verified on the affected machine: claude -p "reply OK" in the worktree succeeds with no prompt while the app simultaneously refuses to start a session there.
Workaround
Quit the app, then add the entry manually:
python3 -c "import json,os; p=os.path.expanduser('~/.claude.json'); d=json.load(open(p)); d['projects'].setdefault('<worktree-path>',{})['hasTrustDialogAccepted']=True; json.dump(d,open(p,'w'),indent=2)"
Session starts normally afterwards.
Suggested fixes (either resolves it)
- Desktop app honors ancestor trust the way the CLI does (a worktree under a trusted repo is trusted), or
- The app's "Try again" path shows its own trust dialog when the backing CLI is not going to prompt.
Also worth a look: the toast's wording ("choose Trust workspace when asked") promises a prompt that, in this state, is unreachable.
Summary
A desktop-app session whose cwd is a git worktree under an already-trusted repo can get permanently stuck on "This workspace isn't trusted" — the trust dialog never appears, and "Try again" can never succeed. The app and the CLI disagree about what "trusted" means, and each waits for the other.
Environment
.claude/worktrees/<name>under a repo whose root is trusted (hasTrustDialogAccepted: truein~/.claude.json)What happens
<repo>/.claude/worktrees/<name>. That exact path has no entry underprojectsin~/.claude.json(sibling worktrees have entries; this one was missed — cause unknown, session dates from June)."Workspace requires trust approval before starting a session."(surfaced verbatim when another session triedsend_messageto the stuck one).Why it can never self-resolve (the deadlock)
hasTrustDialogAccepted: trueentry for the session's cwd.claude(interactive or-p) inside the worktree starts immediately, never shows the folder-trust prompt, and therefore never writes the per-path entry.Verified on the affected machine:
claude -p "reply OK"in the worktree succeeds with no prompt while the app simultaneously refuses to start a session there.Workaround
Quit the app, then add the entry manually:
python3 -c "import json,os; p=os.path.expanduser('~/.claude.json'); d=json.load(open(p)); d['projects'].setdefault('<worktree-path>',{})['hasTrustDialogAccepted']=True; json.dump(d,open(p,'w'),indent=2)"Session starts normally afterwards.
Suggested fixes (either resolves it)
Also worth a look: the toast's wording ("choose Trust workspace when asked") promises a prompt that, in this state, is unreachable.