[BUG] False positive Ask prompt in sandbox auto-allow for python3 -c with inline # comments

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

I ran a python3 -c command with a multiline string containing a standard Python # comment.

Claude displayed an Ask prompt with the warning:

Newline followed by # inside a quoted argument can hide arguments from path validation

This occurred even though sandbox is enabled with auto-allow for bash commands (/sandbox → auto-allow mode).

What Should Happen?

In sandbox auto-allow mode, this command should execute without an Ask prompt. The # character is a standard Python comment inside a quoted string argument, not a shell argument-hiding technique. The sandbox already provides OS-level filesystem and network isolation, making the additional Ask prompt redundant.

Error Messages/Logs

Newline followed by # inside a quoted argument can hide arguments from path validation

Steps to Reproduce

1. Enable sandbox with auto-allow: run /sandbox and select auto-allow mode

Test 1 — Ask appears (false positive):
python3 -c "
print('a')

comment

print('b')
"
Result: Ask prompt displayed with "Newline followed by #" warning.

Test 2 — No Ask (control, no #):
python3 -c "
print('a')
print('b')
"
Result: Executes immediately, no Ask prompt.

Test 3 — No Ask (control, # in file):
cat > /tmp/test_comment.py << 'EOF'
print('a')

comment

print('b')
EOF
python3 /tmp/test_comment.py
Result: Executes immediately, no Ask prompt.

Isolation note: Each test was run in a separate session turn (after the previous response completed). This behavior occurs consistently across multiple runs.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.94

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

This behavior suggests that a heuristic may be matching \n# inside quoted arguments to detect potential shell argument hiding. However, this pattern is common in legitimate python3 -c usage, where # is simply a Python comment character. The same content in a .py file does not trigger the warning.

This creates practical friction: in sandbox auto-allow mode, the user expects uninterrupted execution for safe commands. Frequent false positives for routine Python one-liners can lead to approval fatigue, reducing the signal value of the prompt when it does flag genuinely risky commands.

One possible direction: when the # appears inside a quoted string argument to an interpreter (python3 -c, ruby -e, etc.), it is likely a language-level comment rather than a shell argument-hiding vector.