Claude Code sin supervisión: límites del espacio de trabajo, modo sin interfaz y aceptación

1. Define el éxito antes de dejar una tarea sin supervisión

Una tarea útil sin supervisión es más concreta que «arregla el repositorio». Define la revisión de entrada, los directorios permitidos, las herramientas disponibles, el artefacto esperado, el tiempo máximo y las condiciones que requieren una decisión humana. Por ejemplo, un trabajo de documentación puede leer un diff proporcionado y crear un informe en el directorio de salida, sin herramientas de red ni cambios en el código. Ese contrato puede evaluarlo un comprobador independiente.

Separa tres resultados: el ejecutor arrancó, Claude devolvió una respuesta y el trabajo solicitado superó la aceptación. Un proceso puede iniciarse correctamente y después rechazar una herramienta. Puede devolver JSON convincente y dejar el archivo intacto. Puede completar un trabajo útil mientras un proceso hijo sigue activo. Convertir todo eso en un único indicador verde dificulta el diagnóstico.

El plan siguiente se refiere a un ejecutor bajo tu control y a datos desechables. No demuestra que tu versión instalada, tus credenciales o la política de tu empresa se comporten así. Anota la versión y la configuración efectiva antes de probar. Empieza con una carga inocua y reversible, y conserva la configuración anterior del lanzador para disponer de una recuperación concreta.

2. Qué cambió el 30 y el 31 de octubre

Los metadatos oficiales de GitHub sitúan v2.1.314 el 30 de octubre a las 01:06:26 UTC y v2.1.316 el 31 a las 01:01:35 UTC: las 09:06:26 y 09:01:35 en Singapur, respectivamente. El servicio oficial de última versión seguía indicando v2.1.316 durante esta investigación. Son fechas de publicación, no una prueba de que todas las instalaciones se hayan actualizado.

La oportunidad de ingeniería es aclarar el contrato entre ejecutor y agente. Una corrección documentada aporta un caso de regresión, no demuestra que todos los fallos relacionados sean imposibles. Fecha expresamente los antecedentes: los cambios de reintentos MCP y eventos de seguridad citados después proceden de la versión del 21 de octubre UTC, no de un nuevo anuncio de noviembre.

3. Distingue herramientas de archivos, comandos y servicios externos

Hay al menos cuatro vías de ejecución: herramientas de archivos integradas, comandos y procesos hijos del shell, procesos de integración locales y servicios remotos. Una regla de directorio puede controlar la primera sin limitar un proceso de pruebas de Python o una acción de base de datos en un servidor MCP. Un worktree separa trabajo de Git; no establece un límite del sistema operativo alrededor de todo lo que se inicia desde él.

La documentación del sandbox separa expresamente el aislamiento de comandos de las herramientas de archivos y web, los servidores MCP locales, los hooks y los procesos auxiliares. Una herramienta remota puede trabajar en otra máquina. Antes de configurar permisos, crea un inventario: qué proceso escribe, qué credencial utiliza y qué componente puede detenerlo.

Para un trabajo que solo produce un informe, eliminar una vía de ejecución innecesaria suele ser más fácil de verificar que permitirla y añadir numerosas excepciones. Es una decisión de arquitectura, no una promesa de que disponer de menos herramientas haga confiable cualquier entrada. Mantén separados en la configuración del trabajo el inventario de herramientas, los permisos y el aislamiento durante la ejecución.

4. Usa el nuevo límite de escritura sin inventar la referencia que falta

La nota de versión menciona permissions.blockWritesOutsideWorkingDirectories e indica que Write, Edit y NotebookEdit rechazan rutas fuera de los directorios de trabajo en todos los modos de permisos. Es una afirmación relevante sobre esas herramientas. No garantiza el comportamiento de comandos arbitrarios, servicios remotos ni todas las formas de sacar información de una sesión.

La referencia oficial de ajustes que revisamos no incluía una entrada específica para la nueva clave. Por eso no presentamos una configuración completa, un valor predeterminado, una regla de transmisión remota ni un caso límite de directorios adicionales que hayamos supuesto. Valida el ajuste en la versión que desplegarás y comprueba el rechazo real antes de depender de él. Una clave ignorada silenciosamente podría generar una confianza falsa.

Distingue también los nombres de herramientas de la sintaxis de reglas de rutas. La referencia de permisos indica que las reglas de edición por ruta utilizan Edit(path); las reglas Write(path) o NotebookEdit(path) con ruta no coinciden con las comprobaciones de archivos. Inspecciona la regla resuelta y su origen. Prueba una ruta interna, otra contigua y un directorio de prueba añadido deliberadamente, sin usar archivos reales del directorio personal.

5. Verifica el aislamiento de comandos, su disponibilidad y las alternativas

Una prueba del shell debe ejercitar un proceso hijo, no solo una llamada a Edit. Una compilación aprobada puede ejecutar scripts que abran archivos indirectamente. La documentación de reglas describe estos límites; el sistema operativo es quien puede restringir el subproceso mientras funciona. El sandbox integrado admite macOS, Linux y WSL2. Windows nativo no obtiene la misma protección porque exista un ajuste JSON.

Para ejecutores desechables compatibles, el ejemplo oficial de sandbox administrado combina los siguientes ajustes. Se reproduce como estructura que revisar, no como configuración que hayamos instalado o ejecutado:

{"sandbox":{"enabled":true,"failIfUnavailable":true,"allowUnsandboxedCommands":false}}

Estas opciones atienden la falta de aislamiento y los reintentos fuera del sandbox. No cubren todos los comandos excluidos ni los procesos externos al sandbox de comandos. La lectura predeterminada aún puede alcanzar gran parte del equipo, incluidas credenciales; revisa las lecturas y el entorno heredado además de las escrituras. Si necesitas confinar toda la cadena de herramientas, ejecuta el proceso completo en un entorno aislado bien configurado y revisa montajes y rutas de red.

Usa /sandbox para revisar la configuración. Haz que el agente ejecute la prueba inocua mediante su herramienta: escribirla en el indicador habitual ! puede probar otra vía sin aislamiento. Una prueba en macOS no valida una imagen WSL a la que le falten dependencias.

6. Decide qué puede descubrir una ejecución sin interfaz

El modo print es una interfaz de ejecución, no un límite automático de confianza. Un claude -p normal no muestra el diálogo de confianza y puede descubrir hooks y configuración MCP del proyecto. La corrección de CI del 30 de octubre para ultrareview y remote-control no debe generalizarse a esta vía distinta. Revisa la ejecución proporcionada por el repositorio antes de invocar una copia de terceros.

--bare reduce el descubrimiento automático de personalizaciones. No aporta aislamiento del sistema operativo y la documentación describe excepciones e interacciones entre fuentes de ajustes. Para Anthropic API, bare utiliza una credencial API en lugar del acceso por suscripción. La autenticación y la vía de facturación deben ser decisiones explícitas del despliegue; los ejemplos no realizaron ninguna solicitud al modelo.

La referencia de CLI distingue --allowedTools, que aprueba previamente las llamadas coincidentes, de --tools, que limita las herramientas integradas disponibles. Esta última opción no elimina las herramientas MCP. Revisa conjuntamente --setting-sources, los ajustes explícitos y la configuración MCP. Para imponer reglas de organización, comprueba los ajustes administrados en lugar de suponer que una opción local prevalece. Versiona juntos el lanzador y la configuración revisada.

7. Separa inventario MCP, credenciales y seguridad de las repeticiones

Una conexión MCP es una capacidad aparte. Enumera cada servidor, transporte, herramienta permitida y acción de negocio autorizada. Un servidor local puede iniciarse con acceso al equipo; uno remoto puede tener credenciales que Claude nunca ve. Limita el acceso y el alcance del propio servicio, en lugar de considerar una regla local de archivos como política de la base de datos o del gestor de incidencias.

La referencia MCP documenta que una llamada HTTP pendiente interrumpida puede repetirse una vez si la herramienta declara comportamiento de solo lectura o idempotente. La versión anterior v2.1.307 fecha esa corrección el 21 de octubre UTC. Declararlo no demuestra que sea seguro repetir un pago, mensaje o creación de recurso. Implementa y prueba el comportamiento real del servicio, utilizando un identificador de operación cuando corresponda.

Para la aceptación, usa un simulador local con registro. Cuenta las llamadas y el estado final tras interrumpir deliberadamente una respuesta. Un reintento correcto no demuestra entrega exactamente una vez. Nunca utilices un flujo de clientes reales como datos de prueba. No registres credenciales; prueba su caducidad con credenciales desechables, sin interrumpir un inicio de sesión de producción.

8. Haz coincidir el estado de salida, el JSON y el artefacto

La corrección del arranque facilita detectar un fallo que antes podía inducir a error. Tu envoltorio aún debe registrar por separado el código de salida, stdout, stderr, la duración y un identificador de tarea. Un código cero aporta información sobre el resultado del proceso, no pruebas independientes de que el cambio solicitado en el repositorio sea correcto.

La salida estructurada admite JSON y un esquema proporcionado. Comprueba la presencia de structured_output antes de consumirlo; la documentación indica que una ejecución puede terminar sin ese campo. Validar el esquema comprueba la forma. No demuestra que exista el archivo citado, que se ejecutara una prueba ni que se haya guardado un estado de negocio declarado.

Proporciona a un comprobador separado la ruta esperada del artefacto y las condiciones deterministas. Un informe puede exigir un archivo UTF-8 con referencias conocidas a los datos de prueba; una tarea de código necesita sus propias comprobaciones adecuadas. Compara los cambios con los archivos permitidos y rechaza modificaciones inesperadas. Distingue una acción denegada de un fallo de transporte y conserva la explicación del agente sin sustituir con ella la verificación del artefacto.

9. Acota el tiempo y comprueba la limpieza al cancelar

Establece un plazo en el ejecutor, fuera del bucle del modelo. Decide cómo solicita el cierre el lanzador, cuánto espera y cómo identifica únicamente los procesos de ese trabajo. Un tiempo agotado es un estado terminal de la tarea, no un permiso para dejar el mismo trabajo activo indefinidamente. No finalices procesos ajenos mediante coincidencias amplias de nombres.

La corrección de limpieza del 31 de octubre se refiere a comandos que quedaban activos cuando Claude Code salía por sí mismo en macOS y Linux. No demuestra la limpieza de todos los descendientes desvinculados ni la cancelación de trabajos ya enviados a un MCP remoto. Ambas situaciones requieren observaciones independientes.

En un entorno desechable, un hijo puede escribir una señal periódica solo dentro del directorio de prueba. Después de cancelar, comprueba que cesa y que termina el proceso del trabajo. Usa un simulador para tareas remotas asíncronas y verifica también su estado final. Si no existe cancelación, registra esa limitación y elige una carga cuyos efectos sean aceptables. Marca inequívocamente los artefactos incompletos como fallidos para que trabajos posteriores no los publiquen como terminados.

10. Recoge pruebas que expliquen una denegación sin guardarlo todo

Registra tarea, versión, revisión de configuración, espacio de trabajo resuelto, herramientas permitidas, resultado y veredicto del comprobador. Así se distingue «el límite funcionó» de «el modelo no lo intentó» o «el colector perdió el evento». Un registro de denegación sirve cuando se puede vincular al intento y al estado resultante observado de forma independiente.

La referencia de monitorización de Claude Code documenta claude_code.safety_event desde v2.1.307, pero también enumera llamadas sin ese evento. Sus campos propios evitan comandos y rutas en bruto; los atributos comunes pueden incluir el espacio de trabajo y el registro detallado opcional añade contenido. No etiquetes todo el flujo como anónimo ni supongas que representa cada rechazo.

Empieza con metadatos mínimos y unos pocos eventos sintéticos. Protege el destino del colector y define la retención. Confirma que llegan registros antes de usar su ausencia como prueba. Estas decisiones de herramientas de CLI son distintas de los análisis de costes API: ayudan a explicar límites de ejecución, no a conciliar facturas ni a demostrar todos los efectos externos.

11. Ejecuta una matriz de aceptación con datos desechables

Crea un directorio temporal nuevo con workspace/, sibling/ y results/. Pon texto centinela inocuo en sibling y registra su hash. Mantén todos los objetivos dentro del directorio temporal; no sustituyas los datos por credenciales reales, archivos personales o sistemas de clientes. El plan siguiente es una propuesta nuestra y no se ejecutó para este artículo.

Trata los casos negativos con tanta seriedad como la ruta de éxito. Conserva los hashes anteriores y posteriores, las opciones exactas y la fuente de política. Usa datos nuevos para cada variante. Probar en un espacio ya ampliado puede ocultar permisos excesivos de directorios adicionales y producir una aprobación engañosa.

12. Publica un paquete de configuración y amplía después la carga

Agrupa versión de CLI, lanzador, modelo, fuentes de ajustes, expectativas de política administrada, inventario MCP, plazos y comprobador. Asigna una revisión y un destino de reversión. Actualizar una dependencia sin su configuración correspondiente puede reintroducir el descubrimiento o cambiar cómo interpreta los fallos un envoltorio.

Empieza con informes u otros trabajos reversibles. Promueve el paquete cuando pasen los casos necesarios en cada entorno operativo previsto y después observa una carga real limitada. Define previamente cuándo detenerlo: cambia un artefacto externo, sobrevive un proceso inexplicado, se repite una acción no idempotente o no puede verificarse una configuración obligatoria.

Las incógnitas restantes son condiciones prácticas de publicación: los detalles aún no documentados de la nueva clave, las diferencias entre equipos, la cancelación remota y la integridad de la telemetría. Una nota oficial demuestra un cambio; tus pruebas registradas solo demuestran la configuración y la carga ejercitadas. Conserva visible ese alcance y repite los casos relevantes tras actualizar CLI, envoltorio, políticas o integraciones.