DEV Community: luijhy michael guerra flores

3 permission presets for Claude Code (strict, balanced, autonomous) and the gap none of them close

luijhy michael guerra flores — Wed, 28 Oct 2026 19:31:26 +0000

Every "Allow this command?" prompt in Claude Code is a small interruption. Click "always allow" enough times and you end up with a settings.json nobody has read. Here are three presets I keep in .claude/settings.json, from most to least careful, and the one thing none of them can do.

Rules are matched in this order: deny beats ask, and ask beats allow. Anything not listed falls back to defaultMode.

1. Strict: new or sensitive repos

Read-only git is free. Commits, pushes and installs need a confirmation, and network tools are off.

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)"
    ],
    "ask": [
      "Bash(git commit:*)",
      "Bash(git push:*)",
      "Bash(npm install:*)",
      "Bash(pnpm add:*)",
      "Bash(yarn add:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(curl:*)",
      "Bash(wget:*)",
      "WebFetch"
    ]
  }
}

2. Balanced: day-to-day work

Edits are accepted automatically (acceptEdits). Lint, tests and type checks run without asking, and anything that leaves your machine or changes dependencies still asks.

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Bash(git add:*)",
      "Bash(npm run lint:*)",
      "Bash(npm run test:*)",
      "Bash(npm test:*)",
      "Bash(npx tsc --noEmit:*)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(npm install:*)",
      "Bash(pnpm add:*)",
      "Bash(yarn add:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

3. Autonomous: throwaway branches and spikes

All of git and npm are allowed. Use it only where a bad command costs you a branch, not a production database.

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(git:*)",
      "Bash(npm:*)",
      "Bash(npx:*)",
      "Bash(pnpm:*)",
      "Bash(node:*)",
      "WebFetch",
      "WebSearch"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

The gap

Look at the autonomous preset again: Bash(git:*) allows git push --force and git reset --hard too. Permission rules match a command by its prefix. They can't tell a safe git push from a destructive one.

There's a second gap. Read(./.env) blocks Claude's Read tool, but it isn't a rule about the shell. A cat .env through Bash is a different tool and needs its own handling.

That's what hooks are for. A PreToolUse hook is a script that sees the full command before it runs and can block it with exit 2, so it can reject git push --force while allowing a normal push, or refuse any command that touches .env. Two free ones (one blocks destructive commands, tested against bypasses like git push origin +main; one stops secrets from being written into files) are here: https://github.com/kailucho/claude-code-hooks-seguridad (free, MIT).

Presets for convenience, hooks for safety. You want both.

The three presets, the hooks, 6 skills (/commit, /pr, /review, /tests, /plan, /debug) and CLAUDE.md templates for React, Node and GraphQL come together in the Starter Kit for Claude Code (US$9, unofficial): https://luijhy.gumroad.com/l/starter-kit-for-claude-code

Una skill /revisar para Claude Code que encontró un bypass de auth, una inyección SQL y un secreto en logs (SKILL.md completo)

luijhy michael guerra flores — Wed, 21 Oct 2026 18:35:06 +0000

Las skills de Claude Code son archivos Markdown que le enseñan a Claude un procedimiento repetible. Se guardan en .claude/skills/<nombre>/SKILL.md y se llaman con /<nombre>, o Claude las usa sola cuando tu pedido coincide con su description.

Esta es la skill de revisión de código que uso a diario, completa y gratis para copiar.

La skill

Guárdala como .claude/skills/revisar/SKILL.md en tu repo (o en ~/.claude/skills/revisar/SKILL.md para tenerla en todos):

---
name: revisar
description: "Revisa el diff actual (o una rama) buscando bugs, problemas de seguridad y deuda, y entrega hallazgos priorizados. Úsala cuando el usuario pida \"revisa\", \"code review\" o \"qué opinas de estos cambios\"."
---

# Revisión de código

1. Obtén el diff: `git diff` + `git diff --staged`, o `git diff <base>...HEAD` si el usuario nombra una rama.
2. Lee el contexto necesario de cada archivo tocado (no solo las líneas del diff).
3. Busca, en este orden:
   1. **Correctitud**: casos borde, null/undefined, async sin `await`, condiciones de carrera, off-by-one, manejo de errores que traga excepciones.
   2. **Seguridad**: inyección (SQL, comandos, XSS), secretos en código, validación de entrada, autorización faltante en resolvers/endpoints, datos sensibles en logs.
   3. **Datos y API**: migraciones irreversibles, cambios incompatibles de contrato (REST/GraphQL), N+1 en resolvers.
   4. **Rendimiento**: renders innecesarios en React, efectos sin dependencias correctas, consultas en bucles.
   5. **Mantenibilidad**: duplicación, nombres confusos, código muerto, tests faltantes para la lógica nueva.
4. Entrega una tabla ordenada por severidad:

   | Sev. | Archivo:línea | Problema | Sugerencia |
   |------|---------------|----------|------------|
   | 🔴 alta / 🟡 media / ⚪ menor | ... | ... | ... |

5. Solo reporta lo que puedas justificar con un escenario concreto. Si no encuentras nada serio, dilo. No apliques cambios salvo que el usuario lo pida.

Tres detalles la hacen mejor que escribir "revisa mi código":

Lee el archivo completo, no solo el diff. La mayoría de bugs reales están en cómo las líneas nuevas interactúan con las que no cambiaron.
Un orden fijo. Correctitud y seguridad van antes que estilo, así lo importante no queda enterrado bajo comentarios de nombres.
"Solo reporta lo que puedas justificar con un escenario concreto." Esa línea elimina casi todos los consejos genéricos que suelen dar las revisiones con IA.

Una prueba real

Armé un repo de prueba con un refactor de autenticación que mete tres fallos a propósito: un bypass de auth, el secreto JWT impreso en los logs y una inyección SQL. Lo pasé por la versión en inglés de esta misma skill (mismo contenido, traducido) en Claude Code 2.1.293.

Resultado: encontró los tres fallos, los puso primero como 🔴 alta, explicó para cada uno cómo se explota (por ejemplo, que Authorization: Bearer basura pasaba el middleware porque req.user = null seguía llamando a next()) y propuso el arreglo concreto (return res.status(401) antes de next(), consulta parametrizada con $1, borrar el console.log del secreto). No tocó el código, porque la skill dice que no lo haga salvo que se lo pidas.

Adáptala

Agrega a la lista del paso 3 los errores típicos de tu stack (por ejemplo, "falta key en listas de React", "consultas GraphQL sin límite").
Si quieres que se active sin escribir /revisar, pon en la description las frases que usas de verdad ("mira mis cambios", "¿algo mal aquí?").
Mantén la tabla de severidad: se lee rápido y se pega tal cual en un PR.

Si te sirve, el Kit de Claude Code en español (US$9, no oficial) trae 5 skills más en el mismo estilo (/commit, /pr, /tests, /plan, /depurar), hooks de seguridad que bloquean rm -rf, force-push y secretos filtrados (con 27 tests), plantillas de CLAUDE.md para React, Node y GraphQL, y presets de permisos: https://luijhy.gumroad.com/l/kit-claude-code-es

Los hooks de seguridad solos están gratis aquí: https://github.com/kailucho/claude-code-hooks-seguridad

A Claude Code /review skill that caught an auth bypass, SQL injection and a leaked secret (full SKILL.md)

luijhy michael guerra flores — Wed, 14 Oct 2026 18:34:15 +0000

Claude Code skills are Markdown files that teach Claude a repeatable procedure. You drop one in .claude/skills/<name>/SKILL.md and call it with /<name>, or Claude picks it up when your request matches its description.

Here is the code review skill I use every day, complete and free to copy, plus an unedited run of it against a deliberately broken auth refactor.

The skill

Save this as .claude/skills/review/SKILL.md in your repo (or in ~/.claude/skills/review/SKILL.md to have it everywhere):

---
name: review
description: "Reviews the current diff (or a branch) for bugs, security issues and debt, and returns prioritized findings. Use when the user says \"review\", \"code review\" or \"what do you think of these changes\"."
---

# Code review

1. Get the diff: `git diff` + `git diff --staged`, or `git diff <base>...HEAD` if the user names a branch.
2. Read the context you need from every touched file (not just the diff lines).
3. Look for, in this order:
   1. **Correctness**: edge cases, null/undefined, async without `await`, race conditions, off-by-one, error handling that swallows exceptions.
   2. **Security**: injection (SQL, shell, XSS), secrets in code, input validation, missing authorization in resolvers/endpoints, sensitive data in logs.
   3. **Data and API**: irreversible migrations, breaking contract changes (REST/GraphQL), N+1 in resolvers.
   4. **Performance**: unnecessary React renders, effects with wrong dependencies, queries in loops.
   5. **Maintainability**: duplication, confusing names, dead code, missing tests for new logic.
4. Return a table ordered by severity:

   | Sev. | File:line | Problem | Suggestion |
   |------|-----------|---------|------------|
   | 🔴 high / 🟡 medium / ⚪ minor | ... | ... | ... |

5. Only report what you can justify with a concrete scenario. If you find nothing serious, say so. Do not apply changes unless the user asks.

Three details make it work better than "review my code":

It reads the whole touched file, not just the diff. Most real bugs live in how the changed lines interact with the unchanged ones.
A fixed checklist order. Correctness and security come before style, so the important findings don't get buried under naming nits.
"Only report what you can justify with a concrete scenario." This one line removes most of the vague, generic advice LLM reviews tend to produce.

A real run

I made a test repo with an auth refactor that introduces three bugs on purpose: an auth bypass, a secret written to the logs, and a SQL injection. Then I staged it and typed /review. This is the output, unedited (Claude Code 2.1.293):

Sev.	File:line	Problem	Suggestion
🔴 high	`src/middleware/auth.ts:8-9`	Auth bypass. `verifyToken` now returns `null` for an invalid or expired token. The middleware still sets `req.user = null` and calls `next()`. A request with `Authorization: Bearer garbage` therefore passes `requireAuth`. Any handler that only checks the middleware, or reads `req.user?.sub` loosely, is exposed.	After verifying, add `if (!payload) return res.status(401).json({ error: "invalid token" });` before `next()`.
🔴 high	`src/auth/service.ts:21`	SQL injection. `findUserByEmail` interpolates `email` straight into the query. An input like `' OR '1'='1` returns arbitrary users, and `'; DROP TABLE users;--` can run further statements, depending on the driver.	Use a parameterized query, e.g. `db.query("SELECT * FROM users WHERE email = $1", [email])`, with the placeholder syntax your driver uses. Replace `db: any` with a real type, and select only the columns you need instead of `*`.
🔴 high	`src/auth/service.ts:4`	Secret in logs. `console.log("auth init", config.JWT_SECRET)` writes the JWT signing secret to stdout on every start. Anyone with log access can forge valid tokens.	Delete the line. If you need a startup message, log without the secret.
🟡 medium	`src/auth/service.ts:13-17`	`catch {}` swallows every error and returns `null`. A bad token, an expired token and a misconfigured secret all look the same, which makes failures hard to diagnose. `jwt.verify` can also return a string payload, so callers can't rely on `.sub`.	Return a typed result, such as `{ sub: string } \
🟡 medium	{% raw %}`src/middleware/auth.ts:6`	`replace("Bearer ", "")` doesn't check the scheme. A header of `Basic xyz` becomes `Basic xyz` and is passed to `verify`. That is harmless once the bypass is fixed, but sloppy.	Match with `/^Bearer (.+)$/` and return 401 if it doesn't match.
⚪ minor	`src/middleware/auth.ts:4`	Dropping `async` is correct now that `verifyToken` is synchronous.	None. This is fine as is.
⚪ minor	`src/auth/service.ts`	There are no tests for `verifyToken` or `findUserByEmail`. A test for "invalid token returns 401" would have caught the bypass.	Add tests for valid, expired, malformed and missing tokens.

I recommend not merging until the three 🔴 items are fixed. I haven't changed anything. Tell me if you want me to apply the fixes.

All three planted bugs were found, ranked first, and each came with a concrete exploit scenario and fix. It also didn't touch any code, because the skill says not to unless asked.

Make it yours

Add your stack's usual suspects to step 3 (e.g. "missing key in React lists", "unbounded GraphQL queries").
If you want it to trigger without typing /review, put the phrases you naturally use in the description ("check my changes", "anything wrong here?").
Keep the severity table: it makes the result scannable and easy to paste into a PR.

If you want more like this, the Starter Kit for Claude Code (US$9, unofficial) has 5 more skills in the same style (/commit, /pr, /tests, /plan, /debug), safety hooks that block rm -rf, force-push and leaked secrets (with 27 tests), CLAUDE.md templates for React, Node and GraphQL, and permission presets: https://luijhy.gumroad.com/l/starter-kit-for-claude-code

The safety hooks alone are free here: https://github.com/kailucho/claude-code-hooks-seguridad

3 Claude Code hooks that prevent disasters (with code)

luijhy michael guerra flores — Fri, 09 Oct 2026 20:55:59 +0000

Claude Code is very good at running commands. That's exactly the problem when it runs the wrong one. Hooks let you add a safety net that runs before every action, without relying on the model "remembering" your rules.

How they work (in 30 seconds)

They're configured in .claude/settings.json, per event (PreToolUse, PostToolUse, Notification…) and per tool (Bash, Write|Edit…).
The hook receives the event as JSON on stdin.
If it exits with code 2, the action is blocked and the stderr text is sent back to Claude as the reason.

1. Block destructive commands

.claude/hooks/block-dangerous-commands.sh:

#!/usr/bin/env bash
input="$(cat)"
patterns=(
  'git[^;&|]*[[:space:]]push([[:space:]][^;&|]*)?[[:space:]](--force([^-]|$)|-[a-zA-Z]*f[a-zA-Z]*([[:space:]"]|$)|\+[^[:space:]"]+)'
  'git[^;&|]*[[:space:]]reset([[:space:]][^;&|]*)?[[:space:]]--hard'
  'DROP[[:space:]]+(TABLE|DATABASE)'
  '(curl|wget)[^|]*\|[[:space:]]*(sudo[[:space:]]+)?(ba)?sh'
)
for pattern in "${patterns[@]}"; do
  if printf '%s' "$input" | grep -qiE -- "$pattern"; then
    echo "Blocked: matches a dangerous pattern. Ask the user to run it." >&2
    exit 2
  fi
done
exit 0

Two details in the push pattern: --force([^-]|$) blocks --force but lets --force-with-lease through, which is the safe way to force-push; and \+[^[:space:]"]+ catches a + refspec (git push origin +main), which forces without ever typing --force. The git[^;&|]* prefix also catches git -C some/dir push --force and git reset -q --hard.

.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/block-dangerous-commands.sh" }
        ]
      }
    ]
  }
}

Don't forget chmod +x, then test it:

echo '{"tool_input":{"command":"git push origin +main"}}' | .claude/hooks/block-dangerous-commands.sh; echo $?
# → 2

I tested it in a real session: I asked Claude to run git push --force origin main and it came back with "blocked by a PreToolUse hook, run it yourself if you really need it".

Defense in depth: a regex hook is an early warning, not a guarantee. A reader of the Spanish version of this post found two forced-push variants that slipped past my first patterns (both fixed above). For anything irreversible, put the real block where the agent can't edit it: branch protection on the remote with force pushes disabled. If the regex falls short, the push bounces off the server.

2. Catch secrets before they're written

Same pattern with matcher: "Write|Edit|MultiEdit" and regexes like AKIA[0-9A-Z]{16} (AWS), sk-ant-[A-Za-z0-9_-]{20,} (Anthropic) or gh[pousr]_[A-Za-z0-9]{36,} (GitHub). When Claude tries to write a key, it gets "use an environment variable and document it in .env.example" and fixes it on its own.

3. Format after every edit

A PostToolUse hook that reads file_path from the JSON and runs the project's own Prettier/Biome (node_modules/.bin/prettier). It always exits 0: it never blocks, it just tidies.

Free code

Hooks 1 and 2, with 27 tests running on Linux and macOS, are on GitHub under MIT: https://github.com/kailucho/claude-code-hooks-seguridad (docs in Spanish, English summary at the top).

If you want it all wired up

The Starter Kit for Claude Code (US$9, unofficial) bundles the three hooks plus a notifications one, 6 skills (/commit, /pr, /review, /tests, /plan, /debug), CLAUDE.md templates for React, Node and GraphQL, and permission presets: https://luijhy.gumroad.com/l/starter-kit-for-claude-code

What other command would you block? Let me know in the comments.

3 hooks de Claude Code que evitan desastres (con código)

luijhy michael guerra flores — Thu, 08 Oct 2026 04:57:47 +0000

Claude Code es muy bueno ejecutando comandos. Ese es justo el problema cuando ejecuta el comando equivocado. Los hooks te dejan poner una red de seguridad que corre antes de cada acción, sin depender de que el modelo "recuerde" tus reglas.

Cómo funcionan (en 30 segundos)

Se configuran en .claude/settings.json, por evento (PreToolUse, PostToolUse, Notification…) y por herramienta (Bash, Write|Edit…).
El hook recibe el evento como JSON por stdin.
Si sale con código 2, la acción se bloquea y el texto de stderr se le devuelve a Claude como motivo.

1. Bloquear comandos destructivos

.claude/hooks/bloquear-comandos-peligrosos.sh:

#!/usr/bin/env bash
entrada="$(cat)"
patrones=(
  'git[^;&|]*[[:space:]]push([[:space:]][^;&|]*)?[[:space:]](--force([^-]|$)|-[a-zA-Z]*f[a-zA-Z]*([[:space:]"]|$)|\+[^[:space:]"]+)'
  'git[^;&|]*[[:space:]]reset([[:space:]][^;&|]*)?[[:space:]]--hard'
  'DROP[[:space:]]+(TABLE|DATABASE)'
  '(curl|wget)[^|]*\|[[:space:]]*(sudo[[:space:]]+)?(ba)?sh'
)
for patron in "${patrones[@]}"; do
  if printf '%s' "$entrada" | grep -qiE -- "$patron"; then
    echo "Bloqueado: coincide con un patrón peligroso. Pide al usuario que lo ejecute." >&2
    exit 2
  fi
done
exit 0

Fíjate en dos detalles del patrón de push: --force([^-]|$) bloquea --force pero deja pasar --force-with-lease, que es la forma segura; y \+[^[:space:]"]+ atrapa el refspec con + (git push origin +main), que fuerza sin escribir --force.

.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/bloquear-comandos-peligrosos.sh" }
        ]
      }
    ]
  }
}

No olvides chmod +x y pruébalo:

echo '{"tool_input":{"command":"git push origin +main"}}' | .claude/hooks/bloquear-comandos-peligrosos.sh; echo $?
# → 2

Actualización: un lector mostró en los comentarios que git push origin +main y git reset -q --hard pasaban la primera versión de estos patrones. Ya están corregidos (con pruebas en el repo). Y tiene razón en lo más importante: el hook es un aviso temprano; el bloqueo de verdad es la protección de rama en el remoto con force push desactivado. Si el regex se queda corto, el push rebota en el servidor.

2. Detectar secretos antes de escribirlos

Mismo patrón, pero con matcher: "Write|Edit|MultiEdit" y expresiones como AKIA[0-9A-Z]{16} (AWS), sk-ant-[A-Za-z0-9_-]{20,} (Anthropic) o gh[pousr]_[A-Za-z0-9]{36,} (GitHub). Si Claude intenta escribir una clave, recibe el mensaje "usa una variable de entorno y documéntala en .env.example" y corrige solo.

3. Formatear después de cada edición

Un PostToolUse que lee file_path del JSON y corre el Prettier/Biome del proyecto (node_modules/.bin/prettier). Siempre sale con 0: nunca bloquea, solo ordena.

Código gratis

Los hooks 1 y 2 completos, con pruebas que corren en Linux y macOS, están en GitHub con licencia MIT: https://github.com/kailucho/claude-code-hooks-seguridad

Si quieres todo armado

El Kit Claude Code en español (US$9, no oficial) trae los tres hooks y uno de notificaciones, 6 skills en español (/commit, /pr, /revisar, /tests, /plan, /depurar), plantillas CLAUDE.md para React, Node y GraphQL y presets de permisos: https://luijhy.gumroad.com/l/kit-claude-code-es

¿Qué otro comando bloquearías tú? Te leo en los comentarios.