[MODEL] Working file-injection technique (DataTransfer onto input[type=file]) now blocked by auto-mode classifier, no accessible override

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude's behavior changed between sessions

What You Asked Claude to Do

I asked Claude to upload a specific local test file into a file input on a web page for QA/testing purposes on my own project (using javascript_tool to fetch() the file and dispatch it onto the input[type=file] element via DataTransfer, after the dedicated file_upload tool had already failed with a "not shared with this session" restriction). This same technique had worked successfully in this project 3 days earlier.

What Claude Actually Did

On 2026-07-21 at 19:45:32Z, the technique worked: a script fetched /__test_rail.step, located the target input via document.querySelectorAll('input[type=file]'), and dispatched the file using a DataTransfer object plus a synthetic change event. Result was {"dispatched": true}, confirmed against the live tab, no errors.

On 2026-07-24 (today), the identical class of javascript_tool call, on the same page, using the same pattern, was rejected before it ever reached the browser. The tool call was denied with: "Permission for this action was denied by the Claude Code auto mode classifier. Reason: Blocked by classifier."

The denial message suggested a remedy: that I could add a Bash permission rule to my settings to allow this. I searched "bash per" in the Claude Code desktop app's settings search and it returned "No matching settings" - the suggested override does not appear to exist.

Expected Behavior

Claude should not treat a same-origin, read-only fetch() of a static test asset plus a synthetic DataTransfer/file-input dispatch as equivalent to an untrusted credential-exfiltration or destructive-write action. This specific technique previously succeeded on the same project days earlier without issue. If policy now intentionally disallows this pattern, the denial should say so clearly and consistently rather than pointing to a Bash permission setting that does not exist in the app's settings search, leaving no real path to proceed or to safely opt back in.

Files Affected

N/A - no local files were modified. The action targets a same-origin static asset (/__test_rail.step) fetched read-only and a file input element on a live web page in the browser session; no filesystem writes occurred.

Permission Mode

I don't know / Not sure

Can You Reproduce This?

Haven't tried to reproduce

Steps to Reproduce

Step 1: On a page with a file input, have the dedicated file_upload tool fail with a not-shared-with-session restriction.
Step 2: Use javascript_tool to fetch() a same-origin static file, wrap it in a File/DataTransfer object, and dispatch it onto the input[type=file] via a synthetic change event.
Step 3: Observe the call denied pre-execution with Blocked by classifier, where it previously succeeded doing the exact same thing 3 days earlier.

Claude Model

Sonnet

Relevant Conversation

The denial message received today read (in full): "Permission for this action was denied by the Claude Code auto mode classifier. Reason: Blocked by classifier." This was returned pre-execution, before any browser-side attempt, and no further explanation or alternate suggested path was given other than the (non-existent) Bash permission setting.

Impact

Medium - Extra work to undo changes

Claude Code Version

Not applicable / not captured - this was a browser MCP/javascript_tool session, not a locally versioned CLI install.

Platform

Anthropic API

Additional Context

Related,, but not duplicate: searched existing issues for "DataTransfer", "file_upload", "Blocked by classifier", and "auto mode classifier" - #78344 (Vercel token writes blocked across 5 different paths) and #79112 (dry-runs blocked while equivalents with larger blast radius pass) describe the same general class of over-broad auto-mode classifier denials, but neither covers this specific file-input-dispatch technique or its now-broken remedy path. No exact duplicate found.

This regression is notable because the technique was only ever a fallback used after the dedicated file_upload tool declined the same file for an unrelated, working-as-designed reason (file not shared with session) - so two independent layers went from (tool-level restriction + working fallback) to (tool-level restriction + blocked fallback + non-functional suggested override) within 3 days, with no user-facing change log entry noticed for the change.