spawn_task chip silently does nothing when the workspace denies EnterWorktree / git worktree add

Summary

Clicking a spawn_task suggestion chip does nothing at all — no new session, no error, no toast, no visible state change on the chip — when the workspace denies worktree creation through .claude/settings.json. The chip stays in place and can be clicked repeatedly with the same silent result.

The failure is reproducible and recurring: every spawn_task chip created in this workspace is unusable, and there is no feedback anywhere in the UI explaining why.

Environment

• Claude Code 2.1.247
• Windows 11 Pro 10.0.26200
• Desktop app, session started at the workspace root
• Workspace is a multi-repository container with many concurrent agent sessions

Repro

1. In a workspace whose root .claude/settings.json denies worktree creation:

{
  "permissions": {
    "deny": [
      "Bash(git worktree add:*)",
      "EnterWorktree"
    ]
  }
}

1. Have the assistant call spawn_task so a suggestion chip is rendered.
2. Click the chip.

Expected: either a new session starts, or the UI explains that it cannot because worktree creation is denied — ideally with the option to run in the current directory instead.

Actual: nothing happens. No session, no error, no indication the click registered.

Why this looks like the cause

The desktop log shows the worktree machinery operating under <repo>/.claude/worktrees/<generated-name>:

[info] [WorktreePool] Pruning orphaned store entry funny-lehmann-2ec4db (directory gone or not a worktree)
[info] Removing worktree "funny-lehmann-2ec4db" (leased by none): C:\...\repo\.claude\worktrees\funny-lehmann-2ec4db
[error] Git command failed: git -c core.longpaths=true worktree remove --force C:\...\repo\.claude\worktrees\...

That is exactly the path the chip's "start in a fresh worktree" flow needs, and exactly what both deny rules block. The denial appears to be swallowed rather than surfaced.

Note the logs above are from an earlier date — no log line at all was written when the chip was clicked today, which is itself part of the problem: the failure leaves no trace to diagnose.

Impact

spawn_task is silently non-functional in any workspace that restricts worktree creation. Restricting it is legitimate here: multiple Claude Code and Codex sessions run concurrently against the same repositories, and worktrees are allocated by a workspace tool into a policy-controlled location rather than into <repo>/.claude/worktrees/. The assistant keeps offering chips, the user keeps clicking them, and nothing ever explains the mismatch.

Suggested handling

Any of these would resolve it:

1. Surface the denied permission in the UI when the chip's launch path is blocked.
2. Fall back to starting the spawned session in the current working directory, stating that isolation was unavailable.
3. Let spawn_task chips honour a configured worktree location instead of hardcoding <repo>/.claude/worktrees/.

At minimum, a click that cannot succeed should not be indistinguishable from a click that was never registered.

Possibly related

• #90668 — spawn_task chip runs in the spawning session's working tree, not an isolated worktree
• #78848 — Windows desktop: spawn_task chip primary button contradicts spawn-to-new-session intent (closed)
• #84295 — Mobile (iOS): spawn_task chips not tappable