[BUG] Claude cli repeatedly ignoring no-prompts by generating intermediate files

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 have repeatedly run into cases where my skill was completely tested end-to-end with right allowlist and right set of permissions and subsequent runs, claude cli decided to change how the skill was executed by either generating intermediate files which were NEVER in the original skill or trying to execute compound command (a leading VAR=$(...) assignment plus the real command which again was never in the skill.

THis results in NOT INTENDED back and forth on skills which were supposed to be single command and done.

Impact: Skills that ship multi-line bash (the common case — set a var, then call a tool) guarantee "no interaction" and were tested repeatedly to ensuire that but violate it in practice. The agent also can't distinguish an auto-deny from a manual reject in the tool-result feedback, so it retries variants instead of recognizing a policy mismatch — which is what turned this into a long and extremely frustrating back-and-forth.

Suggested fix: Evaluate allowlist rules per-statement in a compound command (or at least match the trailing pipeline stage), and/or surface to the agent why a call was denied so it can stop retrying.

What Should Happen?

A Bash call should be auto-approved whenever the command it actually runs is covered by an allow rule — regardless of whether it's wrapped in a compound (VAR=$(...); allowed-cmd …) or piped (allowed-cmd … | jq). Concretely, the permission engine should evaluate each statement/pipeline stage against the allowlist rather than prefix-matching the whole string. If any stage isn't covered (e.g. echo, an un-allowlisted helper), prompt only for that stage — don't fail the whole command.

And the secondary fix: when a call is denied, the tool result should tell the agent it was a policy/permission denial (and which rule was missing), not the ambiguous "user doesn't want to proceed." That signal is what lets the agent stop retrying variants and instead say "this needs an allowlist entry" — which is exactly where this run went sideways.

Net effect: a skill that documents "runs with no interaction" and whose commands are allowlisted actually runs with no interaction.

Error Messages/Logs

Steps to Reproduce

Repro:

1. Allowlist Bash(mytool run:*) in settings.
2. Have the agent run, as one tool call: ARG=$(othertool --get-arg) mytool run --arg "$ARG"
3. Expected: no prompt (the mytool run statement is allowlisted). Actual: approval prompt every time, because the

compound string doesn't match the prefix.

1. . Same for mytool run ... | jq '.' and for statements led by echo when echo isn't allowlisted.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.212

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_