What's wrong
arcadia go-broker install sets up workspace trust and permission scope for Claude Code, but only for a small, fixed set of "home" project repositories, each of which nests its own Session worktrees inside itself (e.g. `/Users/pmark/Dev/MR/Arcadia/arcadia/.claude/worktrees/`). Every one of those nested paths shows `hasTrustDialogAccepted: true` in `~/.claude.json`.
A newly-onboarded Project (in the observed case, a disposable rehearsal fixture, but this applies to any Project not in that fixed home set) gets its Claude Code Sessions launched into the shared global worktree root instead — `~/.claude/worktrees/-/` — which is never registered as trusted by `go-broker install` at all. The first time a Session launches there, Claude Code shows its interactive first-run dialog:
```
Quick safety check: Is this a project you created or one you trust? ...
❯ No, exit
Yes, I trust this folder
```
This is a real, blocking interactive prompt with no way to answer it non-interactively. Under a detached tmux Session launched by the automated production tick, with no operator watching, this would leave the Session hanging indefinitely at this prompt — it isn't even a "needs_input" Arcadia can detect and report, since as far as Arcadia's own tracking is concerned the process is just running (or possibly not even that, if Claude Code refuses to proceed past the prompt in a non-interactive/piped context).
Note that `inspectGoBrokerAgentSetup`'s `workspaceTrust`/`codexWorkspaceTrust` check (`src/agentSetup/goBrokerAgentSetup.ts:224-229,263`) is entirely about Codex's `/.codex/config.toml` trust level (`codexTrustLevel`), despite the generic-sounding name `workspaceTrust` in the JSON output. There is no equivalent check or registration step for Claude Code's own trust store (`/.claude.json`'s per-path `hasTrustDialogAccepted`) at all — `claudeWorktreeDirectories` (`goBrokerAgentSetup.ts:262`) only checks that the same, fixed home-project worktree roots appear in Claude's `permissions.additionalDirectories`, which is a different setting (broadens file-access permission scope) from the trust dialog gate, and still only covers the fixed home-project set, not the shared global root.
Reproduction
- Onboard a new Project whose Claude Code Sessions launch via the shared `~/.claude/worktrees/` root rather than a repo-nested one (this is the normal path for any Project outside Arcadia's own small fixed home set — observed with a disposable rehearsal fixture Project registered earlier the same day).
- Seed a build packet with `--agent-profile claude_build` and run the resulting `arcadia-go-broker-claude` / `claude ...` launch command (or let automated production launch it).
- Claude Code shows the interactive trust dialog on first use of that fresh worktree path; nothing in `go-broker install`'s output (`agentSetup.status.checks`, all `true` in the observed run) named this as a gap beforehand.
Impact
Blocks the "no operator intervention" premise of automated/unattended production for any Project outside Arcadia's small fixed home set, the first time Claude Code launches a Session for it. This is squarely in the same category of failure the sibling zero-prompt-rehearsal proof's "zero permission-denial lines" criterion exists to catch — an unanswerable interactive prompt is worse than a clean refusal, since it can hang a Session indefinitely with no operator-visible signal beyond a live-but-silent tmux pane.
Suggested fix
Extend `go-broker install`'s Claude Code setup to pre-accept trust (write `hasTrustDialogAccepted: true`) for the shared global Claude worktree root itself (or for each Project's worktree path at Session-preparation time, the same moment `prepareSession`/`arcadia go` creates it) — not only the fixed home-project set. Add a corresponding `claudeWorkspaceTrust`-style check (parallel to the existing, correctly-named `codexWorkspaceTrust` check) to `inspectGoBrokerAgentSetup` so this gap shows up in `go-broker status`/`install` output instead of only surfacing live, mid-Session, as an unattended interactive dialog.
What's wrong
arcadia go-broker installsets up workspace trust and permission scope for Claude Code, but only for a small, fixed set of "home" project repositories, each of which nests its own Session worktrees inside itself (e.g. `/Users/pmark/Dev/MR/Arcadia/arcadia/.claude/worktrees/`). Every one of those nested paths shows `hasTrustDialogAccepted: true` in `~/.claude.json`.A newly-onboarded Project (in the observed case, a disposable rehearsal fixture, but this applies to any Project not in that fixed home set) gets its Claude Code Sessions launched into the shared global worktree root instead — `~/.claude/worktrees/-/` — which is never registered as trusted by `go-broker install` at all. The first time a Session launches there, Claude Code shows its interactive first-run dialog:
```
Quick safety check: Is this a project you created or one you trust? ...
❯ No, exit
Yes, I trust this folder
```
This is a real, blocking interactive prompt with no way to answer it non-interactively. Under a detached tmux Session launched by the automated production tick, with no operator watching, this would leave the Session hanging indefinitely at this prompt — it isn't even a "needs_input" Arcadia can detect and report, since as far as Arcadia's own tracking is concerned the process is just running (or possibly not even that, if Claude Code refuses to proceed past the prompt in a non-interactive/piped context).
Note that `inspectGoBrokerAgentSetup`'s `workspaceTrust`/`codexWorkspaceTrust` check (`src/agentSetup/goBrokerAgentSetup.ts:224-229,263`) is entirely about Codex's `
/.codex/config.toml` trust level (`codexTrustLevel`), despite the generic-sounding name `workspaceTrust` in the JSON output. There is no equivalent check or registration step for Claude Code's own trust store (`/.claude.json`'s per-path `hasTrustDialogAccepted`) at all — `claudeWorktreeDirectories` (`goBrokerAgentSetup.ts:262`) only checks that the same, fixed home-project worktree roots appear in Claude's `permissions.additionalDirectories`, which is a different setting (broadens file-access permission scope) from the trust dialog gate, and still only covers the fixed home-project set, not the shared global root.Reproduction
Impact
Blocks the "no operator intervention" premise of automated/unattended production for any Project outside Arcadia's small fixed home set, the first time Claude Code launches a Session for it. This is squarely in the same category of failure the sibling zero-prompt-rehearsal proof's "zero permission-denial lines" criterion exists to catch — an unanswerable interactive prompt is worse than a clean refusal, since it can hang a Session indefinitely with no operator-visible signal beyond a live-but-silent tmux pane.
Suggested fix
Extend `go-broker install`'s Claude Code setup to pre-accept trust (write `hasTrustDialogAccepted: true`) for the shared global Claude worktree root itself (or for each Project's worktree path at Session-preparation time, the same moment `prepareSession`/`arcadia go` creates it) — not only the fixed home-project set. Add a corresponding `claudeWorkspaceTrust`-style check (parallel to the existing, correctly-named `codexWorkspaceTrust` check) to `inspectGoBrokerAgentSetup` so this gap shows up in `go-broker status`/`install` output instead of only surfacing live, mid-Session, as an unattended interactive dialog.