Dos cuentas en Codex CLI: cómo separar el acceso laboral y personal

Al utilizar Codex CLI tanto para proyectos personales como para tareas laborales, surge la necesidad de aislar los entornos y las cuentas. El indicador --profile no está diseñado para alternar entre cuentas: según la documentación sobre configuración básica, los perfiles solo superponen $CODEX_HOME/<name>.config.toml sobre la configuración principal (modificando parámetros como el modelo seleccionado, el nivel del sandbox o los servidores MCP), pero no cambian las credenciales de autenticación activas.

Para utilizar cuentas distintas, es necesario definir directorios independientes mediante la variable de entorno CODEX_HOME y completar el procedimiento de inicio de sesión (codex login) por separado para cada directorio.

Riesgos de copiar manualmente los archivos de sesión

Un artículo en Habr ilustra una solución alternativa ideada por un usuario: el autor automatizó el cambio de cuentas reemplazando los archivos de autorización mediante un script de bash y consultando la cuota restante a través de un endpoint no documentado de la interfaz web. El propio autor señaló de forma explícita el principal inconveniente de este enfoque: su dependencia de una API de backend privada e interna que puede cambiar en cualquier momento.

Manipular directamente los archivos de sesión también conlleva el riesgo de alterar el ciclo de vida de los tokens: cuando un refresh token se renueva en una ubicación, el duplicado copiado en otro directorio puede quedar invalidado. Un error de autorización similar tras copiar archivos se encuentra documentado en la issue #15410. Si bien un único informe no demuestra que cualquier copia vaya a fallar de forma obligatoria, transferir archivos a mano introduce riesgos operativos innecesarios. No debes leer ni copiar auth.json, ni tampoco utilizar APIs de backend privadas. El método estándar consiste en permitir que la propia CLI gestione las sesiones de manera independiente en directorios separados.

Almacenamiento de credenciales y restricciones de directivas

Antes de configurar directorios independientes, es fundamental comprender dónde y cómo se guardan los datos de autenticación. De acuerdo con la documentación sobre autenticación, el parámetro de configuración cli_auth_credentials_store admite los siguientes modos:

• file: las credenciales se guardan en un archivo local auth.json dentro del directorio CODEX_HOME.
• keyring: las credenciales se almacenan en el llavero o depósito de claves del sistema (Keychain en macOS, Secret Service en Linux).
• auto: la CLI intenta utilizar el keyring del sistema y recurre al almacenamiento en archivo si este no está disponible.
• ephemeral: la sesión se conserva únicamente en la memoria del proceso en ejecución.

Al planificar la separación de entornos, ten en cuenta las siguientes advertencias y restricciones:

• Utilizar directorios CODEX_HOME independientes no garantiza un aislamiento total si en el equipo rigen directivas centralizadas de la organización (Managed configuration / requirements.toml). Si un administrador fuerza un método de autenticación o un tipo de almacenamiento específico, esas reglas tienen prioridad sobre los parámetros locales.
• En el código fuente de la CLI, el servicio de llavero distingue los directorios mediante un hash de la ruta de CODEX_HOME (consulta storage.rs). Por consiguiente, asumir que diferentes directorios comparten automáticamente una única entrada en el keyring es incorrecto. No obstante, esto tampoco garantiza un aislamiento completo en todos los entornos: el comportamiento real del almacenamiento depende de la plataforma y de la configuración del sistema operativo, por lo que conviene verificarlo en el equipo de trabajo.
• No se puede asumir de antemano que los tokens residan exclusivamente dentro del directorio hasta que se confirme el modo de almacenamiento activo.

Configuración paso a paso de dos entornos

Configuraremos dos directorios explícitos: $HOME/.codex-personal y $HOME/.codex-work. El directorio preexistente ~/.codex permanece intacto y sin modificaciones.

Paso 1. Preparación de los directorios

Crea directorios específicos con permisos de acceso restringidos exclusivamente a tu usuario:

mkdir -p "$HOME/.codex-personal" "$HOME/.codex-work"
chmod 700 "$HOME/.codex-personal" "$HOME/.codex-work"

Si las directivas de tu organización permiten el almacenamiento en archivos, puedes definir explícitamente el parámetro cli_auth_credentials_store = "file" en el archivo config.toml de cada directorio antes de iniciar sesión:

cat << 'EOF' > "$HOME/.codex-personal/config.toml"
cli_auth_credentials_store = "file"
EOF

cat << 'EOF' > "$HOME/.codex-work/config.toml"
cli_auth_credentials_store = "file"
EOF

Si en tu dispositivo se aplican requisitos corporativos obligatorios de autenticación, utiliza en su lugar el modo de almacenamiento de credenciales aprobado por el administrador.

Paso 2. Autenticación independiente

El inicio de sesión mediante el navegador se vincula a la sesión activa en ese momento en chatgpt.com. El menú de perfil del navegador solo muestra la sesión web actual y no demuestra qué credenciales se guardaron en un CODEX_HOME específico. Debes verificar la cuenta y el Workspace correctos durante cada inicio de sesión en el navegador:

• Antes de iniciar sesión en el entorno personal, cambia a tu cuenta personal en el navegador.
• Antes de iniciar sesión en el entorno laboral, selecciona la cuenta corporativa o el Workspace correspondiente en el navegador.

Ejecuta el procedimiento de inicio de sesión para cada entorno por separado:

env CODEX_HOME="$HOME/.codex-personal" codex login

env CODEX_HOME="$HOME/.codex-work" codex login

En cada caso, confirma la solicitud de autorización en la ventana del navegador que se abra. Si tienes alguna duda, ejecuta el comando estándar env CODEX_HOME="..." codex logout y repite el inicio de sesión para ese directorio en concreto, comprobando de nuevo la cuenta activa en el navegador (no debes inspeccionar ni copiar manualmente los archivos de tokens).

Paso 3. Comprobación del estado de inicio de sesión

Verifica el estado de autorización en ambos directorios:

env CODEX_HOME="$HOME/.codex-personal" codex login status
env CODEX_HOME="$HOME/.codex-work" codex login status

El comando codex login status solo muestra el método de autenticación, pero no confirma la identidad de una cuenta de usuario específica. Ten en cuenta la diferencia en el origen de la facturación: el inicio de sesión con ChatGPT utiliza la suscripción o los límites incluidos del plan y Workspace correspondientes, mientras que el inicio de sesión mediante clave de API se factura por separado a través de OpenAI Platform.

Esta guía está diseñada para inicios de sesión con ChatGPT en dos cuentas distintas. Si status muestra una clave de API (API key), el escenario previsto no se habrá cumplido: revisa el paso de inicio de sesión en dicho directorio.

Paso 4. Ejecución de una tarea de prueba

Para comprobar el entorno laboral, ejecuta una tarea real en un repositorio de trabajo de prueba limitando los permisos con el sandbox en modo read-only:

cd /path/to/work-project
env CODEX_HOME="$HOME/.codex-work" codex exec --sandbox read-only "Lee README.md y describe el propósito del proyecto. No modifiques archivos"

Una prueba breve de solo lectura confirma que la sesión y el sandbox están operativos. Revisar la sección de uso (Usage) en tu cuenta o Workspace tras ejecutar una prueba ofrece únicamente una señal indirecta con posibles retrasos en los informes, no una prueba verificada de identidad. Si persiste alguna incertidumbre, ejecuta env CODEX_HOME="$HOME/.codex-work" codex logout y repite el proceso de inicio de sesión comprobando cuidadosamente la cuenta activa en el navegador.

Uso diario

Para el trabajo cotidiano, puedes ejecutar los comandos directamente anteponiendo la variable CODEX_HOME o definir dos funciones prácticas en el archivo de configuración de tu shell (~/.zshrc o ~/.bashrc):

codex-personal() {
  env CODEX_HOME="$HOME/.codex-personal" codex "$@"
}

codex-work() {
  env CODEX_HOME="$HOME/.codex-work" codex "$@"
}

Ejemplos de invocación enviando argumentos mediante "$@":

codex-work login status

cd /path/to/work-project
codex-work exec --sandbox read-only "Lee README.md y describe el propósito del proyecto. No modifiques archivos"

codex-personal