fix: pre-trust worktrees in the config file Claude actually reads; say why a task is blocked

[bborn]

What happened

A task routed to a non-default Claude profile went to blocked about 25s after it started. ty show printed:

Ran on:   local
Because:  no host in ~/.config/on/hosts.yaml serves myapp (4 hosts in inventory)

That line reads like the reason for the block. It is only the placement resolver keeping the task local, which was correct: none of the hosts has a checkout of the project. The real cause was Claude Code's "Quick safety check" workspace trust dialog in the fresh worktree.

Root cause (verified)

• The task log shows Routed to Claude profile ~/.claude-work (by plugin "claude-profile-router"), and the task's claude process had CLAUDE_CONFIG_DIR=~/.claude-work.
• ensureProjectTrusted writes to ClaudeConfigFilePath(dir), which returned dir + ".json", so ~/.claude-work.json. That file holds only TaskYou's own hasTrustDialogAccepted / hasCompletedProjectOnboarding entries.
• Claude Code 2.1.288 resolves its global config as $CLAUDE_CONFIG_DIR/.claude.json. It uses ~/.claude.json only when the variable is unset, and a .config.json in the config dir takes precedence (To()/Far() in the binary). So the pre-trust went to a file Claude never reads.
• Claude's backups of ~/.claude-work/.claude.json show the project's hasTrustDialogAccepted stayed false until the dialog was answered by hand.
• The repro used a scratch repo with a nested .task-worktrees/wt, a .claude symlink, settings.local.json pre-approving Read(.claude/attachments/**), and a non-default CLAUDE_CONFIG_DIR. Results:
  • Trust only in <dir>.json (the old ty behaviour): dialog.
  • Trust in <dir>/.claude.json for the main repo path: no dialog, with the settings.local.json permission present.
  • Trust written by this branch's ensureProjectTrusted: no dialog.

So the pre-approved permission in settings.local.json is not the trigger. The dialog only lists it. Writing the trust to the right file is enough. The default profile was never affected, because ~/.claude + .json is ~/.claude.json, and ty never exports the default dir.

Changes

• ClaudeConfigFilePath returns <dir>/.claude.json for a non-default dir, a legacy <dir>/.config.json when that exists, and ~/.claude.json for the default. This also fixes copyMCPConfig and purge-claude-config --config-dir for profiles, which were reading and writing the same dead file.
• Trust prompt detection: added the current dialog wording to blockingPromptPatterns. A task parked there now records Waiting on Claude Code's workspace trust prompt — choose "Yes, I trust this folder" to let the task start instead of the generic Executor is waiting on a dialog.
• ty show:
  • A new Blocked: line shows the reason and evidence from the transition that blocked the task.
  • Placement prints as Placement: local — <reason> (or Placement: <host> — <reason>) in place of the Ran on:/Because: pair, so it no longer reads as a block reason.
  • --json gains blocked_reason and blocked_detail. ran_on/ran_on_reason are unchanged.
• Placement (ty-on): I read the resolver and confirmed it only offers or chooses hosts with a non-blank checkout of the project. It falls back to local when there is no inventory, no serving host, or the probe fails, and core falls back to local when no handler is installed or a handler fails. Existing tests covered most of this. I added regression tests for that inventory shape (prefix-similar project names, a blank checkout, a host with no repos) and for "no inventory configured → local".
• QA stress script: corrected comments that documented the old path mismatch as a constraint.

Rendered ty show (branch binary against a DB copy, with a trust-prompt block event added):

Status:   blocked
Blocked:  the executor is waiting on a dialog and cannot make progress
          Waiting on Claude Code's workspace trust prompt — choose "Yes, I trust this folder" to let the task start
...
Placement: local — no host in ~/.config/on/hosts.yaml serves myapp (4 hosts in inventory)

Tests

• New: TestClaudeConfigFilePath, a stricter custom-dir subtest in TestEnsureProjectTrusted, TestDetectBlockingPromptNamesTheTrustDialog (real 2.1.288 capture), TestPlacementLine, TestBlockReason*, and ty-on TestResolveNeverPlacesOnAHostThatDoesNotServeTheProject and TestResolveWithNoInventoryRunsLocal.
• go test ./... fails the same 7 tests on this branch as on origin/main: the executor phantom-worktree and remote-worktree script tests, reaper TestLivePanePIDs_HonorsAgentSocket, and ui TestDetectMimeType_FixesPreviouslyBrokenFiles. They are environment-specific on this machine and unrelated to this change. ty-on (extensions/ty-on, its own module) passes. The new tests pass under -race.

Not covered

• An explicit manual placement (ty place <id> <host>, --on <host>) is still the user's choice. It is not checked against the inventory, only by the host preflight at launch.
• Existing ~/<profile>.json files that ty wrote under the old path are left in place. They are harmless.

🤖 Generated with Claude Code