Auto-mode classifier blocks routine API POST with no way to grant standing permission; !-prefix input hard-wraps long lines

Summary

Two separate friction points hit in the same session while doing routine homelab infrastructure automation (launching a self-hosted Ansible Automation Platform job template via its REST API to provision/destroy a VM — an action the user has performed many times before through this exact automation).

Issue 1: auto-mode classifier blocks a routine API call with no available path to permit it

• Calling Bash to run curl -X POST ... /api/.../launch/ against the user's own self-hosted automation server was blocked by "the Claude Code auto mode classifier," with no further detail on why.
• The project's .claude/settings.local.json already contains an unconditional "Bash(curl *)" allow rule — so the block is happening at a layer above the standard Bash permission allow-list, and adding more Bash rules cannot fix it.
• The user then explicitly approved the action in conversation ("go ahead, apply both" earlier in the session; "yeah sure lets try it" for this specific action) — explicit human approval in-chat did not clear the block either.
• Attempting to use the built-in update-config skill to add a permission rule for this action was also blocked by the same classifier, so there was no self-service path at all to grant standing permission — the assistant could not even configure a fix, only report that it was stuck.
• The only way to actually perform the action was for the human to run the exact same curl command themselves via the ! prefix (run-in-session) — meaning the block adds friction without adding safety, since the human can trivially do the identical thing.

Ask: please provide a real path to grant standing permission for this class of action (e.g. a documented settings key, or having the classifier respect an explicit in-conversation approval), and make the block reason specific enough to actually act on.

Issue 2: the !-prefix (run in session) input mechanism hard-wraps long single lines, breaking commands

• Typing/pasting a single logical shell command longer than roughly 70-72 characters into the ! prefix input caused it to be split across multiple literal lines mid-token (e.g. splitting rhel_version into rhe + newline + l_version), which bash then interpreted as multiple separate broken commands instead of one.
• This happened even inside a heredoc (cat > file << 'EOF' ... EOF) — the wrapping injected leading whitespace onto the EOF terminator line itself, so bash never recognized the delimiter and the heredoc consumed to end-of-input instead.
• Workaround found: write the command/payload to a file first via the assistant's own file-write tool (not through !), then have the human run a short command (well under the wrap width) that references the file. This works but is a significant, non-obvious detour for anything beyond a trivial one-liner.

Ask: either don't hard-wrap !-prefix input (treat it as one logical line/paste even if the terminal displays it wrapped), or make heredoc terminator matching tolerant of injected leading whitespace from the wrap.

Impact

Both issues combined turned a routine, previously-proven-safe automation task (provision a throwaway VM, several times run before) into a long back-and-forth requiring multiple manual workarounds from the user, for an action that carried effectively no risk beyond what the user could already do unassisted in one command.