Permission-mode system prompt instructs the model to edit files via Bash, routing writes around PreToolUse hooks on Write|Edit|NotebookEdit

What happens

When a permission mode is active, the session system prompt contains this directive:

While bypass permissions mode is active: Do your work through the Bash tool wherever it can accomplish the job: read files with cat, head, or sed -n, search with grep and find, and make file changes with sed, heredocs, or short scripts, rather than using the dedicated Read, Edit, or Write tools. Fall back to a dedicated tool only when Bash genuinely cannot do the job.

The same text appears under While auto mode is active: in that mode. Only the mode name
differs.

Why it matters

PreToolUse hooks that guard file writes are conventionally registered with the matcher
Write|Edit|NotebookEdit, because those are the tools that write files. A model that follows
the directive above makes its edits with sed and heredocs, so those hooks are never
called.

The important part is not that the hooks can be bypassed. It is that the product now
instructs the model to take the path that bypasses them, by default, whenever a permission mode
is on. A hook author who registered Write|Edit|NotebookEdit yesterday has a guard that quietly
stops being reached today, and nothing reports it: the hook does not fire, and a hook that does
not fire looks exactly like a hook with nothing to object to.

This lands hardest on hooks that protect something expensive to undo. In our case one of them
denies edits to .gitattributes, because a direct edit to that file once put an entire body of
working material under encryption by accident. That hook is still registered, still correct, and
is now routed around by default.

Reproduction

1. Register a PreToolUse hook with matcher Write|Edit|NotebookEdit that denies any edit to

target.txt.

1. Start a session with a permission mode active.
2. Ask for a change to target.txt.

Observed: the model edits the file with sed -i or a heredoc, the hook is never invoked, the
edit lands. Expected: either the hook is consulted, or the directive does not steer writes away
from the tools that hooks can intercept.

Relation to an earlier report

The general form of this was reported in #63786, "PreToolUse hook for Write/Edit can be bypassed
by writing files via the Bash tool", labelled area:security / area:hooks, with a repro. It
was closed by the inactivity bot, whose message invites opening a new issue if it is still
relevant. This is that new issue, and it adds the part that changed: the bypass is no longer
something a user has to choose, it is the default instruction.

Possible directions

Offered as options, not as a preferred fix:

1. Scope the directive to reads, and leave writes on the dedicated tools.
2. Suppress or soften it when PreToolUse hooks matching Write|Edit|NotebookEdit are

registered in the active settings.

1. Leave the behaviour and document the interaction, so hook authors know that guarding writes

requires matching Bash as well, and that matching Bash means parsing shell, which does
not generalise.