Cómo usar Codex con seguridad en un proyecto existente
Un procedimiento de ramas, AGENTS.md, privilegio mínimo, cambios acotados, pruebas, secretos y revisión humana.
Traducción del procedimiento basado en documentación de Codex revisada el 25 de agosto de 2026. No afirma que UseAIVisora ejecutara Codex en un repositorio de prueba. No se ensayó el proceso completo en una cuenta real; el producto y su configuración pueden haber cambiado.
Asigna riesgo antes de pedir código
El nivel lo determina la acción de mayor impacto, no el tamaño aparente. Cambiar una sola línea de permisos puede alcanzar el nivel 3.
- Nivel 0, inspección: leer, explicar y proponer pruebas; sin editar.
- Nivel 1, cambio limitado: archivos nombrados, sin dependencias, esquema ni configuración.
- Nivel 2, cambio transversal: componentes compartidos, dependencias, construcción o migraciones.
- Nivel 3, estado externo: desplegar, rotar credenciales, cambiar cuentas, escribir producción o enviar mensajes.
Rama, aprobación, pruebas y reversión
- Capturar base: ruta, rama, cambios existentes, pruebas actuales y objetivo. Preserva trabajo ajeno. Detente si no están claros checkout o propiedad de cambios.
- Aislar: rama o worktree aprobado, archivos permitidos y acciones prohibidas. Obtén un espacio recuperable y acotado.
- Revisar plan: archivos, comandos, dependencias y efectos externos antes de implementar. Separa aprobaciones de alto riesgo; detente ante producción, secretos o refactorizaciones ajenas.
- Verificar: pruebas enfocadas, tipos, compilación y navegador o plataforma proporcionales al riesgo. Vincula evidencia a diferencias y entorno exactos.
- Preparar reversión: explica cómo revertir código y estado externo antes de aprobar lanzamiento. Distingue verificado, pendiente y no probado.
Controla ramas y worktrees
No ocultes una copia de trabajo modificada. Conserva cambios ajenos y aísla solo tras confirmar la base. Un worktree facilita tareas paralelas con rutas conocidas, pero no permite que dos agentes editen el mismo archivo sin riesgo.
Mantén commits comprensibles. No mezcles cambio de gestor de paquetes, formato masivo o migración de rutas con una corrección salvo necesidad.
Cada aprobación tiene un alcance
Debe nombrar operación y destino. Aprobar pruebas no aprueba instalar paquetes; editar web no aprueba tocar una app nativa; preparar lanzamiento no aprueba subir o desplegar.
Revisa comandos con comodines, variables, recursión o composición de shell. Inspecciona scripts ajenos antes de ejecutar. Nunca muestres contenido del entorno en registros para demostrar configuración.
Prueba en la capa de la afirmación
Un test unitario demuestra una regla pura, no renderizado, escucha HTTP, CSS en WebView ni propagación productiva. Acompaña cada afirmación con evidencia de esa capa y declara lo no comprobado.
Para errores, reproduce antes y añade regresión. Para UI, anchuras representativas y textos largos. Para rutas o metadatos, salida generada y respuesta HTTP real.
Conserva evidencia para volver atrás
Antes de lanzar registra commit, dirección de migración, diferencias de configuración y acciones externas que Git no revierte. Para borrar datos o rotar claves, obtén autorización nueva y documenta recuperación primero.
El selector de interfaz ayuda a elegir supervisión. Falta prueba de los mecanismos: no se observó sandbox, aprobación ni reversión de Codex en una sesión real; la configuración local exige una prueba acotada.
Fuentes
Estas son las fuentes oficiales del artículo original. Muchas de sus páginas están en inglés.