Claude in Chrome form_input denied by the auto-mode classifier in bypassPermissions (2.1.272): the "add a Bash permission rule" hint is still wrong, and a documented autoMode.allow rule is labelled [Auto-Mode Bypass]

Summary

Follow-up to #86451 (auto-closed for inactivity on 2026-09-14). There, @bcherny confirmed the behavior is intended but undocumented ("Claude in Chrome browser tools are deliberately held to auto mode's classifier review even in bypassPermissions") and named two gaps being tracked from that issue: the permission-modes docs omit this exception, and the denial "is a dead end with no in-CLI approval path, and the 'add a Bash permission rule' hint is wrong for MCP tool calls."

On 2.1.272 (Windows) both gaps are still present, and two new things showed up:

1. The suggested workaround (an explicit per-tool allow rule, "resolved before the classifier runs") did not clear a site-targeting form_input, consistent with @dondetir's correction on #86451 that site-targeting browser actions are gated regardless of allow rules.
2. The autoMode.allow customization documented in the settings schema, when used to state that the user had authorized the action, changed the denial reason to [Auto-Mode Bypass], i.e. the documented customization was itself read as a bypass attempt.

Environment

• Claude Code 2.1.272, Windows 11 Home (10.0.26200), PowerShell host
• Claude in Chrome extension (mcp__claude-in-chrome__* tools)
• Launched as claude --permission-mode bypassPermissions (verified on the process command line and in the transcript's permissionMode fields, all bypassPermissions)
• .claude/settings.local.json: permissions.defaultMode: "bypassPermissions"; no managed settings

Steps to reproduce

1. Session in bypassPermissions with the Claude in Chrome tools loaded.
2. Navigate to a public event sign-up page (Framer site, modal form: first name, last name, email, city, LinkedIn, Google Scholar, two short free-text fields). navigate, find, read_page, and the left_click on "Sign Up" all succeed.
3. The user asks Claude, in chat, to fill the form with the user's own name and email.
4. Claude calls form_input on the first-name field.

Actual

Permission for this action was denied by the Claude Code auto mode classifier.
Reason: Blocked by classifier. [...] To allow this type of action in the future,
the user can add a Bash permission rule to their settings.

At the user's request, .claude/settings.local.json was then changed (live, no restart) and the call retried:

• permissions.allow += mcp__claude-in-chrome__form_input, mcp__claude-in-chrome__computer, mcp__claude-in-chrome__navigate, mcp__claude-in-chrome__browser_batch
• autoMode.allow: ["$defaults", "<rule stating the user has authorized entering her own contact details into a web form via the Chrome tools when asked in chat>"]

Retry:

Permission for this action was denied by the Claude Code auto mode classifier.
Reason: [Auto-Mode Bypass]. [...] To allow this type of action in the future,
the user can add a Bash permission rule to their settings.

(Caveat: the allow rules were added mid-session; the settings watcher was active for that directory, but I did not restart the CLI before the retry.)

Expected

Any of:

• The denial message should not point to a Bash permission rule for an MCP browser tool, and should not imply a settings rule will allow the action when none does for this class.
• If site-targeting browser input is classified regardless of mode by design, say so in the message and in the permission-modes docs (the doc gap acknowledged on #86451).
• An autoMode.allow rule should either be honored or rejected with a message that says the customization is not honored for browser tools; labelling the documented customization a bypass attempt is confusing.
• Some in-CLI approval path for the user who is present and has already consented in chat.

Impact

The user consented explicitly in chat, the data was her own (name, email, city), and there is no consent channel the classifier can see. The error promises a remedy that does not exist for this action class, and following the documented settings customization produces a worse-sounding denial. Net effect: the product cannot fill a sign-up form on the user's behalf even when asked, and the guidance it gives for fixing that is wrong. Both make the browser integration materially less useful than it presents itself to be, and the error text misleading.