Worktree isolation: session guidance suggests the ! prefix as a workaround, but ! runs in the same session and hits the identical block

Summary

When a Bash command is blocked by worktree isolation (a session pinned to
one worktree tries to target a path outside it), the session's own
guidance suggests the user route around the restriction by re-running the
command themselves with the ! prefix ("run it in this session"). That
suggestion does not work for this restriction class: !-prefixed commands
still execute inside the same session's execution context, subject to the
same worktree-isolation boundary — so the user's !-prefixed retry hits
the identical block.

Reported reproduction

Account-reported (epub-pdf-splitter session, 2026-08-18, relayed via a
backlog task note — not independently reproduced in the session that
filed this issue): a session isolated to one worktree had a Bash command
blocked for targeting a directory outside it, the block's own guidance
suggested the ! prefix as an escape hatch, and the user's !-prefixed
command hit the same worktree-isolation block.

This looks related to the broader worktree-isolation bug cluster already
filed (e.g. #87959, #84258, #85931, #84452) but is specifically about the
suggested remediation being wrong for this restriction class, not about
the restriction itself over-triggering.

Why this matters

The guidance implies a real way to route around a Claude-side restriction
when the user genuinely needs to run something outside the pinned
worktree (e.g. inspecting a sibling checkout). Suggesting ! here is
actively misleading — worse than suggesting nothing, since the user
expects it to work based on the guidance and only discovers the failure
after already committing to that path.

Requested fix

Either:

1. Give !-prefixed commands a real escape hatch from worktree-isolation

Bash restrictions specifically (they're explicitly user-initiated, not
model-initiated), or

1. Stop suggesting ! as a workaround for this restriction class in the

block message / session guidance, so a future session doesn't propose
a fix that silently doesn't work.