Bash(sed *) runs without permission prompt despite not being in read-only built-in set

Summary

sed invocations execute without a permission prompt in the default permission mode, even though sed is documented as NOT being a read-only built-in command. This is a regression / silent expansion of the auto-allowed Bash command set.

Environment

• Claude Code: 2.1.126
• macOS: 26.3.1 (Darwin 25.3.0)
• Permission mode: default (no --dangerously-skip-permissions, no acceptEdits, no plan mode)

Expected behavior

Per the permissions documentation:

Commands with write-capable or exec-capable flags, such as find, sort, sed, and git, still prompt when an unquoted glob is present because the glob could expand to a flag like -delete.

Bare sed -n '1,3p' README.md should prompt the user before executing — sed -i can edit files in place, and an unquoted argument could in principle expand to a flag.

Actual behavior

sed -n '1,3p' README.md 2>/dev/null || sed -n '1,3p' CLAUDE.md runs silently, no prompt presented to the user.

Configuration

No Bash(sed *), Bash(sed:*), or any wildcard that subsumes sed is present in:

• ~/.claude/settings.json (user)
• <project>/.claude/settings.json (project)
• <project>/.claude/settings.local.json (project-local)

/permissions UI confirms: searching "sed" in the allow list returns empty. No ask or deny rules configured.

User-level settings allow list (relevant subset, no sed wildcards):

Bash(grep *), Bash(awk *), Bash(ls *), Bash(pdftotext *), Bash(pdfinfo *),
Bash(unzip *), Bash(mdls *), Bash(shasum *), Bash(brew install *),
Bash(brew list *), Bash(pip3 install *), Bash(pip3 list *),
Bash(ruff check *), Bash(curl *), Bash(mkdir -p *), Bash(git *),
Bash(gh issue *), Bash(gh pr view *), Bash(gh pr list *),
Bash(gh pr checks *), Bash(gh repo view *), Bash(gh label *)

No defaultMode field set; no enterprise managed-settings file; no in-session "don't ask again" approval (verified via /permissions UI).

Reproduction

1. Start fresh Claude Code session in any directory containing a readable file (e.g., README.md).
2. Verify /permissions allow list has no Bash(sed*) entry.
3. Have Claude run sed -n '1,3p' README.md.
4. Observe: command runs without prompt.

Same behavior reported from a prior session, suggesting it's not in-session-cache-related.

Impact

sed -i can modify files in place. Silent execution defeats the purpose of the permission gate for a write-capable command. Users who rely on the prompt as a "don't use sed when Edit/Write would do" reminder lose that affordance.

Possible root cause

sed with read-only-looking flags (e.g., -n print-only) may be misclassified as read-only by the harness's command classifier. The classifier should treat sed as write-capable regardless of flags, per the documented design.

Workaround

Adding Bash(sed *) to permissions.ask should force a prompt — but users shouldn't have to opt in to documented default behavior.