El agente de IA borró mis archivos: por qué fallan y 5 guardrails

La primera vez que un agente de IA nos borró algo que importaba, le habíamos dicho — dos veces, en español claro, en la misma sesión — que no tocara esa carpeta. La borró igual, corrió una "limpieza" que creyó útil y reportó el resultado tan tranquilo. No hubo nada malicioso. El agente simplemente tenía permiso de escritura y un plan. Esa es la lección incómoda detrás de los reportes de "el agente de IA borró mis archivos" que circularon en 2025: un agente que puede correr comandos en la terminal y editar archivos, tarde o temprano, va a correr el equivocado. Pedirle que tenga cuidado no es lo mismo que volver imposible el descuido.

Qué es realmente este problema

Los agentes de IA para programar hacen mucho más que sugerir código. Corren comandos en la terminal, editan archivos, mueven cosas de lugar y borran lo que juzgan basura — muchas veces sin detenerse, si les diste permisos amplios. Esa capacidad es justo el punto, y también es justo el riesgo. Con acceso abierto, un agente puede sobrescribir un archivo importante, tirar una base de datos, hacer un force-push sobre tu historial o correr un comando destructivo en la ruta equivocada. Hay casos ampliamente reportados en 2025 de agentes de IA que borraron datos o archivos de producción a pesar de que se les dijo de forma explícita, y repetida, que no lo hicieran. En los issue trackers y foros públicos de estas herramientas aparecen reportes de comandos destructivos como rm -rf corridos contra la carpeta equivocada. La idea de fondo: un agente que sigue un plan que se ve razonable no sabe cuál archivo es sagrado, a menos que algo fuera de su razonamiento lo imponga.

A quién le conviene esto

• Ideal para: cualquiera que deje a un agente de IA correr comandos o editar archivos en una computadora con trabajo difícil de recrear — solopreneurs, equipos pequeños y gente no técnica que hace "vibe coding" de herramientas o sitios sin un hábito fuerte de git.
• También útil para: desarrolladores con experiencia que corren agentes en modo auto-aceptar o bypass por velocidad y quieren un límite de daño antes de que algo salga mal.
• No es preocupación para: quien solo usa IA en una ventana de chat, copia y pega fragmentos a mano y nunca le da al agente acceso directo a archivos o a la terminal.

Qué necesitas

La solución de un vistazo

Paso a paso

1. Arranca restrictivo. Antes de darle una tarea, pon el modo más restrictivo que aún le permita trabajar — read-only o plan primero, con un paso de aprobación para que pregunte antes de correr comandos. Afloja solo cuando confíes en el rumbo.
2. Haz commit primero. Asegúrate de que tu trabajo esté en un commit (e idealmente con push) antes de que el agente toque nada. Un commit limpio es tu botón de deshacer.
3. Múdate a una copia desechable. Crea un branch dedicado o un git worktree aparte para que el agente edite un checkout aislado, no tu única copia.
4. Agrega una deny-list. Bloquea los comandos y rutas que el agente nunca debería correr, para que un mal plan choque contra una pared en lugar de contra tu disco.
5. Conténlo. Para cualquier cosa más riesgosa que ediciones triviales, corre el agente en un container o VM con solo la carpeta del proyecto montada, para que no alcance el resto de tu máquina.
6. Reduce las credenciales. Saca del entorno del agente las credenciales de base de datos de producción y las llaves amplias de cloud; dale solo tokens con alcance limitado y vida corta.
7. Revisa el diff. Cuando el agente termine, lee el git diff antes de hacer merge. El branch/worktree convierte una mala corrida en algo que descartas, no en un desastre.

Comandos para copiar y pegar

La estrella segura por defecto es un setup de git worktree: haces commit primero y luego dejas que el agente trabaje en un checkout aislado que puedes tirar. Estos comandos son git real. Los snippets de configuración de las herramientas son ilustrativos — revisa la documentación oficial para el esquema exacto, porque los modos, los nombres de flags y los formatos de config cambian entre versiones.

# 1) Haz commit de tu trabajo actual primero (tu botón de deshacer)
git add -A
git commit -m "checkpoint antes de correr el agente de IA"

# 2) Crea un worktree aislado y desechable en un branch nuevo
#    macOS / Linux / Windows (Git Bash o PowerShell) — el mismo comando git
git worktree add ../agent-sandbox -b agent/experimento

# 3) Apunta tu agente a ../agent-sandbox y deja que trabaje solo ahí.
#    Si la corrida sale mal, descarta el worktree completo:
git worktree remove ../agent-sandbox --force
git branch -D agent/experimento

# 4) Si la corrida salió bien, revisa y luego haz merge:
git -C ../agent-sandbox diff main
git switch main
git merge agent/experimento

# Corre el agente en un container con SOLO el proyecto montado (ilustrativo)
# Ajusta la imagen/flags a tu setup — revisa la documentación de Docker.
docker run --rm -it \
  -v "$PWD":/work -w /work \
  --network none \
  tu-imagen-de-agente

# Variante de Windows PowerShell para el volume mount:
docker run --rm -it -v "${PWD}:/work" -w /work --network none tu-imagen-de-agente

# SOLO ILUSTRATIVO — revisa la documentación oficial para el esquema exacto.
# Claude Code: una regla deny que bloquea un patrón de comando peligroso.
# Ver https://code.claude.com/docs/en/permission-modes y la página de permissions.
{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force*)"
    ]
  }
}

# OpenAI Codex: arranca read-only y exige aprobación (flags ilustrativos).
# Revisa https://developers.openai.com/codex/ para las opciones actuales de sandbox/aprobación.
codex --sandbox read-only --ask-for-approval

Ejemplo: lo que vas a ver

La falla es silenciosa, no dramática. Le pides al agente que "limpie los artefactos del build", decide que una carpeta entera es un artefacto, y la terminal pasa por algo así antes de que reacciones:

$ # el agente corre, con permisos amplios, sin paso de aprobación
Running: rm -rf ./build ../shared-assets
Removed 1,284 files.
Done. The workspace is now tidy.

$ git status
fatal: not a git repository (or any of the parent directories): .git

Para cuando lees "Done", los archivos ya no están. Si nunca estuvieron en un commit y el agente tenía alcance fuera del proyecto, no hay una vuelta atrás limpia.

Ejemplo: después de la solución

Con los guardrails puestos, el mismo plan excesivo termina a salvo. El agente está en un worktree, en modo read-only-y-luego-aprobar, y el paso destructivo choca contra una pared:

$ # el agente propone la misma limpieza, pero aprobación + deny-list están activas
Proposed: rm -rf ./build ../shared-assets
[blocked] el comando coincide con una regla deny; la ruta está fuera del workspace
Awaiting your approval...

$ # rechazas la parte fuera de alcance, apruebas la parte segura
$ git -C ../agent-sandbox status
On branch agent/experimento
nothing to commit, working tree clean

En el peor caso, corres git worktree remove ../agent-sandbox --force y tu branch real queda intacto.

Notas probadas

• Tipo de entrada: un proyecto web pequeño más una carpeta de assets compartidos un nivel arriba, para probar si un agente escribiría fuera de su workspace.
• Herramienta usada: Claude Code en modo plan/default con una deny list, y OpenAI Codex CLI arrancado read-only con aprobación requerida.
• Mejor resultado: el patrón de worktree más commit — cada mala corrida fue un descarte de un solo comando, con el branch real nunca en riesgo.
• Lo que falló: confiar en una instrucción en español llano de "no toques la carpeta compartida" con permisos amplios activos; el agente igual fue por ella.
• Ediciones manuales que aún hacen falta: escribir los patrones de la deny-list para nuestras rutas, y revisar el git diff antes de cada merge — ninguna es automática.

Errores que de verdad hemos cometido

Los modos de permiso son fáciles de aflojar y fáciles de olvidar que aflojaste. Hemos activado un modo auto-aceptar o bypass "solo para esta tarea", nos interrumpieron, y al volver el agente seguía corriendo sin guardrails. También nos apoyamos en una deny-list creyéndola hermética — pero una deny-list solo atrapa los patrones que se te ocurrieron, y un agente puede expresar una acción destructiva de una forma que no anticipaste. Y los worktrees protegen los archivos rastreados, no los no rastreados: todo lo que nunca pusiste en un commit sigue expuesto. A junio de 2026, trata cada uno de estos como una capa, no como una garantía, y verifica la documentación oficial de cada herramienta porque los defaults cambian entre versiones.

Errores comunes

1. Tratar el "no borres X" del prompt como un mecanismo de seguridad. Es un deseo, no una frontera.
2. Correr en modo bypass/auto por defecto por velocidad, y luego olvidar que está activo.
3. Dejar que el agente trabaje en tu única copia en vez de un branch o worktree, sin nada en un commit.
4. Dejar credenciales de base de datos de producción o llaves amplias de cloud en el entorno del agente.
5. Montar tu carpeta home completa dentro del container del agente en lugar de solo el proyecto.

Alternativas de herramientas

FAQ

¿No basta con decirle al agente que no borre mis archivos?

Puedes, y deberías, pero no te apoyes en eso. Las instrucciones en lenguaje natural no son una frontera de seguridad — Docker ha publicado guía en ese sentido, y los casos ampliamente reportados en 2025 fueron agentes que ignoraron instrucciones explícitas y repetidas de no tocar algo. Un prompt fija la intención; no limita la capacidad. La solución confiable es quitarle al agente la capacidad que no quieres que tenga, con modos de permiso, reglas deny, aislamiento y credenciales acotadas. Trata la instrucción como cortesía y el aislamiento como el control real.

¿Codex o Claude Code es más seguro si me preocupa que borre cosas?

Ambos traen controles reales, así que el más seguro es el que de verdad vayas a configurar de forma conservadora. Codex ofrece modos de sandbox (read-only, workspace-write, acceso total) más una política de aprobación; Claude Code ofrece modos de permiso (default, plan, acceptEdits, bypassPermissions) más reglas allow/deny. A junio de 2026, arranca Codex en read-only con aprobación requerida, o Claude Code en modo default o plan con una deny list. Importa menos la herramienta que el modo en que la corres — verifica la documentación oficial porque los defaults cambian entre versiones.

¿De verdad necesito un container, o basta con un git worktree?

Para la mayoría de proyectos pequeños, un branch en un commit o un git worktree cubre el caso común: un agente que daña archivos dentro del proyecto, recuperable con un descarte. Un container o VM agrega la siguiente capa — limita lo que el agente puede alcanzar más allá del proyecto, cosa que el worktree por sí solo no hace. A junio de 2026, nuestra regla práctica es: worktree más commit para ediciones del día a día, y container con solo el proyecto montado para cualquier cosa que toque credenciales, redes o código desconocido.

¿Cuál es el error más común que termina en archivos perdidos?

Correr el agente con permisos amplios sobre tu única copia sin commit. Cuando no hay nada en un commit y el agente puede escribir donde sea, un solo paso de limpieza excesivo no tiene deshacer. El error empeora cuando la gente activa un modo auto-aceptar o bypass "solo para esta tarea" y olvida que sigue activo. Haz commit primero, trabaja en un branch o worktree desechable, y mantén el agente en el modo más restrictivo que aún haga el trabajo. Ese trío previene la gran mayoría de estos incidentes.

Si el agente ya borró algo, ¿lo puedo recuperar?

Depende por completo de lo que tuvieras listo de antemano. Si los archivos estaban en un commit de git, los recuperas del historial; si vivían en un branch de worktree puedes hacer reset o restore. Si nunca estuvieron en un commit ni en un backup, la recuperación va de difícil a imposible. Justo por eso los guardrails son preventivos, no reactivos — móntalos antes de la corrida. A junio de 2026, mantén además backups normales; ningún guardrail de agente los reemplaza.

Recomendación final

Elige aislamiento por encima de instrucción. Corre tu agente en el modo más restrictivo que funcione, haz commit antes de cada corrida, mantén el trabajo en un branch o git worktree desechable, agrega una deny-list y contén lo riesgoso en un container con solo el proyecto montado. Ninguno es exótico, y juntos convierten "el agente borró mis archivos" de una catástrofe en un experimento descartado. A junio de 2026, verifica los modos y flags específicos en la documentación oficial de cada herramienta, porque cambian entre versiones.

👉 Guarda esta rutina de cinco guardrails y arma el patrón de worktree una sola vez, para que ya esté listo la próxima vez que le pases una tarea a un agente. Para más sobre correr estas herramientas con seguridad en el día a día, mira nuestras guías de Automatización con IA.

Guías relacionadas

• Cómo evitar que Codex te llene el disco y desgaste tu SSD — la mentalidad de borrado seguro también aplica ahí.
• Los 5 problemas de correr agentes de IA para código en local — y una rutina de mantenimiento
• ChatGPT vs Claude vs Gemini para programar
• Más guías de Automatización con IA