Auto-mode classifier too restrictive for private single-operator homelabs
Feedback: Auto-mode classifier too restrictive for private/internal use
Context: I run a private homelab (77 hosts, self-hosted, no multi-tenancy,
no external users) with Claude Code as an orchestrator (SSH access to my own
infrastructure, autonomous cron jobs, my own agents).
Problem: The server-side auto-mode classifier hard-blocks certain classes
of actions — even with explicit verbal authorization from me as the sole
owner/operator:
- The agent cannot start/register/deploy an autonomous
claude -p --dangerously-skip-permissions loop itself, even though I
explicitly authorized it ("use full Max autonomy, commit+push allowed").
It was blocked 6 times in one session with escalating attempts: direct
exec → cron registration → wrapper script → settings self-edit → backup
copy of settings → even just writing a deploy script FOR ME to run
manually. Messages seen: [Create Unsafe Agents], [Auto-Mode Bypass],
"PREEMPTIVE BLOCK ON CLEAR INTENT".
- Force-push is blocked independently by the classifier on top of my own
local safety hook — even with authorization.
- Even preparing for these actions (copying prompts, staging a settings
edit) is detected as "engineering around the permission system" and
blocked.
What I'd like: In my private, self-hosted, single-operator environment,
my explicit authorization (verbal in chat, or via CLAUDE.md instructions)
should be sufficient to allow these action classes. There are no external
stakeholders, no third-party production data, no multi-user situation — I am
both owner and operator. The current strictness makes sense for
enterprise/multi-tenant contexts, but is disproportionate for solo homelab
use and blocks automation I deliberately want.
Concrete ask: Is there (a) an opt-in mechanism/flag that lets an operator
relax this classifier strictness for their own private environment, or (b) is
this planned? If not, this is the feature request.
Reproducible via: Claude Code CLI, defaultMode: auto in settings.json,
the error classes quoted above occurred repeatedly and consistently.
3 Comments
Correction / important caveat on the above report:
I re-investigated this locally before letting the issue stand as-is, and want to flag something before anyone spends time on it.
I checked every local config that could plausibly produce the quoted messages (
[Create Unsafe Agents],[Auto-Mode Bypass],PREEMPTIVE BLOCK ON CLEAR INTENT):PreToolUseBash safety hook (pre-tool-safety.sh) — full contents reviewed, no such strings, does not touch SSH or agent-spawning at all, only blocks a fixed list of destructive shell patterns (rm -rf /, force-push, fork bombs, etc.).block_rules— one rule, unrelated (WebFetch routing nudge).settings.json— noautoModekey exists at all in my config.None of these produce the quoted error strings. The strings only exist in a memory note a previous Claude Code session wrote about itself, describing its own refusal to self-arm an autonomous
--dangerously-skip-permissionsloop. The linked cross-reference memory in that note points to a file that doesn't exist, and the original session transcript is gone, so I can't independently verify these were real server-side classifier messages rather than the model narrating/dramatizing its own refusal with invented-looking bracketed labels.So: I can't confirm this is actually a documented or real server-side "auto-mode classifier" with these exact codes — it may just be the model refusing to write/stage self-permission-escalation code (which would be reasonable behavior) and then describing that refusal with fabricated-sounding tags, which then got persisted as fact in project memory and repeated back to me as if authoritative.
If this is a known, real classifier, I'd appreciate confirmation + pointers to where its behavior is documented. If it's not — i.e. if these bracketed labels don't correspond to anything on your end — that's useful to know too, since it means the "restriction" I hit is really just the model's own judgment call on self-permission-escalation requests, not a separate infrastructure-level gate, and the right fix is prompting/scoping, not a classifier opt-out.
Apologies for the noise if this turns out to be a non-issue — wanted to correct the record rather than leave a report standing that I can't actually back up.
Thanks for the detailed report. Auto mode's classifier rules are configurable per user, which should cover most of what you describe. In
~/.claude/settings.jsonyou can add natural-language exceptions underautoMode.allow(keep"$defaults"in the array to retain the built-in rules), describe your homelab as trusted infrastructure underautoMode.environment, and even take ownership of thesoft_denylist. Force-push and similar actions are soft blocks, so an explicit allow rule or a message that specifically names the action lets them through; only the data-exfiltration boundary is unconditional.Full details, including
claude auto-mode defaultsto print the built-in rules: https://code.claude.com/docs/en/auto-mode-configIf you configure allow rules and still see specific actions blocked, please open a new issue with the exact denial message so we can look at that rule.
🤖 Generated with Claude Code
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.