Auto-mode permission classifier over-blocks an explicitly-authorized tool call in a multi-task prompt

Summary

In a single prompt that batches several independent tasks, the auto‑mode permission classifier denied a tool call that the prompt explicitly authorized, because it appears to infer one scope for the whole prompt from the other tasks (which were constrained to "local edits only, no deploys"). The explicit per‑task instruction to perform the action was not given controlling weight.

Environment

• Claude Code CLI, auto (default) permission mode
• macOS

Repro (sanitized)

1. Send one prompt containing several labeled, independent tasks. Most are constrained (e.g. "local config edits only", "do not deploy anything"). One task explicitly instructs a read‑only remote command (e.g. "pull record X and show it to me").
2. The agent attempts the explicitly‑instructed read‑only command.

Expected

A read‑only action that the prompt explicitly requests should be allowed (or prompted on its own merits). Constraints attached to sibling tasks in the same prompt should not retroactively narrow the scope of a different, explicitly‑authorized task.

Actual

The call was denied. The denial reason paraphrased the constraints of the other tasks ("the task only involved local config edits and explicitly forbade deploys") and concluded the action was out of scope — even though a different task in the same prompt explicitly requested it.

Notably, when the user re‑stated the same authorization in a follow‑up turn, the identical command was allowed. That strongly suggests this is a scope‑attribution miss in multi‑task prompts, not an intentional policy block.

Impact

Forces an extra user round‑trip to re‑authorize an action the prompt already authorized. Mild but recurring whenever a single prompt mixes constrained and unconstrained tasks.

Suggested fix

• Attribute scope per task in multi‑task prompts rather than collapsing the prompt to one inferred scope.
• Treat an explicit in‑prompt instruction to perform a specific action as authorization for that action, not overridable by constraints attached to sibling tasks.
• Optionally surface which span of the prompt drove the scope inference, so the user can correct it without a full re‑prompt.