Programación con IA

Permisos de Claude Code: protege .env, Git y los comandos peligrosos

Guía práctica para limitar los permisos de Claude Code: aislar secretos, controlar comandos de Git y shell y comprobar los límites de seguridad antes de usar un repositorio de producción.

BT

BetterToken

Equipo editorial
4 min de lectura

Al configurar Claude Code, los desarrolladores suelen encontrarse ante una elección equivocada: confirmar constantemente comandos de lectura triviales o activar el bypass completo (--dangerously-skip-permissions) y arriesgar una filtración de .env, un git push --force accidental o un entorno de proyecto dañado.

Ninguno de los dos extremos funciona bien. La operación segura sigue el principio de mínimo privilegio: hay que separar con claridad los accesos de lectura, los permisos de escritura, la ejecución de shell y el control de versiones.

1. Mapa de permisos: de la lectura al impacto externo

Organiza los archivos y comandos en cuatro niveles de acceso:

NivelOperacionesPolítica predeterminadaEjemplos
1. Inspección de códigoLeer archivos del proyectoPermitido (sin confirmación)cat, grep, ver código fuente en src/
2. Secretos y configuraciónAcceder a .env, claves y tokensEstrictamente prohibido.env*, id_rsa, *.pem, credentials.json
3. Edición de archivosCrear y modificar códigoPermitido dentro del workspacewrite_to_file, replace_file_content
4. Shell y Git peligrososGestores de paquetes y operaciones destructivasRequiere aprobación manualrm -rf, git push --force, npm publish, DROP TABLE

2. Aislar los archivos .env y los secretos del proyecto

Transport Layer Security (TLS) cifra el tráfico de API mientras viaja por la red. No impide, sin embargo, que credenciales confidenciales lleguen a la ventana de contexto del modelo, a los registros de errores o a los resúmenes de handoff.

Para evitar que Claude Code ingiera credenciales privadas:

  1. Añade a .gitignore todos los archivos de entorno que contengan secretos.
  2. Proporciona una plantilla .env.example limpia con valores ficticios; así el agente conoce los nombres de variables sin ver valores de ejecución.
  3. Añade una regla de límite estricta en CLAUDE.md o AGENTS.md:

Regla de protección de secretos

  • Nunca inspecciones, muestres ni transmitas contenido de .env, .env.local o archivos de claves privadas.
  • Para comprobar las claves de configuración requeridas, revisa .env.example.

> [!IMPORTANT]
> **Gestión de claves API**: tu clave API de Claude Code se configura en tu entorno local y nunca debe incluirse en archivos del repositorio. Sigue el flujo de integración de la [documentación de BetterToken para Claude Code](https://docs.bettertoken.ai/ai-tools/claude-code).

---

3. Lista de comprobación priorizada para Git y comandos

Al ejecutar tareas con Claude Code, aplica primero esta jerarquía:

El agente propone un comando
  │
  ├─> ¿Contiene patrones destructivos (rm -rf, drop, force push)?
  │     └─> SÍ: Rechazarlo o ejecutarlo manualmente bajo supervisión
  │
  └─> ¿Afecta a internos de .git, archivos .env o redes externas?
        │
        ├─> SÍ: Exigir una justificación explícita y limitar el alcance
        │
        └─> NO: Aprobar su ejecución en la rama objetivo

Barreras paso a paso

  1. Paso 1: bloquear mutaciones de Git. No permitas pushes automatizados directos a main sin ejecutar manualmente git diff --check y las pruebas.
  2. Paso 2: aislar la instalación de paquetes. Comandos como npm install <package> o scripts curl remotos deben verificarse manualmente para evitar dependencias no confiables y riesgos de cadena de suministro.
  3. Paso 3: limitar el alcance de directorios. Restringe el workspace del agente a una carpeta concreta de la funcionalidad o a un Git worktree dedicado.

4. Validar permisos en un workspace de prueba

Antes de dar a Claude Code acceso a repositorios críticos, realiza una validación en sandbox:

  1. Crea una rama temporal de prueba: git checkout -b test/permission-check.
  2. Añade un archivo .env ficticio con un secreto de prueba falso.
  3. Pide al agente que refactorice el módulo de autenticación.
  4. Comprueba que:
    • el agente no leyó el .env ficticio durante la exploración;
    • no aparecen tokens secretos en registros de errores, comentarios o git diff;
    • las pruebas unitarias se ejecutan sin acceder a archivos no autorizados.
  5. Elimina la rama de prueba cuando hayas confirmado los límites.

Este límite de permisos protege las credenciales y mantiene una ejecución autónoma rápida.

¿Quieres optimizar tu flujo de trabajo con LLM?

Conecta modelos mediante una API, gestiona claves y controla el gasto en IA.