Bash sandbox for isolation:worktree dispatched agents false-blocks on the substring "git" anywhere in the command, including inside unrelated prose #93193

Title: Bash sandbox for isolation:worktree dispatched agents false-blocks on the substring "git" anywhere in the command, including inside unrelated prose

Body:

What happened

A background agent dispatched with isolation: "worktree" had a Bash command refused by the sandbox with a message to the effect of "too complex to verify [it] stays inside the worktree," even though the command contained no git invocation at all — no $(git ...) substitution, no git subcommand anywhere.

The command was:

python3 scripts/work.py update TX-KAN-NNNNN "status_update=$(cat "$SCRATCH")"

$SCRATCH was a plain text file (written earlier in the same shell) whose prose content included the English word "legitimate" — which contains the substring git. Removing that one word from the file content made the identical command succeed.

Reproduction

SCRATCH=$(mktemp)
cat <<'EOF' > "$SCRATCH"
this is a legitimate status update with no git command in it at all
EOF
echo "$(cat "$SCRATCH")"

Dispatched with isolation: "worktree", this is refused. The same command run in an interactive (non-dispatched) session's Bash tool executes cleanly — the restriction appears specific to the sandbox applied to isolation:worktree/background-agent Bash execution, not to Bash execution generally.

Expected behavior

The sandbox's "is this a git invocation I can't statically verify stays inside the worktree" check should key off an actual git token in a shell-command position (e.g. word-boundary match on a command word, or a real shell/AST parse), not a raw substring scan over the entire command string — which also matches inside quoted prose, heredoc bodies, variable names, and any other English word containing "git" (legitimate, digit, digits, gitignore-as-a-word, legitimize, etc.).

Impact

Low severity, but it silently misfires on ordinary status-update text, commit messages, or any file content piped through Bash by a dispatched agent — with no accepted-form escape hatch, since the block fires before any project-level PreToolUse hook runs. We've hit this multiple times dispatching background agents from a large monorepo and worked around it by avoiding the word "legitimate" (and presumably any other word containing "git") in text piped through Bash — which isn't a fix, just an avoidance.

Suggested fix

Replace the substring scan with a proper tokenization / word-boundary check for the git command word specifically in a command position (start of command, after a shell separator like &&/;/|, or as the target of env/sudo/etc.), so that:

• git status, $(git rev-parse --git-dir), foo && git push → correctly flagged for verification
• "...legitimate...", "...digit...", "...gitignore..." appearing anywhere in quoted strings, heredocs, or variable content → correctly ignored

Environment

• Claude Code CLI, desktop app
• Trigger: Agent tool call with isolation: "worktree"
• Observed inside a git worktree-based monorepo project