Duas contas no Codex CLI: como separar logins de trabalho e pessoais

Ao usar o Codex CLI para projetos pessoais paralelamente a tarefas de trabalho, surge a necessidade de isolar ambientes e contas. A flag --profile não foi projetada para alternar contas: de acordo com a documentação de configuração básica, os perfis apenas sobrepõem o arquivo $CODEX_HOME/<name>.config.toml à configuração principal (ajustando parâmetros como seleção de modelo, nível de sandbox ou servidores MCP), mas não alteram as credenciais ativas de autenticação.

Para usar contas diferentes, é necessário definir diretórios independentes por meio da variável de ambiente CODEX_HOME e realizar o procedimento de login (codex login) separadamente para cada diretório.

Riscos de copiar arquivos de sessão manualmente

Um artigo no Habr ilustra uma prática de usuário: o autor automatizou a troca de contas substituindo arquivos de autorização por meio de um script em bash e consultava o saldo de cotas utilizando um endpoint não documentado da interface web. O próprio autor destacou a principal desvantagem dessa abordagem: a dependência de uma API de backend interna e privada, sujeita a alterações a qualquer momento.

A manipulação direta de arquivos de sessão também pode corromper o ciclo de vida dos tokens: quando um refresh token é rotacionado em um local, uma cópia duplicada em outro diretório pode se tornar inválida. Um erro de autenticação decorrente da cópia de arquivos está documentado na issue #15410. Embora um relato isolado não comprove que qualquer arquivo de sessão copiado vá falhar inevitavelmente, a cópia manual de arquivos introduz riscos operacionais desnecessários. Não leia nem copie o auth.json e não faça chamadas a APIs privadas de backend. A abordagem padrão é permitir que a CLI gerencie as sessões de forma independente em diretórios distintos.

Armazenamento de credenciais e restrições de políticas

Antes de configurar diretórios separados, é importante compreender onde e como os dados de autenticação são salvos. De acordo com a documentação de autenticação, o parâmetro de configuração cli_auth_credentials_store suporta os seguintes modos:

• file — As credenciais são salvas em um arquivo local auth.json dentro do diretório CODEX_HOME.
• keyring — As credenciais são salvas no chaveiro do sistema (Keychain no macOS, Secret Service no Linux).
• auto — A CLI tenta utilizar o keyring do sistema e recorre ao armazenamento em arquivo caso o chaveiro não esteja disponível.
• ephemeral — A sessão é retida apenas na memória do processo em execução.

Ao planejar a separação de ambientes, mantenha em mente estes alertas e restrições:

• Diretórios CODEX_HOME separados não garantem isolamento total se políticas organizacionais centralizadas estiverem ativas na máquina (Managed configuration / requirements.toml). Se um administrador impuser um método específico de autenticação ou tipo de armazenamento, essas diretrizes terão precedência sobre a configuração local.
• No código-fonte da CLI, o serviço de keyring diferencia os diretórios aplicando um hash ao caminho de CODEX_HOME (veja storage.rs). Consequentemente, supor que diretórios distintos compartilhem automaticamente a mesma entrada no keyring está incorreto. No entanto, isso ainda não garante isolamento completo em todas as plataformas: o comportamento real depende das configurações do sistema operacional, portanto você deve validá-lo no ambiente em que for trabalhar.
• Não é possível presumir que os tokens residam exclusivamente dentro do diretório até que o modo de armazenamento ativo seja confirmado.

Passo a passo para configurar dois ambientes

Vamos configurar dois diretórios explícitos: $HOME/.codex-personal e $HOME/.codex-work. O diretório ~/.codex existente permanece intacto e não é modificado.

Passo 1. Preparar os diretórios

Crie diretórios dedicados com permissões de acesso restritas ao seu usuário:

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

Se as políticas da sua organização permitirem armazenamento em arquivo, você pode definir explicitamente cli_auth_credentials_store = "file" no arquivo config.toml dentro de cada diretório antes de iniciar o login:

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

Se houver requisitos corporativos obrigatórios de autenticação impostos ao seu dispositivo, utilize o modo aprovado pelo administrador.

Passo 2. Autenticação independente

A autenticação via navegador vincula-se à sessão ativa no momento no chatgpt.com. O menu de perfil no navegador mostra apenas a sessão web atual e não comprova quais credenciais foram salvas em um determinado CODEX_HOME. É necessário verificar a conta e o Workspace pretendidos durante cada login no navegador:

• Antes de entrar no ambiente pessoal, alterne para sua conta pessoal no navegador.
• Antes de entrar no ambiente de trabalho, selecione a conta corporativa ou o Workspace correspondente no navegador.

Execute o procedimento de login para cada ambiente separadamente:

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

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

Em cada caso, aprove o pedido de autorização na janela do navegador que for aberta. Em caso de qualquer dúvida, execute o comando padrão env CODEX_HOME="..." codex logout e refaça o login especificamente para aquele diretório enquanto confere a conta ativa no navegador (não inspecione nem copie manualmente arquivos de token).

Passo 3. Verificar o status do login

Verifique o status da autorização em ambos os diretórios:

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

O comando codex login status exibe o método de autenticação, mas não comprova a identidade de uma conta de usuário específica. Observe a diferença nas fontes de faturamento: o login via ChatGPT utiliza a assinatura ou os limites inclusos no plano e Workspace associados, enquanto o login por chave de API é cobrado separadamente na OpenAI Platform.

Este fluxo foi planejado para logins via ChatGPT em duas contas distintas. Se o status exibir uma chave de API, o cenário esperado não foi atendido — revise a etapa de login daquele diretório.

Passo 4. Executar uma tarefa de teste

Para validar o ambiente de trabalho, execute uma tarefa real em um repositório de trabalho de teste restringindo as permissões com a sandbox read-only:

cd /path/to/work-project
env CODEX_HOME="$HOME/.codex-work" codex exec --sandbox read-only "Leia o README.md e descreva o propósito do projeto. Não altere arquivos"

Um teste rápido em modo somente leitura confirma que a sessão e a sandbox estão funcionais. Verificar a seção de consumo (Usage) na sua conta ou Workspace após o teste fornece apenas um indício indireto sujeito a atrasos de atualização, não uma prova definitiva de identidade. Se restar qualquer incerteza, execute env CODEX_HOME="$HOME/.codex-work" codex logout e repita o procedimento de login prestando atenção à conta ativa no navegador.

Uso no dia a dia

No fluxo diário de desenvolvimento, você pode executar comandos diretamente inserindo CODEX_HOME como prefixo ou criar funções auxiliares no arquivo de configuração da sua shell (~/.zshrc ou ~/.bashrc):

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

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

Exemplos de invocação dessas funções com argumentos repassados via "$@":

codex-work login status

cd /path/to/work-project
codex-work exec --sandbox read-only "Leia o README.md e descreva o propósito do projeto. Não altere arquivos"

codex-personal