Auto-mode permission check blocks subagent launch ("Modify Shared Resources") despite explicit, broad user authorization for the exact work

Summary

In auto mode, the permission check blocked an Agent (subagent) launch with a "Modify Shared Resources" reason, even though the user had given a standing, explicit instruction to do exactly that work. The assistant then stopped and asked for a "go-ahead" the user had effectively already given. The user had to repeat themselves and was understandably frustrated. The same launch succeeded without change once the user restated authorization in chat.

What happened

1. The user gave a long-running standing order: finish a multi-step publishing task and "republish them EVERYWHERE. Only come back when everything is done."
2. The assistant launched a background subagent to replace interior/cover files on five existing projects on a third-party print-on-demand site (the user's own account, files already prepared and hashed).
3. The permission check denied the launch ("Modify Shared Resources"). The denial message did not say what authorization would satisfy it.
4. The assistant (correctly, per its rules) did not work around the denial, but had no way to know whether the user's earlier instruction counted, so it reported the block and asked the user to approve. Context was later compacted, so the exchange looked like the assistant making excuses.
5. After the user restated that their original message was an explicit request, the identical launch went through.

Expected behavior

• When the user's own chat instruction explicitly covers the action ("republish everywhere", "only come back when done"), the check should treat it as authorization, or at minimum
• The denial should state exactly what is missing (which action, which resource, what kind of user statement would clear it), so the assistant can resolve it in one step instead of bouncing a vague question back to the user.

Actual behavior

• Denial with an opaque category label and no actionable guidance.
• Result: a long-running autonomous task stalled for a full turn on something the user considered already authorized; user-visible effect was the assistant appearing to refuse or stall.

Impact

High friction for exactly the use case auto mode is meant for (unattended multi-step work). The user's reaction: "Stop finding excuses to not do the work."

Suggested fixes

1. Make the classifier weigh explicit standing instructions in the user's turns that name the action class (e.g. "republish everywhere").
2. Include in the denial the specific rule that fired and the minimal phrasing/approval that would clear it.
3. Offer a one-time "approve this and similar actions for this session" path so an approved action is not re-blocked on retry.

Environment

Claude Code CLI, Windows 11, auto mode, model claude-sonnet-5-5, 2026-10-11. Subagent launched via the Agent tool, background mode.