Deux comptes dans Codex CLI : séparer connexions pro et perso

Lorsque vous utilisez Codex CLI à la fois pour vos projets personnels et vos missions professionnelles, il devient indispensable de cloisonner les contextes et les comptes. L’option --profile n’est pas conçue pour changer d’utilisateur : d’après la documentation sur la configuration de base, les profils se contentent de superposer un fichier $CODEX_HOME/<name>.config.toml à votre configuration principale (afin d’ajuster des paramètres comme le modèle, le niveau de bac à sable ou les serveurs MCP), sans jamais modifier les identifiants actifs de la session.

Pour utiliser des comptes distincts, vous devez définir des répertoires indépendants au moyen de la variable d’environnement CODEX_HOME, puis effectuer la procédure de connexion (codex login) séparément pour chaque répertoire.

Risques liés à la copie manuelle des fichiers de session

Un article sur Habr illustre une pratique mise en place par un utilisateur : l’auteur y automatisait la bascule de compte en permutant des fichiers d’autorisation via un script bash, tout en interrogeant le solde de quota via un point de terminaison non documenté de l’interface web. L’auteur soulignait lui-même la faiblesse majeure de cette approche : sa dépendance vis-à-vis d’une API backend privée et interne susceptible d’évoluer ou d’être modifiée à tout instant.

La manipulation directe des fichiers de session risque également de perturber le cycle de vie des jetons : lorsqu’un refresh token est renouvelé à un endroit, la copie dupliquée dans un autre répertoire peut devenir invalide. Un cas d’erreur d’autorisation survenu après la copie d’un fichier est ainsi documenté dans l’issue #15410. Même si un rapport isolé ne prouve pas que chaque duplication échouera systématiquement, le transfert manuel de fichiers introduit des risques opérationnels superflus. Il ne faut ni lire ni copier auth.json, ni faire appel à des API backend privées. La démarche standard consiste à laisser le CLI gérer lui-même ses sessions au sein de répertoires distincts.

Stockage des identifiants et contraintes de stratégie

Avant de configurer des répertoires séparés, il est essentiel de comprendre comment et où sont enregistrées les données d’authentification. Selon la documentation sur l’authentification, le paramètre de configuration cli_auth_credentials_store accepte les modes suivants :

• file — Les identifiants sont enregistrés dans un fichier local auth.json situé dans le répertoire CODEX_HOME.
• keyring — Les identifiants sont placés dans le trousseau de clés du système (Keychain sur macOS, Secret Service sur Linux).
• auto — Le CLI tente d’utiliser le trousseau système et bascule vers le stockage fichier si le trousseau est indisponible.
• ephemeral — La session est conservée uniquement en mémoire vive pendant la durée du processus en cours.

Lors de la planification du cloisonnement, gardez à l’esprit ces limites et avertissements :

• Disposer de répertoires CODEX_HOME séparés ne garantit pas une isolation totale si des politiques d’entreprise centralisées s’appliquent à la machine (Managed configuration / requirements.toml). Si un administrateur impose une méthode d’authentification ou un type de stockage particulier, ces règles prévalent sur les paramètres locaux.
• Dans le code source du CLI, le service de trousseau distingue les répertoires par le hachage du chemin de CODEX_HOME (voir storage.rs). Par conséquent, affirmer que des répertoires différents partagent d’office la même entrée dans le trousseau est inexact. Pour autant, cela ne fournit aucune garantie d’isolation complète sur tous les environnements : le comportement réel du stockage dépend de la plateforme et de la configuration du système d’exploitation, ce qu’il convient de vérifier sur votre machine de travail.
• Vous ne pouvez pas présumer que les jetons résident exclusivement dans un répertoire tant que le mode de stockage effectif n’a pas été confirmé.

Configuration pas à pas de deux environnements

Nous allons mettre en place deux répertoires distincts : $HOME/.codex-personal et $HOME/.codex-work. Le dossier existant ~/.codex reste quant à lui intact et inchangé.

Étape 1. Préparation des répertoires

Créez les répertoires dédiés en restreignant les permissions à votre seul compte utilisateur :

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

Si la politique de votre organisation autorise le stockage sur fichier, vous pouvez définir explicitement cli_auth_credentials_store = "file" dans le fichier config.toml de chaque répertoire avant de vous connecter :

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 des exigences de sécurité d’entreprise obligatoires sont appliquées sur votre poste, utilisez plutôt le mode de stockage validé par votre administrateur.

Étape 2. Authentification indépendante

La connexion via le navigateur s’associe à la session active sur chatgpt.com. Le menu de profil du navigateur affiche uniquement la session web en cours et ne prouve aucunement quels identifiants ont été enregistrés dans un CODEX_HOME donné. Vous devez impérativement vérifier le compte et le Workspace sélectionnés lors de chaque connexion dans le navigateur :

• avant de vous connecter à l’environnement personnel, basculez sur votre compte individuel dans le navigateur ;
• avant de vous connecter à l’environnement professionnel, sélectionnez le compte d’entreprise ou le Workspace approprié.

Lancez la procédure de connexion séparément pour chaque environnement :

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

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

Dans chaque cas, confirmez la demande d’autorisation dans la fenêtre du navigateur qui s’ouvre. Au moindre doute, exécutez la commande standard env CODEX_HOME="..." codex logout et recommencez la connexion pour le répertoire concerné en vérifiant à nouveau le compte actif dans le navigateur (il ne faut ni inspecter ni copier manuellement les fichiers de jetons).

Étape 3. Vérification du statut de connexion

Vérifiez le statut d’authentification dans les deux répertoires :

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

La commande codex login status indique uniquement la méthode d’authentification, mais ne confirme pas l’identité de l’utilisateur connecté. Gardez à l’esprit la différence entre les sources de facturation : la connexion ChatGPT s’appuie sur l’abonnement ou les quotas inclus du forfait et du Workspace associés, tandis qu’une connexion par clé API est facturée séparément sur OpenAI Platform.

Cette procédure vise une connexion ChatGPT pour deux comptes distincts. Si status affiche une clé API, l’objectif n’est pas atteint : revoyez la phase de connexion pour ce répertoire.

Étape 4. Exécution d’une tâche de test

Pour vérifier l’environnement professionnel, exécutez une tâche concrète dans un dépôt de travail de test en limitant les permissions avec le bac à sable read-only :

cd /path/to/work-project
env CODEX_HOME="$HOME/.codex-work" codex exec --sandbox read-only "Lis le README.md et décris l'objectif du projet. Ne modifie aucun fichier"

Un court test en lecture seule permet de confirmer que la session et le bac à sable sont opérationnels. Consulter la section Consommation (Usage) de votre compte ou Workspace après le test n’apporte qu’un indice indirect assorti d’un délai d’actualisation, et non une preuve d’identité formelle. Si une incertitude subsiste, lancez env CODEX_HOME="$HOME/.codex-work" codex logout et répétez la procédure de connexion en contrôlant soigneusement le compte actif dans le navigateur.

Utilisation au quotidien

Pour votre travail quotidien, vous pouvez exécuter directement vos commandes en préfixant CODEX_HOME, ou déclarer des fonctions d’assistance dans le fichier de configuration de votre shell (~/.zshrc ou ~/.bashrc) :

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

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

Exemples d’appel avec transmission des arguments via "$@" :

codex-work login status

cd /path/to/work-project
codex-work exec --sandbox read-only "Lis le README.md et décris l'objectif du projet. Ne modifie aucun fichier"

codex-personal