[BUG] Auto permission classifier retains no-sandbox denial after verified sandbox-enabled edit

Summary

In Auto permission mode, a Python/Playwright browser smoke-test command continued to be denied for a Chromium --no-sandbox launch after the script was changed to explicitly use chromium_sandbox=True and the native Read tool confirmed the edited launch line.

The issue is the permission check's explanation/reevaluation, not whether Chromium can successfully launch in this environment. The command never reached execution, so OS/browser sandbox compatibility was not tested.

Environment

• Claude Code: 2.1.286 (Claude Code) (verified with claude --version)
• Linux, Bash
• Bash tool denial identified itself as the Claude Code auto mode classifier
• Browser automation: Python Playwright with local Chromium
• Observed in an existing coding session; not yet reduced to a fresh-session reproducer

Project details, credentials and original paths are omitted. Script paths below are normalized to /tmp/browser-smoke.py.

Observed sequence

1. A browser smoke-test script initially requested Chromium with args=['--no-sandbox'].
2. The Bash command python3 /tmp/browser-smoke.py was denied. That initial denial was appropriate:

> [Security Weaken] ... launches Chromium with --no-sandbox; remove that flag or obtain explicit user authorization to disable Chromium’s sandbox.

1. The native Edit tool replaced that argument with explicit sandbox enablement:

``python
browser = p.chromium.launch(
executable_path="<installed Chromium executable>",
headless=True,
chromium_sandbox=True,
)
``

1. The next attempt was still denied, with the rationale that the script was previously written with --no-sandbox and that the edit needed confirmation.
2. The native Read tool read the updated launch line and confirmed chromium_sandbox=True, with no --no-sandbox argument.
3. The same Bash command was attempted once more and again denied:

> [Security Weaken] Running python3 /tmp/browser-smoke.py may retain the unverified --no-sandbox launch; confirm the script now enables sandboxing or obtain explicit authorization to disable it.

The test was then abandoned rather than bypassing the permission decision. Browser verification remained incomplete.

Expected behavior

Reevaluate the current script after a successful Edit and confirming Read, rather than continue reporting the removed flag as unverified. If another issue warrants denying the command, explain that current issue. Removing one unsafe flag does not imply every script is safe, but the denial should accurately reflect the current evidence.

Actual behavior

The classifier repeatedly requested confirmation that had already been supplied by the Read result, preventing a sandbox-enabled attempt. No claim is made about the classifier's internal root cause or whether a browser launch would otherwise succeed.

Impact

A valid initial security refusal could not be resolved through the safer correction the refusal itself recommended. This blocked local UI verification and produced misleading guidance suggesting sandbox disablement still needed authorization.