Summary
In a worktree-isolated agent, the Bash command guard refuses a command that a PreToolUse hook explicitly allowed
("permissionDecision":"allow"). The hook's verdict is recorded in the transcript, and the refusal follows it. No
setting, permission rule, or hook output lets a user override the guard for a command they have judged safe.
Version: 2.1.292, macOS (darwin arm64).
Repro
- Install a PreToolUse hook on
Bash that returns
{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"allow"}} for the command below.
- Spawn an agent with
isolation: worktree that writes .claude/tmp/guardtest/x.awk (BEGIN{print "awk ran"}) and
in.txt with the Write tool, then runs:
awk -f .claude/tmp/guardtest/x.awk .claude/tmp/guardtest/in.txt
Observed
The transcript's hook_success attachment for the call shows the hook's permissionDecision":"allow". The tool result
is:
This agent is isolated in the worktree …/agent-a8422017222635263, but this command runs awk with -f in a plain
command, so what it runs cannot be shown not to be git. Refusing to run it — a worktree-isolated agent's git
operations must target its own worktree. Run the plain command from …/agent-a8422017222635263.
The same refusal followed an explicit hook allow for /usr/bin/awk -f …, absolute-path awk -f …, and
cat x.awk | awk -f - ….
Control: the identical command, with the same hook allow, in the main session (no worktree) prints awk ran.
Expected
An explicit PreToolUse allow is the user's decision about that command, and the harness honours it — or, at minimum,
there is a documented setting that lets it take precedence over the worktree command guard.
Related
Other reports of the guard refusing git-free commands: #94040, #95122, #97225, #97474, #93193. This report is
narrower: the command was not merely git-free, the user's own hook explicitly allowed it. #93193 states the block fires
before any PreToolUse hook runs; the transcripts here show the hook ran and returned allow, and the refusal came after.
Summary
In a worktree-isolated agent, the Bash command guard refuses a command that a PreToolUse hook explicitly allowed
(
"permissionDecision":"allow"). The hook's verdict is recorded in the transcript, and the refusal follows it. Nosetting, permission rule, or hook output lets a user override the guard for a command they have judged safe.
Version: 2.1.292, macOS (darwin arm64).
Repro
Bashthat returns{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"allow"}}for the command below.isolation: worktreethat writes.claude/tmp/guardtest/x.awk(BEGIN{print "awk ran"}) andin.txtwith the Write tool, then runs:awk -f .claude/tmp/guardtest/x.awk .claude/tmp/guardtest/in.txtObserved
The transcript's
hook_successattachment for the call shows the hook'spermissionDecision":"allow". The tool resultis:
The same refusal followed an explicit hook allow for
/usr/bin/awk -f …, absolute-pathawk -f …, andcat x.awk | awk -f - ….Control: the identical command, with the same hook allow, in the main session (no worktree) prints
awk ran.Expected
An explicit PreToolUse
allowis the user's decision about that command, and the harness honours it — or, at minimum,there is a documented setting that lets it take precedence over the worktree command guard.
Related
Other reports of the guard refusing git-free commands: #94040, #95122, #97225, #97474, #93193. This report is
narrower: the command was not merely git-free, the user's own hook explicitly allowed it. #93193 states the block fires
before any PreToolUse hook runs; the transcripts here show the hook ran and returned
allow, and the refusal came after.