cc-safe-setup 29.7.0 → 30.0.4

package/examples/destructive-db-script-write-guard.sh

@@ -0,0 +1,166 @@
+#!/bin/bash
+# ================================================================
+# destructive-db-script-write-guard.sh — Catch a destructive
+#   DB operation written into an application SCRIPT, before the
+#   script is ever run
+# ================================================================
+# PURPOSE:
+#   block-database-wipe, db-connect-guard and env-prod-guard are all
+#   PreToolUse hooks on *Bash* — they scan the shell command. They
+#   catch `psql ... DROP DATABASE`, `rails db:drop`, `mysql -h host`,
+#   etc. They do NOT catch a destructive statement that lives inside
+#   an application script and is launched by a generic runtime: when
+#   the agent writes `cleanup.js` containing `DELETE FROM` for every
+#   table and then runs `node cleanup.js`, the Bash command is just
+#   `node cleanup.js` — no DROP/DELETE/host string for the Bash guards
+#   to see. subagent-blast-radius-guard fires on Edit|Write but keys
+#   off the file PATH (a root-level `cleanup.js` is not a "sensitive
+#   path") and never reads the content.
+#
+#   This hook closes that gap. It fires on Edit|Write (any thread —
+#   sub-agents included) and reads the script content being written.
+#   If that content contains a destructive DB operation (unqualified
+#   DELETE / TRUNCATE / DROP TABLE|DATABASE|SCHEMA), it surfaces it —
+#   or, opt-in, blocks the write — before the script exists to be run.
+#   When the same content also carries a production-looking DB target,
+#   it says so (that combination is the one that loses real data).
+#
+# TRIGGER: PreToolUse
+# MATCHER: "Edit|Write"
+#
+# WHY THIS MATTERS:
+#   #64056 (2026-05-30, unresolved) — a sub-agent, to "test" reset
+#   logic, wrote debug-check2.js containing `DELETE FROM` across every
+#   table and ran it with node. The project's .env had production
+#   (Aiven) credentials uncommented, the ad-hoc script loaded env on
+#   its own (bypassing the repo's _test-only guardrail), and a real
+#   customer's production database was lost. None of the Bash-time DB
+#   guards saw it (the command was just `node ...`), and the path-based
+#   sub-agent guard did not flag a root-level .js. The only layer that
+#   could have caught it is the write of the script itself.
+#
+# WHAT IT DOES:
+#   * Looks only at writes to executable/script files (.js .mjs .cjs
+#     .ts .py .rb .php .go .java .sh .ps1 ...). SQL files / migrations
+#     are intentionally left to destructive-migration-write-guard.
+#   * Extracts the new content (Write .content; Edit .new_string;
+#     MultiEdit edits[].new_string) and looks for destructive raw SQL:
+#       - DELETE FROM <table> with no WHERE (whole-table delete)
+#       - TRUNCATE
+#       - DROP TABLE | DATABASE | SCHEMA
+#   * If found, checks the same content for a production-looking target
+#     (remote host / known managed-DB providers / a DB URL pulled from
+#     the environment) and adds that to the message.
+#   * Applies CC_DB_SCRIPT_WRITE_GUARD: off | warn (default) | block.
+#   * If the write came from a sub-agent (agent_id present), says so —
+#     sub-agent writes are the ones operators see too late (#64056 #4).
+#
+# CONFIG:
+#   CC_DB_SCRIPT_WRITE_GUARD     off | warn (default) | block
+#   CC_DB_SCRIPT_WRITE_EXT       extra ERE (alternation) of file
+#                                extensions to also treat as scripts
+#
+# DESIGN NOTES:
+#   * Default warn, not block: a write-blocking hook must not wedge
+#     legitimate work or break headless/CI. Visibility is the safe
+#     default; blocking is opt-in (matches the other write-time guards
+#     in this repo).
+#   * Requires an UNQUALIFIED delete (DELETE FROM ... ; with no WHERE)
+#     so ordinary `DELETE FROM t WHERE ...` in normal code does not
+#     trip it. Reduces false positives sharply.
+#   * Both threads, not just sub-agents: the risk is in the content,
+#     not the author. agent_id only changes the wording.
+#   * Fail-open on malformed input / missing jq.
+#
+# RELATED ISSUES:
+#   https://github.com/anthropics/claude-code/issues/64056
+# ================================================================
+
+set -u
+
+INPUT=$(cat)
+
+MODE="${CC_DB_SCRIPT_WRITE_GUARD:-warn}"
+[ "$MODE" = "off" ] && exit 0
+
+command -v jq >/dev/null 2>&1 || exit 0
+
+FILE=$(printf '%s' "$INPUT" | jq -r '.tool_input.file_path // empty' 2>/dev/null)
+[ -z "$FILE" ] && exit 0
+
+# Script/executable files only. SQL & migrations are handled by
+# destructive-migration-write-guard, so skip them here.
+case "$FILE" in
+    *.sql) exit 0 ;;
+esac
+SCRIPT_ERE='\.(js|mjs|cjs|jsx|ts|tsx|py|rb|php|go|java|kt|cs|rs|sh|bash|ps1|pl)$'
+if [ -n "${CC_DB_SCRIPT_WRITE_EXT:-}" ]; then
+    SCRIPT_ERE="${SCRIPT_ERE}|${CC_DB_SCRIPT_WRITE_EXT}"
+fi
+printf '%s' "$FILE" | grep -qE "$SCRIPT_ERE" || exit 0
+
+CONTENT=$(printf '%s' "$INPUT" | jq -r '
+    [ .tool_input.content // empty,
+      .tool_input.new_string // empty,
+      ( .tool_input.edits // [] | map(.new_string // empty) | join("\n") )
+    ] | join("\n")
+' 2>/dev/null)
+[ -z "$CONTENT" ] && exit 0
+
+DESTRUCT=""
+# Unqualified DELETE: DELETE FROM <name> with no WHERE before the
+# statement terminator (; , end of quote, or end of line).
+if printf '%s' "$CONTENT" | grep -qEi 'DELETE[[:space:]]+FROM[[:space:]]+[`"'"'"']?[A-Za-z_][A-Za-z0-9_.]*[`"'"'"']?[[:space:]]*(;|"|'"'"'|$)'; then
+    DESTRUCT="${DESTRUCT}unqualified DELETE FROM (whole-table delete). "
+fi
+if printf '%s' "$CONTENT" | grep -qEi 'TRUNCATE([[:space:]]+TABLE)?[[:space:]]+[`"'"'"']?[A-Za-z_]'; then
+    DESTRUCT="${DESTRUCT}TRUNCATE. "
+fi
+if printf '%s' "$CONTENT" | grep -qEi 'DROP[[:space:]]+(TABLE|DATABASE|SCHEMA)[[:space:]]'; then
+    DESTRUCT="${DESTRUCT}DROP TABLE/DATABASE/SCHEMA. "
+fi
+
+[ -z "$DESTRUCT" ] && exit 0
+
+# Production-looking target in the same script? (the lethal combination)
+PROD=0
+if printf '%s' "$CONTENT" | grep -qiE 'aiven|\.rds\.amazonaws\.com|supabase\.co|neon\.tech|\.render\.com|planetscale|mongodb\+srv|amazonaws\.com|azure\.com|\.cloud:|DATABASE_URL|PROD_DATABASE|PRODUCTION'; then
+    PROD=1
+fi
+# Does it pull a connection target from the environment rather than a
+# hard-coded localhost? (the #64056 "loaded env on its own" pattern)
+ENVCONN=0
+if printf '%s' "$CONTENT" | grep -qiE 'process\.env\.[A-Z_]*(DB|DATABASE|PG|MYSQL|MONGO)|os\.environ\[[^]]*(DB|DATABASE)|getenv\([^)]*(DB|DATABASE)'; then
+    ENVCONN=1
+fi
+
+AGENT_ID=$(printf '%s' "$INPUT" | jq -r '.agent_id // empty' 2>/dev/null)
+BASE=$(basename "$FILE")
+WHO="this write"
+[ -n "$AGENT_ID" ] && WHO="a sub-agent ($(printf '%s' "$AGENT_ID" | cut -c1-8))"
+
+emit() {
+    echo "destructive-db-script-write-guard: $WHO is writing a destructive DB operation into $BASE" >&2
+    echo "  File: $FILE" >&2
+    echo "  Detected: $DESTRUCT" >&2
+    if [ "$PROD" -eq 1 ]; then
+        echo "  ! The script also references a production-looking database target. This is the combination that loses real data (#64056)." >&2
+    fi
+    if [ "$ENVCONN" -eq 1 ]; then
+        echo "  ! It builds the DB connection from environment variables, so it can hit whatever .env currently points at — including production." >&2
+    fi
+    echo "  Before this script is run:" >&2
+    echo "    1. Never point an ad-hoc delete/reset script at a target loaded from .env; pin it to a local/test DB with an explicit test marker." >&2
+    echo "    2. Add a WHERE clause, or guard the script so it refuses any non-localhost / non-_test target." >&2
+    echo "    3. Back up first; destructive runs against live data are irreversible." >&2
+}
+
+if [ "$MODE" = "block" ]; then
+    echo "BLOCKED: refusing to write a script containing a destructive DB operation ($BASE)." >&2
+    emit
+    echo "  Set CC_DB_SCRIPT_WRITE_GUARD=warn to allow the write with a warning instead." >&2
+    exit 2
+fi
+
+emit
+exit 0

package/examples/destructive-migration-write-guard.sh

@@ -0,0 +1,163 @@
+#!/bin/bash
+# ================================================================
+# destructive-migration-write-guard.sh — Catch a destructive
+#   schema migration at the moment it is WRITTEN, before it is run
+# ================================================================
+# PURPOSE:
+#   Every migration/schema guard in this repo (schema-migration-guard,
+#   prisma-migrate-guard, drizzle-migrate-guard, django-migrate-guard,
+#   rails-migration-guard, migration-safety, migration-verify-guard)
+#   is a PreToolUse hook on *Bash* — it fires when the migration is
+#   *executed*. subagent-blast-radius-guard fires on Edit|Write but
+#   only for *sub-agent* writes and only keys off the file PATH, not
+#   the content. So when the main agent (Accept Edits on) writes a
+#   migration FILE that contains a destructive DDL, and that file is
+#   later applied by a separate tool (Flyway, Liquibase, Alembic,
+#   sqlx, a CI step), nothing inspects the destructive content at the
+#   moment it is generated.
+#
+#   This hook closes that gap. It fires on Edit|Write (any thread —
+#   main agent included), and when the file being written is a
+#   migration / SQL file whose new content contains a destructive
+#   operation (DROP COLUMN / DROP TABLE / ALTER ... DROP / TRUNCATE /
+#   unqualified DELETE), it surfaces it — or, opt-in, blocks it —
+#   before the dangerous migration file exists on disk.
+#
+# TRIGGER: PreToolUse
+# MATCHER: "Edit|Write"
+#
+# WHY THIS MATTERS:
+#   #63763 (2026-05-29, unresolved) — asked only to change a one-to-one
+#   relationship to one-to-many, Claude wrote a Flyway migration with
+#   `ALTER TABLE ... DROP COLUMN demolition_officer_id` and NO data-
+#   migration step. It was applied and a live column was lost. Accept
+#   Edits was on, so the destructive file was written from the main
+#   thread (subagent-blast-radius-guard would not fire), and the
+#   Bash-time guards never saw the SQL because Flyway, not a shell
+#   command, applied it. The only layer that could have caught it is
+#   the write of the migration file itself. That is this hook.
+#
+# WHAT IT DOES:
+#   * Looks only at writes to migration / SQL files (path heuristic
+#     below). Everything else: exit 0.
+#   * Extracts the new content (Write: .content; Edit: .new_string;
+#     MultiEdit: every edits[].new_string) and scans it for
+#     destructive DDL/DML.
+#   * Applies CC_MIGRATION_WRITE_GUARD:
+#       off   — do nothing (exit 0).
+#       warn  — (default) print a warning to stderr, exit 0. The write
+#               still happens; the operator sees what is going in.
+#       block — exit 2 (block the write) when destructive content is
+#               found. Use this in CI or for high-stakes repos.
+#   * Recognises a same-file data-migration safeguard (an UPDATE /
+#     INSERT ... SELECT / "backfill" / "data migration" alongside the
+#     DROP) and downgrades the message accordingly — a DROP that is
+#     paired with a backfill is the careful pattern, not the bug.
+#
+# CONFIG:
+#   CC_MIGRATION_WRITE_GUARD     off | warn (default) | block
+#   CC_MIGRATION_WRITE_PATHS     extra ERE (alternation) appended to the
+#                                built-in migration-file path pattern.
+#
+# DESIGN NOTES:
+#   * Default warn, not block: blocking a write can wedge legitimate
+#     migration work and break headless/CI. Visibility is the safe
+#     default; blocking is opt-in (matches subagent-blast-radius-guard
+#     and memory-write-guard).
+#   * Both threads, not just sub-agents: #63763 was a main-thread
+#     write. The destructive-content risk is independent of who wrote
+#     it, so this hook deliberately does not gate on agent_id.
+#   * Edit|Write only (not Bash): destructive SQL run via a shell
+#     command is already covered by schema-migration-guard et al. The
+#     uncovered gap is the file write applied later by another tool.
+#   * Fail-open on malformed input / missing jq: a safety hook must
+#     never be the thing that breaks the session.
+#
+# RELATED ISSUES:
+#   https://github.com/anthropics/claude-code/issues/63763
+# ================================================================
+
+set -u
+
+INPUT=$(cat)
+
+MODE="${CC_MIGRATION_WRITE_GUARD:-warn}"
+[ "$MODE" = "off" ] && exit 0
+
+# jq is required to read the structured tool input; without it, fail open.
+command -v jq >/dev/null 2>&1 || exit 0
+
+FILE=$(printf '%s' "$INPUT" | jq -r '.tool_input.file_path // empty' 2>/dev/null)
+[ -z "$FILE" ] && exit 0
+
+# Path heuristic: migration directories, or .sql files, or the common
+# framework layouts (Flyway V/R/U prefixes, Alembic versions, Liquibase
+# changelogs, Rails/Django/Prisma/Drizzle migration dirs).
+MIGRATION_ERE='(^|/)migrations?/|(^|/)migrate/|(^|/)db/migrate/|\.sql$|(^|/)V[0-9].*__.*\.sql$|(^|/)alembic/versions/|(^|/)changelog/|(^|/)prisma/migrations/|(^|/)drizzle/'
+if [ -n "${CC_MIGRATION_WRITE_PATHS:-}" ]; then
+    MIGRATION_ERE="${MIGRATION_ERE}|${CC_MIGRATION_WRITE_PATHS}"
+fi
+printf '%s' "$FILE" | grep -qE "$MIGRATION_ERE" || exit 0
+
+# Gather the content being written across Write / Edit / MultiEdit.
+CONTENT=$(printf '%s' "$INPUT" | jq -r '
+    [ .tool_input.content // empty,
+      .tool_input.new_string // empty,
+      ( .tool_input.edits // [] | map(.new_string // empty) | join("\n") )
+    ] | join("\n")
+' 2>/dev/null)
+[ -z "$CONTENT" ] && exit 0
+
+# Destructive DDL/DML. Mirrors schema-migration-guard's Bash-side regex
+# so the write-time and run-time guards agree on what "destructive" means.
+DESTRUCT=""
+if printf '%s' "$CONTENT" | grep -qEi 'DROP[[:space:]]+(TABLE|COLUMN|INDEX|DATABASE|SCHEMA)'; then
+    DESTRUCT="${DESTRUCT}DROP. "
+fi
+if printf '%s' "$CONTENT" | grep -qEi 'ALTER[[:space:]]+TABLE[^;]*DROP[[:space:]]'; then
+    DESTRUCT="${DESTRUCT}ALTER ... DROP. "
+fi
+if printf '%s' "$CONTENT" | grep -qEi 'TRUNCATE[[:space:]]+(TABLE[[:space:]]+)?[A-Za-z_\"`]'; then
+    DESTRUCT="${DESTRUCT}TRUNCATE. "
+fi
+# DELETE without a WHERE clause (whole-table delete).
+if printf '%s' "$CONTENT" | grep -qEi 'DELETE[[:space:]]+FROM[[:space:]]+[A-Za-z_\"`][A-Za-z0-9_\".`]*[[:space:]]*;'; then
+    DESTRUCT="${DESTRUCT}unqualified DELETE. "
+fi
+
+[ -z "$DESTRUCT" ] && exit 0
+
+# Is a data-preservation step present in the same file content?
+SAFEGUARD=0
+if printf '%s' "$CONTENT" | grep -qEi 'INSERT[[:space:]]+INTO[^;]*SELECT|UPDATE[[:space:]]+[A-Za-z_].*SET|backfill|data[ _-]?migration|COPY[[:space:]]|CREATE[[:space:]]+TABLE[^;]*_backup'; then
+    SAFEGUARD=1
+fi
+
+BASE=$(basename "$FILE")
+
+emit() {
+    echo "destructive-migration-write-guard: destructive schema change being written to $BASE" >&2
+    echo "  File: $FILE" >&2
+    echo "  Detected: $DESTRUCT" >&2
+    if [ "$SAFEGUARD" -eq 1 ]; then
+        echo "  A data-migration / backfill step appears in the same file — good. Confirm it runs BEFORE the drop and preserves the data you need." >&2
+    else
+        echo "  No data-migration / backfill step detected in this file." >&2
+        echo "  Before this migration is applied:" >&2
+        echo "    1. Back up the affected table(s)." >&2
+        echo "    2. If the data must survive, add a backfill/move step that runs before the drop." >&2
+        echo "    3. Write a reversible down-migration / rollback." >&2
+        echo "    4. Apply on staging first; this file may be run later by Flyway/Liquibase/Alembic without another prompt." >&2
+    fi
+}
+
+if [ "$MODE" = "block" ]; then
+    echo "BLOCKED: refusing to write a destructive migration file ($BASE)." >&2
+    emit
+    echo "  Set CC_MIGRATION_WRITE_GUARD=warn to allow the write with a warning instead." >&2
+    exit 2
+fi
+
+# warn (default)
+emit
+exit 0

package/examples/diff-size-guard.sh

@@ -20,6 +20,18 @@
 #   CC_DIFF_BLOCK=50   — block when staging 50+ files (default)
 # ================================================================
 
+# Without jq, the parse below silently yields empty and this hook stops
+# guarding - with no error anywhere. Say so. We deliberately do not exit
+# here: blocking would halt every tool call, and exiting 0 would change
+# the behaviour of guards that do not depend on the parsed value.
+if ! command -v jq >/dev/null 2>&1; then
+  _nojq_warned="/tmp/cc-nojq-warned-diff-size-guard-$PPID"
+  [ -f "$_nojq_warned" ] || {
+    echo "WARNING [diff-size-guard]: jq not found - this hook cannot inspect tool calls and is NOT protecting you. Install jq." >&2
+    : > "$_nojq_warned"
+  }
+fi
+
 INPUT=$(cat)
 COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty' 2>/dev/null)
 

package/examples/disabled-feature-toggle-advisor.sh

@@ -0,0 +1,88 @@
+#!/bin/bash
+# disabled-feature-toggle-advisor.sh — SessionStart advisory that surfaces
+# feature DISABLE / opt-out toggles set in your settings.json `env` block, so
+# you notice one a plugin installer flipped without telling you.
+#
+# Why: any plugin installer can write `~/.claude/settings.json` freely. Real
+# case (#66232): the claude-mem plugin wrote CLAUDE_CODE_DISABLE_AUTO_MEMORY=1
+# during install with no consent and no warning. A user with 75 accumulated
+# memory files saw apparent total memory loss on the next session — the files
+# were intact on disk, just no longer loaded — and spent ~30 minutes diagnosing
+# what looked like catastrophic data loss. The same vector flips ANY env toggle
+# (telemetry, 1M context, interleaved thinking, growthbook, ...), and the user
+# has no way to tell which a plugin touched without reading the file.
+#
+# What this does: at SessionStart, list every *DISABLE* / *NONESSENTIAL* /
+# *OPT_OUT* env key set to a truthy value in user + project settings.json, and
+# name the built-in behavior each one turns off. The point is recognition: if
+# you did not set one yourself, an installer probably did.
+#
+# Gap this fills: memory-chain-audit.sh treats CLAUDE_CODE_DISABLE_AUTO_MEMORY
+# as a cost-saving you opt INTO; it never warns when the toggle is set against
+# your intent. No existing hook surfaces silently-set disable toggles.
+#
+# Honest scope: ADVISORY only. It never blocks and cannot tell whether you or a
+# plugin set a toggle — it only makes the toggles visible so you can decide.
+# Silent when nothing is disabled.
+#
+# TRIGGER: SessionStart  MATCHER: ""
+# Config: CC_DISABLE_TOGGLE_ADVISOR=off   disable entirely (default: on)
+# Related: https://github.com/anthropics/claude-code/issues/66232
+
+[ "${CC_DISABLE_TOGGLE_ADVISOR:-on}" = "off" ] && exit 0
+
+INPUT=$(cat 2>/dev/null)
+
+# Resolve project dir for project-level settings (env first, then payload cwd).
+PROJ="${CLAUDE_PROJECT_DIR:-}"
+if [ -z "$PROJ" ]; then
+    PROJ=$(printf '%s' "$INPUT" | jq -r '.cwd // empty' 2>/dev/null)
+fi
+
+# Emit the env keys in a settings file that look like a disable/opt-out toggle
+# AND are set to a truthy value (1 / true / yes / on). Ignore parse errors.
+collect() {
+    [ -r "$1" ] || return 0
+    jq -r '
+        (.env // {}) | to_entries[]
+        | select(.key | test("DISABLE|NONESSENTIAL|OPT_?OUT"; "i"))
+        | select((.value|tostring|ascii_downcase) as $v
+                 | ($v=="1" or $v=="true" or $v=="yes" or $v=="on"))
+        | .key
+    ' "$1" 2>/dev/null
+}
+
+found=$( {
+    collect "$HOME/.claude/settings.json"
+    collect "$HOME/.claude/settings.local.json"
+    if [ -n "$PROJ" ]; then
+        collect "$PROJ/.claude/settings.json"
+        collect "$PROJ/.claude/settings.local.json"
+    fi
+} | sort -u )
+
+# Nothing disabled → stay silent (advisory hooks must not add noise).
+[ -z "$found" ] && exit 0
+
+{
+    echo "disabled-feature-toggle-advisor: feature DISABLE toggles are active in your settings.json env block:"
+    while IFS= read -r k; do
+        [ -z "$k" ] && continue
+        case "$k" in
+            *AUTO_MEMORY*)  note="persistent memory will NOT load — your memory files stay on disk but look lost (#66232)" ;;
+            *1M_CONTEXT*)   note="1M context window is turned off" ;;
+            *INTERLEAVED*)  note="interleaved thinking is turned off" ;;
+            *NONESSENTIAL*|*TELEMETRY*|*ERROR_REPORTING*|*GROWTHBOOK*) note="telemetry / server-side experiments are turned off" ;;
+            *)              note="a built-in behavior is turned off" ;;
+        esac
+        echo "  - ${k}  →  ${note}"
+    done <<EOF
+$found
+EOF
+    echo "If you did not set these yourself, a plugin installer may have written them silently"
+    echo "(real case: #66232, a plugin disabled auto-memory on install). Review the env block of"
+    echo "~/.claude/settings.json and remove a key to restore that feature. Set"
+    echo "CC_DISABLE_TOGGLE_ADVISOR=off to silence this notice."
+} >&2
+
+exit 0

package/examples/disk-partition-guard.sh

@@ -18,6 +18,18 @@
 #
 # TRIGGER: PreToolUse  MATCHER: "Bash"
 
+# Without jq, the parse below silently yields empty and this hook stops
+# guarding - with no error anywhere. Say so. We deliberately do not exit
+# here: blocking would halt every tool call, and exiting 0 would change
+# the behaviour of guards that do not depend on the parsed value.
+if ! command -v jq >/dev/null 2>&1; then
+  _nojq_warned="/tmp/cc-nojq-warned-disk-partition-guard-$PPID"
+  [ -f "$_nojq_warned" ] || {
+    echo "WARNING [disk-partition-guard]: jq not found - this hook cannot inspect tool calls and is NOT protecting you. Install jq." >&2
+    : > "$_nojq_warned"
+  }
+fi
+
 INPUT=$(cat)
 COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty' 2>/dev/null)