Claude Code en GitHub Actions: CI/CD, permisos y seguridad para agentes de código

Anthropic's Claude Code agent can now run inside GitHub Actions, but developers must carefully restrict its permissions to avoid security risks. The CI/CD integration allows the AI agent to review pull requests, triage issues, and execute maintenance tasks from comments, PRs, or scheduled workflows, but requires explicit permission scoping and cost limits rather than broad access. Anthropic recommends using the `anthropics/claude-code-action@v1` action with narrow mandates, minimal token permissions, and OIDC for cloud providers instead of static secrets.

Claude Code puede vivir dentro de GitHub Actions, pero un agente en CI no debe tener los mismos permisos que un desarrollador interactivo. Claude Code en GitHub Actions convierte una conversación con un agente en una automatización reproducible: puedes invocarlo desde comentarios, pull requests, issues, tareas programadas o workflows internos. La promesa es clara: revisar PRs, preparar cambios, clasificar issues o ejecutar mantenimiento sin abrir el editor. El riesgo también es claro. Un agente dentro de CI corre con permisos de workflow, acceso a secretos, checkout del repositorio y capacidad para comentar, abrir PRs o modificar archivos si se lo permites. No es lo mismo que pedir ayuda localmente a Claude Code y revisar cada comando en una terminal. La guía práctica no es activar anthropics/claude-code-action@v1 y esperar magia. Es diseñar un workflow donde el agente tenga un mandato estrecho, permisos mínimos, salida auditable y límites de coste antes de que escriba en el repositorio. La documentación actual de Anthropic recomienda usar anthropics/claude-code-action@v1 . La versión v1 simplifica la configuración con entradas unificadas como prompt y claude args , elimina parte de la configuración antigua de modos y permite pasar argumentos de Claude Code desde el workflow. Eso mejora la ergonomía, pero no elimina las decisiones importantes. Tienes que decidir qué evento dispara el agente, qué puede leer, qué puede escribir, qué modelo usar, cuántos turnos permitir, si tendrá MCP, si podrá usar proveedores como Bedrock o Vertex, y si el resultado será comentario, PR o cambio directo. Trata la migración desde beta como una revisión de seguridad, no como un reemplazo mecánico de YAML. Si el workflow anterior ya tenía permisos amplios, la actualización es un buen momento para recortarlos. El primer patrón es asistente bajo demanda: Claude solo actúa cuando alguien escribe @claude en un issue o pull request. Es el más fácil de introducir porque conserva intención humana explícita. El segundo patrón es revisión acotada: se ejecuta en PRs, pero solo para rutas críticas, cambios grandes o etiquetas concretas. Evita revisar cada cambio trivial y reduce coste de API y minutos de Actions. El tercer patrón es mantenimiento programado: informes diarios, actualización de documentación, triage de issues o propuestas de refactor. Aquí el riesgo no está en el comentario, sino en convertir recomendaciones automáticas en trabajo que nadie revisa. Empieza con permissions explícito en el workflow o en el job. Si el agente solo comenta en PRs, no necesita permisos amplios sobre contents. Si debe abrir un PR, necesitará escritura en contenidos y pull requests, pero no necesariamente acceso a packages, deployments o id-token. GitHub documenta que una acción puede acceder a GITHUB TOKEN desde el contexto github.token aunque no se lo pases explícitamente. Por eso no basta con ocultar el token como input: debes limitar los permisos concedidos al token. Para proveedores cloud, prefiere OIDC cuando sea posible en lugar de secretos largos. Si usas Bedrock o Vertex desde Actions, un rol temporal con condiciones de repositorio y rama suele ser más defendible que una clave estática guardada durante meses. Guarda ANTHROPIC API KEY como secreto de GitHub, nunca en el YAML ni en CLAUDE.md . Si el workflow usa otros secretos, separa los jobs: el job que comenta o revisa código no debería heredar credenciales de despliegue si no despliega. No metas datos sensibles en el prompt. Los títulos de PR, comentarios de issues y bodies de usuarios externos son entrada no confiable. Si interpolas ese texto dentro de comandos shell o prompts con permisos de escritura, estás mezclando prompt injection con CI injection. GitHub recomienda tratar entradas del contexto como potencialmente peligrosas en scripts. En workflows con agentes, el mismo criterio aplica doblemente: lo que viene de un comentario puede influir en una decisión del modelo y también en lo que acaba ejecutando el job. MCP es útil cuando Claude necesita leer documentación interna, consultar tickets o hablar con sistemas corporativos. Pero en CI, cada servidor MCP aumenta la superficie de permisos. No conectes el mismo servidor que usas localmente si incluye acciones de escritura que el workflow no necesita. Usa allowlists de herramientas y servidores. En Claude Code, claude args permite pasar opciones como --allowedTools , --max-turns , --model o una ruta de configuración MCP. Ese control debe estar en el YAML o en configuración versionada, no en una instrucción informal dentro del prompt. Si necesitas hooks, úsalos para validaciones deterministas: bloquear rutas sensibles, exigir tests después de editar, impedir cambios en migraciones sin etiqueta o registrar qué herramientas se invocaron. Los hooks no sustituyen revisión humana, pero reducen estados peligrosos antes de que el diff llegue al PR. Hay dos facturas. Una es GitHub Actions: cada ejecución consume minutos de runner, especialmente si el agente instala dependencias, corre tests o itera varias veces. La otra es la API de Claude: el coste depende del contexto, modelo, longitud del repo y número de turnos. Empieza con --max-turns conservador y timeouts de workflow. Añade concurrency para evitar que cinco comentarios disparen cinco sesiones simultáneas sobre el mismo PR. Si el workflow es automático en cada push, mide coste por PR, no solo coste mensual. La métrica útil no es cuántos comentarios genera Claude. Es cuántos comentarios terminan en cambios aceptados, cuántos falsos positivos produce y cuánto tiempo humano ahorra frente al coste de revisión adicional. Actívalo primero en un repositorio de riesgo medio, no en producción crítica ni en un sandbox irrelevante. Usa disparo manual por mención, permissions explícitos, ANTHROPIC API KEY en secrets, --max-turns bajo y un prompt que pida análisis antes de cambios. Durante dos semanas, prohíbe merges automáticos generados por el agente. Claude puede comentar, sugerir y abrir PRs, pero una persona debe aprobar. Registra duración de jobs, tokens aproximados, rutas tocadas, tests ejecutados y comentarios descartados. Después decide si ampliar por caso de uso. Si funcionó bien revisando PRs de backend, no significa que deba tocar despliegues, migraciones o infraestructura. La expansión sana es por permiso y por workflow, no por entusiasmo. permissions por job y evita permisos globales amplios. --max-turns , modelo y herramientas con claude args .Claude Code en GitHub Actions es potente porque acerca los agentes al sitio donde el equipo ya decide: issues, PRs y CI. Eso lo hace más útil que un asistente aislado, pero también más peligroso si hereda permisos sin diseño. La configuración responsable combina anthropics/claude-code-action@v1 , prompts estrechos, GITHUB TOKEN mínimo, secretos bien separados, límites de turnos, hooks, MCP con permisos mínimos y revisión humana. Si una pieza falta, el workflow puede seguir funcionando, pero será más difícil explicar qué hizo el agente cuando algo salga mal. Regla operativa:activa la automatización donde el comentario pueda cambiar una decisión técnica, no donde solo vaya a producir ruido revisable. Publicado originalmente en devaisemanal.com.