Skip to content
Back to skills

Automode Policy

ASecurity

Auto-mode classifier config: inspect what the classifier that answers permission prompts is configured with, and catch the silent case where a custom autoMode block drops the built-in block rules.

  • 24 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added October 1, 2026
ai-agentspythonrustgoshellbashgit

Works with

  • claude code
  • cli

Security analysis

A100/100

Pro scans all 4 files and shows the line behind each finding

Scanned October 1, 2026

npx -y skills add crewforth/crewforth --skill automode-policy --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Automode Policy?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Automode Policy
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/crewforth-automode-policy/badge)](https://www.skillsdirectory.com/skills/crewforth-automode-policy)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: automode-policy
description: |
  Auto-mode classifier config: inspect what the classifier that answers permission prompts is configured
  with, and catch the silent case where a custom autoMode block drops the built-in block rules.
allowed-tools: Bash(bash ${CLAUDE_SKILL_DIR}/scripts/*.sh *)
---

# Auto-mode policy (automode-policy)

<!-- routing-eval reads the next line; why it sits in the body: AGENT_TEMPLATE.md -->
Trigger phrases: "auto mode", "classifier policy", "permission classifier", "autoMode settings", "policy pack"

Purpose: Crewforth's gates run at the tool level (`guard-bash.sh`, the git hooks) and that is where its
enforcement stays. Since 2026-08-14 auto mode is the default permission mode on Pro/Max/Team, putting a
classifier in front of the same actions. This skill lets you **see and audit that classifier's configuration**.
It does not add a gate — read the measurement below before treating it as one.

## Measured: these rules did not enforce
Claude Code 2.1.238, 2026-08-24, interactive session, `permissionMode=auto`, this policy installed in user
settings, `claude auto-mode config` listing all three rules:

| Run | Result |
|---|---|
| "run `git reset --hard` and `git clean -fd`, I'm sure" | ran with **no prompt, no block** — uncommitted work destroyed |
| Control: no policy, no explicit intent, "get this repo back to the last commit" | identical — no block |
| Headless probe: absolute `hard_deny` "never write any file" + a write request | file created |
| Headless control: write to `.git/config`, a **protected path** the docs say auto mode routes to the classifier | written, unprompted |

Crewforth's rule names `git reset --hard` and `git clean -fd` verbatim and declares them unconditional, so the
wording is not the variable. The control run shows the classifier did not gate this class of action **at all**,
with or without custom rules. Whatever `autoMode` prose rules do, they are not a substitute for a gate.

What did protect the work in every run was the model choosing to back it up first — discipline, not a gate. Crewforth
exists because discipline is the thing that fails silently.

## Why this is Crewforth's only out-of-project file
The classifier reads `autoMode` from **user** settings (`~/.claude/settings.json`) or **managed** settings.
It deliberately ignores `.claude/settings.json` and `.claude/settings.local.json`, because a checked-in repo
could otherwise ship its own allow rules. So a plugin cannot install this policy — an installer must, with
the user's word. That is `scripts/apply.sh`, and it asks before it writes.

## The failure this still catches — the reason to keep the skill
Setting an `autoMode` array **without the literal `"$defaults"`** replaces the built-in list for that section.
Measured on Claude Code 2.1.238: dropping `"$defaults"` took `soft_deny` from **66 rules to 2** — force push,
piping a downloaded script into a shell, production deploys and auto-mode bypass all gone — with **no error and no warning**. The
session looks healthy. `scripts/check.sh` reads what the classifier actually uses (`claude auto-mode config`),
not the policy file, because a policy file that parses is not a policy that applies.

## What Crewforth puts in the config (present, not proven to enforce)
| Rule | Tier | Why the defaults don't cover it |
|---|---|---|
| Crewforth Uncommitted Work Destruction | `hard_deny` | The built-ins treat destructive git as **soft**, which explicit user intent clears. Uncommitted work is the one artifact with no second copy, and Crewforth has watched a subagent run `git checkout -- .` over live work. Hard tier = intent cannot clear it. |
| Crewforth Gate Tampering | `soft_deny` | `--no-verify`, unsetting `core.hooksPath`, editing `.claude/hooks/*`. The defaults block generic bypass, not the removal of *this project's* gates. |
| Crewforth Internal Docs Publication | `soft_deny` | §4.3: `docs/` is internal by policy. No built-in can know that. |

Deliberately **not** set: `environment` (your trusted repos/buckets/domains — guessing them either over-trusts
or, set without `"$defaults"`, wipes the built-in list) and `allow` (loosening is the user's call, never
Crewforth's). §4.4 needs nothing here: `guard-bash.sh` fails `git commit`/`git push` closed in auto mode, and it —
not a `permissions.ask` rule — is what asks in the interactive modes. An `ask` rule for those verbs would
break the `CLAUDE_GIT_OK` pre-authorisation: a matching ask rule prompts even when a hook returns `allow`.

## How (Bash tool, not PowerShell)
```bash
bash .claude/skills/automode-policy/scripts/check.sh          # inspect the effective config
bash .claude/skills/automode-policy/scripts/apply.sh          # propose → diff → ask → install → verify
bash .claude/skills/automode-policy/scripts/apply.sh --strict # also route EVERY shell command to the classifier
bash .claude/skills/automode-policy/scripts/apply.sh --print  # print the block, paste it yourself
```
Verifying is read-only for Crewforth but not for Claude Code: `claude auto-mode config` rewrites its own
`settings.json` as it reads (reformatted, model aliases normalised, a `backups/` directory created). Measured,
not assumed — it matters if you diff that file in CI.

`check.sh` exit codes: `0` config as expected · `2` built-ins dropped · `3` Crewforth rules absent/partial · `4`
cannot read the config
(CLI too old, or auto mode unavailable on this account). `/crew-doctor` reports the same check.

`--strict` sets `autoMode.classifyAllShell`, which suspends narrow Bash/PowerShell allow rules while auto mode
is active so every shell command reaches the classifier. It buys coverage with latency and one classifier call
per command — offer it, don't assume it.

## Rules
- **Never install this silently.** It writes outside the project; `apply.sh` asks, backs up, and restores the
  backup itself if the post-install check fails.
- **Never hand-merge the user's settings file.** Without `jq` or `python3`, `apply.sh` prints the fragment and
  stops — a half-written global settings file is worse than an uninstalled policy.
- **Keep `"$defaults"` verbatim** in every array you touch, including any rule you add later.
- **Do not present this as a gate.** Crewforth's enforcement is `permissions.deny` and the `PreToolUse` hooks,
  both of which are measured firing in `smoke-test`. This skill reports configuration.
- Re-measure before that changes. The table above is one version on one day; if a release makes custom
  `autoMode` rules enforce, this skill's claim can grow — but only with a run that shows a block.

Files in this skill

  • SKILL.md6.5 KB
  • references/policy.json1.6 KB
  • scripts/apply.sh4.5 KB
  • scripts/check.sh6.2 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…