Workspace trust y qué puede hacer un repo con tu agente

¿Qué es workspace trust y qué se activa al confiar en una carpeta?

En el artículo sobre hooks hablamos de los comandos que un agente ejecuta por su cuenta; en el artículo sobre seguridad MCP, de los servidores que se añaden a un repositorio, y en el artículo sobre el sandbox, de lo que limita los comandos del agente. Este artículo mira la pregunta que comparten los tres: cuando abres un repositorio con un agente de programación, ¿qué puede el repositorio hacer que haga el agente? La respuesta corta:

Workspace trust existe para la primera vía. La primera vez que abres una carpeta, la herramienta te pregunta si confías en ella y, hasta que lo hagas, no carga parte de la configuración del repositorio. Según la documentación de VS Code, el objetivo es evitar que el código se ejecute solo; por eso el Restricted Mode desactiva o limita los agentes, la terminal, las tareas, la depuración, los ajustes del espacio de trabajo y las extensiones. Esto es lo que queda desactivado en las cinco herramientas hasta que confías en la carpeta:

Fuente: documentación y notas de versión de las herramientas, 20 de octubre de 2026. «La documentación no lo dice»: en las páginas que leímos ese día no encontramos ninguna frase que lo describa. En Gemini CLI, la decisión se guarda en ~/.gemini/trustedFolders.json.

Las herramientas tienen algo en común: la confianza se da a la carpeta, no a su contenido. Claude Code ata la confianza a la raíz del repositorio, y cubre todo el repositorio. En Copilot CLI, cuando confías en una carpeta también para sesiones futuras, la pregunta no vuelve a aparecer; Gemini CLI también pregunta una sola vez por carpeta. Así que un hook que llega más tarde a un repositorio de confianza puede ejecutarse sin una nueva pregunta. El gusano de npm que vemos más abajo usó justo este camino.

En VS Code, confiar en una carpeta padre significa confiar en todas las carpetas que contiene. La documentación lo propone como forma de organizarse: guarda los repositorios de confianza en una carpeta y los que no conoces en otra, y confía solo en la primera. Si arrancas Claude Code directamente en tu directorio personal, la confianza solo vale para esa sesión y no se escribe en disco.

Sobre Gemini CLI, dos fuentes dicen cosas distintas. La página de Trusted Folders (actualizada el 23 de abril) dice que la función está desactivada por defecto; las notas de la versión v0.59.0 (8 de septiembre) dicen que la política de confianza pasó a ser «fail-closed». Revisa el ajuste security.folderTrust.enabled en tu propia instalación. El 18 de junio de 2026, Google dejó de dar servicio en Gemini CLI a los usuarios gratuitos y a los suscriptores de Google AI Pro y Ultra, y los dirigió a Antigravity CLI; con una clave de API de pago puedes seguir usando Gemini CLI.

¿Con qué archivos puede un repositorio ejecutar código?

Cuando un agente de programación abre una carpeta, varios archivos pueden ejecutar código por su cuenta. La mayoría entra en el repositorio con un commit y aparece en el diff del pull request. Uno no aparece en ningún diff:

Un mismo archivo lo pueden leer varias herramientas: Copilot CLI también lee el .claude/settings.json del repositorio, y Cursor CLI combina los hooks de Claude Code con los suyos. Explicamos los hooks en detalle en el artículo sobre hooks y los archivos MCP en el artículo sobre MCP. Aquí vemos cómo usan los atacantes estos archivos; los dos ejemplos son de agosto y septiembre.

Según el informe de Aikido, el 4 de agosto unos atacantes se hicieron con la cuenta de GitHub del mantenedor de la biblioteca keyv y metieron en los paquetes un gusano que roba credenciales. Al día siguiente había al menos 444 paquetes y 1.381 versiones afectados. Si el gusano encontraba un token de GitHub App entre las credenciales robadas, hacía commits en los repositorios a los que podía llegar, en hasta 50 ramas por repositorio. Esos commits añadían hooks a .claude/settings.json y a .vscode/tasks.json; su autor era claude y su mensaje, chore: update config.

Según el análisis de Elastic Security Labs, lo que se añadía para Claude Code era un hook SessionStart, que se ejecuta en cada sesión nueva, y para VS Code una tarea folderOpen, que se ejecuta al abrir la carpeta. La conclusión de Elastic: basta con que el desarrollador abra el repositorio para infectarse. Según Aikido, ni siquiera hacía falta npm install.

Puede que la pregunta de confianza ni siquiera entre en juego aquí: la confianza se da a una carpeta una vez, mientras que el hook nuevo llega con un commit a un repositorio que abres todos los días. VS Code tiene una barrera más: las tareas automáticas no se ejecutan nunca en una carpeta que no es de confianza y, en una carpeta de confianza, piden permiso una vez por defecto. En un pull request, donde se puede detectar es en el propio diff: una «actualización de config» que añade un hook a .claude/settings.json. Tanto el autor como el mensaje del commit parecían normales; fíjate en el contenido.

El segundo ejemplo es el archivo que no llega con un commit. Según GitSpawn, la investigación que Manifold Security publicó el 1 de septiembre, los agentes de programación ejecutan comandos de git en segundo plano para reunir contexto; algunos lo hacían antes de que escribieras nada, incluso antes de la pregunta de confianza. Al refrescar el índice, comandos como git status ejecutan el programa indicado en el ajuste core.fsmonitor, y git lee ese ajuste del propio .git/config del repositorio. El resultado, tal como lo describe Manifold: el repositorio nombra un comando y git lo ejecuta con tus permisos, fuera del sandbox y sin ninguna petición de aprobación.

Importa cómo llega el archivo. Según Manifold, clonar el repositorio desde una dirección maliciosa no activa el fallo, y tampoco fetch ni pull; git no transfiere ese ajuste. Para que el ataque funcione, el repositorio tiene que llegar con su propia carpeta .git: en un zip, en una unidad compartida, en una carpeta sincronizada o en un USB. La regla de la investigación cabe en una frase: cualquier ajuste que nombre un programa puede ejecutarlo. El día de la publicación, 4 de los 8 hallazgos estaban corregidos; revisa las notas de versión de tu herramienta. Este archivo no aparece en ningún diff y puede ejecutarse antes de la pregunta de confianza; solo puedes revisarlo cuando la carpeta llega a tus manos.

¿Un agente que se ejecuta en CI hace la pregunta de confianza?

No; no hay nadie a quien preguntar. Las herramientas se diferencian en lo que hacen en su lugar: unas usan la configuración del proyecto, otras no la cargan y otras se detienen. Si un agente revisa tus pull requests en CI, mira esta tabla:

Fuente: documentación y notas de versión de las herramientas, 20 de octubre de 2026. «La documentación no lo dice»: en las páginas que leímos ese día no encontramos ninguna frase que lo describa. Cursor CLI se comporta así desde enero de 2026. Cuando la confianza en carpetas está activada, Gemini CLI detiene una ejecución no interactiva con FatalUntrustedWorkspaceError.

La documentación de permisos de Claude Code muestra este caso en una tabla propia. En una ejecución de claude -p en una carpeta en la que nunca se confió, no se usan las reglas allow, pero sí los hooks del archivo de ajustes y el bloque env. La parte de MCP la tratamos en el artículo sobre MCP. La documentación también dice qué hacer con un repositorio que no escribiste tú: con --setting-sources user, Claude Code no lee los archivos de ajustes del proyecto; con --bare, no lee del proyecto hooks, skills, subagentes ni plugins, pero el bloque env del proyecto se sigue aplicando. Para desactivar los hooks, pasa disableAllHooks a esa ejecución con --settings. Según la documentación, no basta con escribirlo solo en tus propios ajustes de usuario, porque los ajustes del proyecto pueden imponerse a los tuyos y volver a ponerlo en false.

En Copilot CLI, vigila una variable: si COPILOT_ALLOW_ALL vale exactamente true, la CLI confía en la carpeta sin preguntar y carga todo lo que hay en el repositorio, incluidos los hooks que ejecutan comandos de shell. Si ves esta variable en un workflow, comprueba si el job se ejecuta en la rama del pull request. La documentación de Codex hace además una advertencia propia para CI: en los jobs que hacen checkout del código del repositorio o lo ejecutan, no pongas la clave de API como variable de entorno a nivel de job; los scripts de build, los tests y los hooks de instalación de las dependencias pueden leerla.

En Gemini CLI, este hueco se convirtió en un aviso de seguridad y quedó cerrado. Según el aviso GHSA-wpqr-6v78-jr5g de GitHub (24 de abril de 2026, crítico, CVSS 10,0), las versiones anteriores confiaban automáticamente en la carpeta cuando se ejecutaban en CI. El aviso nombra el riesgo con claridad: workflows de CI que revisan pull requests enviados por usuarios. Las variables de entorno puestas en la carpeta .gemini/ de un repositorio así podían llevar a ejecución remota de código. La vulnerabilidad se corrigió en Gemini CLI 0.39.1 y en la acción run-gemini-cli 0.1.22; ahora también en una ejecución no interactiva tienes que confiar en la carpeta de forma explícita.

¿Qué es la prompt injection y puede un pull request engañar a un bot de revisión?

La prompt injection consiste en meter instrucciones en un texto que lee un modelo para cambiar su comportamiento. OWASP distingue dos tipos: la prompt injection directa, hecha con la propia entrada del usuario, y la prompt injection indirecta, escondida en una página web o un archivo que el modelo lee desde fuera. Según OWASP, el texto ni siquiera tiene que ser visible para una persona; basta con que el modelo lo lea. En un agente de programación, ese texto puede ser un archivo del repositorio, la descripción de un pull request, una issue o un comentario.

Workspace trust no cierra esta vía: en cuanto ejecutas el agente en una carpeta, también le haces leer el texto de esa carpeta. Por eso la documentación de VS Code recomienda abrir en Restricted Mode un proyecto que no has revisado. Cualquier archivo que el agente meta en su contexto puede llevar a una prompt injection; en Restricted Mode, los agentes no se ejecutan en absoluto. Frente al texto te quedan dos cosas: de dónde se leen las reglas y qué puede hacer el agente.

GitInject (7 de junio de 2026) midió hasta dónde puede llegar esto en CI, en workflows reales de GitHub. Los investigadores probaron las configuraciones de workflow de 4 proveedores de IA y documentaron 11 ataques. Se reparten en cuatro clases: inyección en archivos de configuración, robo de credenciales, manipulación del juicio y ataques a la disponibilidad. Todos los proveedores probados resultaron vulnerables a al menos una clase en su configuración por defecto. Según los autores, las vulnerabilidades más graves no vienen del comportamiento del modelo, sino de cómo la infraestructura de CI maneja las credenciales y los archivos de configuración.

Para engañar a un bot de revisión ni siquiera hace falta escribir instrucciones. PRWeaver (3 de agosto de 2026) construyó 208 ataques en 10 repositorios reales, cada uno validado ejecutándolo, e hizo revisar cada uno en cuatro presentaciones (832 casos) a 3 agentes de revisión con 6 configuraciones de modelo. Cuando los pull requests se revisaban uno a uno, se detectó entre el 50 % y el 60 % de los ataques; cuando se revisaban 24 pull requests de una vez, la tasa bajaba a entre el 16 % y el 22 %. Meter el ataque dentro de un cambio real, con una descripción creíble que explica las dos cosas, redujo la tasa de detección entre 10 y 18 puntos porcentuales. Repartir el ataque en varios commits cambió el resultado como mucho 5 puntos.

La conclusión de los autores: ocultar funciona mejor cuando los cambios inofensivos y los maliciosos están juntos delante del revisor, o cuando el propósito que dice la descripción hace que el diff parezca razonable. La lista del artículo sobre cómo revisar código generado por IA tiene un punto para esto: cada afirmación de la descripción debe tener su reflejo en el diff. Después de PRWeaver, pregunta también lo contrario: ¿cada cambio del diff tiene un motivo en la descripción?

La forma de dirigir a un bot de revisión de manera duradera es cambiar sus reglas. Si el archivo de reglas se lee de la rama del pull request, el pull request también puede cambiar las reglas de su propia revisión. La documentación de las herramientas dice cosas distintas sobre esto:

Fuente: documentación de las herramientas, 20 de octubre de 2026. «La documentación no lo dice»: en las páginas que leímos ese día no encontramos ninguna frase que lo describa.

Un ejemplo de cómo acotar lo que puede hacer el agente es GitHub Agentic Workflows: el agente se ejecuta con permisos de solo lectura, y las escrituras, como un pull request que abriría, no se aplican enseguida, sino que quedan en espera. Según la documentación, antes de aplicarlas se ejecuta un job aparte que busca en la salida intentos de prompt injection, secretos filtrados y código malicioso. Un agente engañado solo puede hacer tanto daño como permitan los permisos que le diste.

¿Qué hacer con un repositorio o un pull request que no conoces?

En resumen: la pregunta de confianza se hace una vez, nunca en CI, y no filtra el texto. Qué hacer depende del caso:

• Un repositorio que no conoces. No confíes en él. VS Code recomienda dejar la carpeta en Restricted Mode si tienes dudas, y Cursor, abrir un repositorio que no es de confianza en un editor de texto sencillo. Si necesitas trabajar en él con un agente, ábrelo en una máquina virtual o en un contenedor; la documentación de Claude Code también recomienda máquinas virtuales. Un sandbox por sí solo no basta: en Claude Code, el sandbox solo cubre los comandos de shell, y los hooks y los servidores MCP quedan fuera. Los detalles están en el artículo sobre el sandbox.
• Una carpeta que te pasan. Si una carpeta que llegó en un zip, en una unidad compartida o en un USB contiene .git, como recomienda Manifold, lee .git/config antes de abrirla con un agente, o vuelve a clonar el repositorio desde su origen.
• Un agente que revisa en CI pull requests de forks. No dejes que el agente cargue la configuración del proyecto: pasa --setting-sources user en Claude Code, y no uses COPILOT_ALLOW_ALL en Copilot CLI ni --trust en Cursor CLI en la rama del pull request. La guía de GitHub del 7 de mayo de 2026 considera permissions: read-all un valor por defecto razonable y dice que nunca hagas eval de la salida del modelo. No pongas secretos en el paso del agente.
• Un pull request que toca un archivo de ajustes o de reglas. Lee un diff que toque alguno de los archivos de la segunda sección como un cambio de seguridad; la guía de GitHub también considera bloqueante cualquier cambio que debilite la CI. Si tu bot de revisión lee sus reglas de la rama del pull request, un cambio en el archivo de reglas decide también cómo se revisará ese pull request; léelo también como código.

Hicimos las mismas preguntas a nuestro propio servicio de revisión. Nuestra herramienta de revisión de código con IA, diffox, clona el repositorio de GitHub desde cero en una carpeta vacía en cada revisión; como un clon no trae .git/config, el camino que usó GitSpawn no nos alcanza. Como contamos en el artículo sobre la arquitectura, las reglas se leen de la rama en la que se fusionará el pull request. El autor de un pull request desde un fork puede escribir el diff y los nombres de archivo como quiera; pero el texto suyo que pasa a nuestro comentario no puede abrir una etiqueta HTML ni convertirse en un enlace. Esta regla existe para impedir que aparezca un enlace de phishing con nuestro nombre, que alguien cierre la sección plegada para escribir una falsa sección «sin problemas» y que se filtren datos a través de una imagen.

Preguntas frecuentes

¿Qué es workspace trust?

Es que la herramienta de programación o el editor te pregunte, la primera vez que abres una carpeta, si confías en ella, y no cargue parte de la configuración de la carpeta hasta que lo hagas. El objetivo es evitar que los hooks, las tareas y los servidores MCP puestos en un repositorio se ejecuten antes de que los mires. Lo tienen Claude Code, Codex, GitHub Copilot, Cursor y Antigravity CLI; en el editor de Cursor está desactivado por defecto. La confianza se da a una carpeta una vez, y no impide que el texto de la carpeta dirija al agente.

¿Qué activa confiar en una carpeta en Claude Code?

Claude Code ata la confianza a la raíz del repositorio, y cubre todo el repositorio. Después de confiar se usan las reglas allow y los directorios adicionales del .claude/settings.json del proyecto, los hooks y los servidores MCP de los subagentes y los plugins que vienen del repositorio; los hooks y el bloque env del archivo de ajustes también se ejecutan en la sesión. Los servidores de .mcp.json tienen su propia pregunta. La pregunta solo aparece en una sesión interactiva; claude -p y el SDK nunca preguntan. Si lo arrancas en tu directorio personal, la confianza solo vale para esa sesión.

¿Cómo quito una carpeta de confianza?

Depende de la herramienta. En VS Code, abre el editor de Workspace Trust (Workspaces: Manage Workspace Trust) y quita la carpeta de la lista de carpetas de confianza. En Copilot CLI, edita la lista trustedFolders de ~/.copilot/config.json. En Gemini CLI, escribe /permissions en esa carpeta; todas las decisiones están en ~/.gemini/trustedFolders.json. En Codex, pon el trust_level de ese proyecto en untrusted en ~/.codex/config.toml. Claude Code guarda la confianza en el campo hasTrustDialogAccepted de ~/.claude.json; un comando para deshacerla, la documentación no lo dice. La documentación de Cursor y la de Antigravity tampoco hablan de esto.

¿Se puede desactivar workspace trust en VS Code?

Sí: el ajuste security.workspace.trust.enabled (activado por defecto) desactiva la función por completo, y la opción --disable-workspace-trust solo para esa sesión. La recomendación de VS Code es la contraria: si tienes dudas, deja la carpeta en Restricted Mode; la confianza puedes darla después. En Restricted Mode están desactivados los agentes, las tareas, la depuración y la terminal. Puedes reunir los repositorios que abres a menudo en una carpeta padre y confiar solo en esa carpeta, y guardar los repositorios que no conoces en otra.

¿Qué es la prompt injection?

Es esconder instrucciones en un texto que lee un modelo para cambiar su comportamiento. OWASP distingue dos tipos: la prompt injection directa, hecha con la propia entrada del usuario, y la prompt injection indirecta, escondida en una página web, un archivo o un comentario que el modelo lee desde fuera. En los agentes de programación destaca la segunda: un archivo del repositorio, la descripción de un pull request o el texto de una issue entran en el contexto del agente. Según OWASP, el texto ni siquiera tiene que ser visible para una persona; basta con que el modelo lo lea.

¿Puede un pull request engañar a una herramienta de revisión de código con IA?

Los estudios muestran que sí. En PRWeaver, agentes de revisión con IA detectaron entre el 50 % y el 60 % de los ataques ocultos cuando los pull requests se revisaban uno a uno, y entre el 16 % y el 22 % cuando se revisaban 24 pull requests juntos; una descripción creíble bajó aún más la tasa. En GitInject, los 4 proveedores probados eran todos vulnerables a al menos una clase de ataque en su configuración por defecto. Comprueba si tu herramienta lee sus reglas de la rama del pull request o de la rama en la que se fusionará. En diffox, las reglas se leen de la rama en la que se fusionará el pull request, y el texto del pull request que pasa a su comentario no puede convertirse en una etiqueta ni en un enlace.

¿Aparece la pregunta de confianza con claude -p o en CI?

No. Según la documentación de Claude Code, claude -p y las sesiones del SDK no muestran nunca la pregunta de confianza; se usan los hooks del archivo de ajustes del repositorio, el bloque env y apiKeyHelper, y los servidores de .mcp.json se conectan sin preguntar. En un repositorio que no escribiste tú, arráncalo con --setting-sources user o --bare; para desactivar los hooks, pasa disableAllHooks con --settings. El modo -p de Copilot CLI no carga los hooks del repositorio en una carpeta que no es de confianza; Cursor CLI se detiene si no pasas --trust.