Evita prompts peligrosos en Claude Code: sin push automático, sin saltar tests, sin arreglos vagos

Pedirle a Claude Code “arregla todo, haz push y deja los tests para después” parece productivo. Pero en una herramienta que puede editar archivos, ejecutar comandos, usar git y consultar documentación, esa frase también puede quitarte el control de revisión.

Esta guía no busca asustar. Busca prevenir. Revisé la documentación oficial de Claude Code el 3 de junio de 2026, especialmente los modos de permisos, /permissions, settings.json y los flujos de trabajo comunes, y convertí los patrones peligrosos en prompts que puedes pegar en trabajo real.

flowchart LR
  A["Escribir pedido"] --> B["Permitir investigación"]
  B --> C["Revisar plan"]
  C --> D["Editar con alcance reducido"]
  D --> E["Ejecutar tests y diff"]
  E --> F["Humano decide push/deploy"]

Qué hace peligroso a un prompt

Peligroso no significa malicioso. Aquí significa que el alcance, la autoridad o el criterio de finalización no están claros mientras Claude Code tiene acceso a acciones potentes. Para principiantes: un límite de permisos es la línea donde el agente debe pedir confirmación antes de editar archivos, ejecutar comandos o salir del proyecto.

Claude Code puede leer y buscar archivos, editar código, ejecutar tests y usar git. La documentación oficial explica que, en una sesión local, Claude Code puede trabajar con los archivos y capacidades de terminal disponibles para el usuario. Por eso un buen prompt debe decir qué está permitido y también qué queda prohibido.

Frase riesgosa	Sustitución segura
Arregla todo	Nombra archivos objetivo y excluidos; pide primero un plan
Haz push al terminar	Resume diff y tests; yo decido si se hace push
Salta los tests	Propón la verificación mínima útil y explica si no puede ejecutarse
Revisa la base de producción	Usa solo dev/staging; genera SQL de producción sin ejecutarlo
Salta todas las aprobaciones	Investiga en Plan mode y avanza paso a paso con aprobación
Borra lo viejo	Lista candidatos a borrar; elimina solo tras aprobación
Actualiza todo a latest	Separa fixes de seguridad, minor updates y major updates
Investiga e implementa	Cita fuentes oficiales y separa hallazgos de propuestas de cambio

Límites de permisos según la documentación actual

El modo de permisos de Claude Code no cambia solo porque escribas “hazlo de forma segura” en el chat. En CLI se cambia con Shift+Tab o --permission-mode; en IDE y Desktop con el selector de modo; los valores persistentes se configuran en settings.json.

Al 3 de junio de 2026, los modos principales son: default, que pregunta antes de acciones que no sean lectura; acceptEdits, que acepta automáticamente ediciones de archivos y operaciones comunes de sistema de archivos; plan, útil para leer, explorar y proponer antes de editar; auto, una vista previa de investigación con comprobaciones de seguridad; dontAsk, que niega herramientas no preaprobadas; y bypassPermissions, reservado para contenedores o VMs aisladas.

El comando /permissions muestra reglas Allow, Ask y Deny. Deny gana, así que un equipo debería bloquear force pushes, lectura de .env y comandos de despliegue a producción en lugar de confiar en la memoria. Las reglas compartidas van en .claude/settings.json; los experimentos personales, en .claude/settings.local.json.

settings.json mínimo

Usa este ejemplo como punto de partida y cambia solo los nombres de comandos de tu proyecto.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm publish *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push --force *)",
      "Bash(* --no-verify *)"
    ]
  }
}

La clave es la moderación. Una regla amplia como Bash(*) adelgaza la capa de aprobación. Preaprobar comprobaciones repetibles como npm run test y git diff mantiene la sesión rápida sin ocultar operaciones riesgosas.

Caso de uso 1: bugfix

El pedido riesgoso es: “Arregla todo lo de login y haz push si funciona”. El alcance es demasiado amplio y la acción remota queda unida a la edición.

Objetivo: Corregir el bug donde la sesión expira justo después del login.
Alcance: Solo src/auth/**, src/session/** y tests/auth/**.
Prohibido: git push, deploy, acceso a DB de producción y leer .env.
Proceso:
1. Leer archivos relevantes y listar hasta 3 causas probables.
2. Proponer un plan de cambio y esperar mi aprobación.
3. Tras la aprobación, hacer el cambio mínimo útil.
4. Ejecutar npm run test -- auth y resumir fallos si aparecen.
5. Terminar con resumen de git diff y riesgos restantes.

Así Claude Code puede investigar, editar y verificar sin eliminar los puntos de revisión. También reduce el riesgo de reescrituras no relacionadas.

Caso de uso 2: refactorización

El pedido riesgoso es: “Limpia la implementación vieja y borra lo innecesario”. Palabras como viejo, limpio e innecesario son ambiguas.

Objetivo: Consolidar validaciones duplicadas en el módulo de billing.
Cambios permitidos: src/billing/validators.ts y sus tests.
No cambiar: migrations/**, prisma/**, public/**, package-lock.json.
Regla de borrado: Solo listar candidatos. No borrar sin aprobación.
Verificación: Ejecutar npm run test -- billing y npm run lint.
Salida: Reportar motivo, impacto de compatibilidad y tests pendientes.

En refactors, la lista de exclusiones suele ser la parte más importante. Migraciones, lockfiles y archivos generados son fáciles de juzgar mal solo por su apariencia.

Caso de uso 3: revisión antes de desplegar

El pedido riesgoso es: “CI es lento, sáltalo y manda a producción”. --no-verify puede saltarse más que lint; también puede saltarse hooks y escaneo de secretos.

Objetivo: Hacer una revisión breve de preparación para release.
Comandos permitidos: git status, git diff, npm run test -- --runInBand, npm run build.
Comandos prohibidos: git push, deploy, --no-verify, npm publish.
Criterio:
- Detenerse si fallan tests o build.
- Resumir solo las últimas 80 líneas de cualquier log de error.
- Reportar estado como Listo / Requiere arreglo / Decisión pendiente.

Los despliegues tocan clientes, pagos, índices de búsqueda, cachés y soporte. Deja que Claude Code prepare evidencia; mantén la acción final de release como decisión explícita humana.

Caso de uso 4: investigación y documentación

El pedido riesgoso es: “Busca lo último y actualiza el artículo como te parezca”. Los hechos externos cambian, por lo que fuentes y alcance de edición deben separarse.

Objetivo: Actualizar el texto sobre permission modes de Claude Code.
Fuentes: Priorizar documentación oficial y listar URLs al final.
Prohibido: No afirmar funciones que la documentación oficial no confirme.
Proceso:
1. Crear una tabla comparando el texto actual con la documentación oficial.
2. Proponer cambios solamente; esperar antes de editar el artículo.
3. Tras editar, revisar enlaces obsoletos y longitud de description.

En tareas de investigación, trata a Claude Code primero como verificador de fuentes y organizador de diferencias, no como redactor final.

Fallos concretos

Primero, reintentos ilimitados. “Reintenta hasta que funcione” puede convertir una caída externa en más coste y presión de rate limits. Define intentos máximos, espera y condición de parada.

Segundo, secretos. Si pegas claves reales en prompts, pueden quedar en historial, logs locales y traspasos a subagentes. Los valores van en variables de entorno o secret managers; los prompts solo mencionan nombres de variables.

Tercero, dependencias. “Actualiza todo a latest” puede traer versiones major con breaking changes. Usa npm outdated, separa security fixes de updates normales y revisa majors por separado.

Cuarto, limpieza y migraciones. “Limpia los archivos de DB” puede interpretarse como borrar historial de migraciones. Pide primero una lista y detén cualquier cambio de datos de producción en SQL generado.

Checklist de revisión

Pega esto al final de prompts de alto impacto.

Comprobación de seguridad:
[ ] Nombré archivos objetivo y archivos excluidos
[ ] git push / deploy / publish está prohibido o requiere aprobación
[ ] Bloqueé DB de producción, API de producción y operaciones con coste
[ ] Bloqueé lecturas de .env, claves privadas y datos personales
[ ] Pedí Plan mode o un plan antes de editar
[ ] Incluí al menos un test, lint o build
[ ] Indiqué detenerse y resumir logs si algo falla
[ ] Pedí diff final, comandos ejecutados y riesgos restantes

Si quieres plantillas reutilizables en vez de reescribir estas reglas cada vez, la página de productos incluye paquetes de prompts y checklists. Para equipos, CLAUDE.md, permisos, gates de revisión y ejercicios de onboarding pueden diseñarse con tu repositorio real mediante formación y consultoría de Claude Code.

Enlaces oficiales

実際に試した結果: En el flujo de Masa, lo que más ayudó fue empezar en Plan mode, limitar los cambios a dos o cinco archivos y dejar push/deploy como decisión humana. Evitar prompts peligrosos no frena Claude Code; hace que el traspaso sea lo bastante preciso para avanzar más rápido y revisar con menos tensión.