Codex CLI e Codex App em paralelo: como rodar duas ou mais contas e instâncias no mesmo Mac

O mesmo binário. O mesmo Mac. Duas contas completamente diferentes.

No primeiro terminal, codex abre autenticado na conta A — a sua conta principal, com os repositórios confiados, os skills, as sessões e a organização de sempre. No segundo terminal, codex abre autenticado na conta B — uma conta separada, com histórico, contexto e permissões próprias. Nenhum toca o estado do outro.

Parece mágica. Não é. É um detalhe de configuração que quase ninguém documenta direito: o Codex não é preso a um único diretório de configuração. Ele resolve tudo — login, config, sessões, skills, histórico — a partir de uma variável de ambiente chamada CODEX_HOME.

Se você entende isso, abre um leque de possibilidades que vai muito além de "rodar dois terminais":

• separar conta pessoal de conta de trabalho sem ficar fazendo logout/login;
• rodar duas instâncias em paralelo no mesmo repositório, cada uma com um modelo ou um profile de permissão diferente;
• isolar uma instância experimental (novo skill, novo provider) sem risco de corromper a principal;
• e, o mais interessante, fazer as duas instâncias conversarem entre si usando recursos nativos do Codex — sem instalar nada.

Este artigo é um tutorial completo, baseado numa configuração real que já roda em produção num Mac: a conta A em ~/.codex e a conta B em ~/.codex-lemon-dev, acessadas por wrappers chamados codex-lemon-dev-cli e codex-lemon-dev.

A tese central é simples:

Uma instância do Codex é definida pelo seu CODEX_HOME. Controle o CODEX_HOME e você controla quantos mundos isolados quiser rodar ao mesmo tempo.

O que uma "instância" do Codex realmente é

Antes de configurar qualquer coisa, vale entender o que você está configurando. Muita gente imagina o Codex como "um app" ou "um CLI". Na prática, o que existe é um binário (codex) que lê, a cada execução, um diretório de estado.

Por padrão, esse diretório é ~/.codex. É lá que moram:

~/.codex/
├── auth.json                 # login (tokens, account_id, auth_mode)
├── config.toml               # modelo, profiles, projetos, MCP servers, features
├── sessions/                 # sessões interativas
├── skills/                   # skills carregados sob demanda
├── plugins/                  # plugins e marketplaces
├── thread_history_1.sqlite   # histórico de conversas
├── logs_2.sqlite             # logs
├── state_5.sqlite            # estado do daemon/agentes
└── ...

Tudo que faz de uma instância "aquela" instância — a conta logada, o modelo, os projetos confiáveis, as conversas passadas — está dentro desse diretório. Não existe um estado global mágico em outro lugar.

Isso tem uma consequência prática enorme:

Se você apontar o CODEX_HOME para outro diretório, você tem uma instância completamente nova. Mesmo binário. Estado zero. Conta própria.

A documentação oficial confirma isso na página de environment variables: o CODEX_HOME sobrepõe o diretório de configuração padrão. O binário não se importa se esse diretório é ~/.codex, ~/.codex-lemon-dev ou qualquer outro caminho que você criar.

Por que você iria querer duas instâncias

Antes de sujar as mãos, deixe o porquê claro. Rodar duas instâncias não é vaidade de power-user. É a resposta a problemas reais.

1. Duas contas, zero logout

Quem trabalha com IA acaba com mais de uma conta OpenAI: uma pessoal, uma da empresa, talvez uma de teste. Fazer codex logout e codex login toda vez é desgastante e arriscado — você perde o contexto, esquece em qual conta está e, pior, mistura histórico.

Com CODEX_HOME isolado, cada conta vive no seu próprio diretório. Você nunca mais faz logout para trocar de conta. Só muda o wrapper que chama.

2. Paralelismo real no mesmo repositório

Dois agentes trabalhando ao mesmo tempo é a base de muita automação: um revisa enquanto o outro implementa, um pesquisa docs enquanto o outro roda testes. Com uma instância só, você fica preso a uma conversa por vez (ou a worktrees, que resolvem outra coisa).

Com duas instâncias, você tem dois cérebros independentes rodando de verdade em paralelo.

3. Isolamento de experimentos

Um novo skill, um novo provider via --oss, uma mudança agressiva de sandbox_mode — nada disso deveria arriscar a instância que você usa todo dia. Uma instância descartável é a forma mais barata de experimentar sem medo.

4. Perfis de risco diferentes

Você pode ter uma instância "fundo total" (sandbox danger-full-access) e outra "somente leitura" (sandbox read-only) apontando para o mesmo repositório. Escolhe a instância conforme o risco da tarefa, sem reconfigurar nada.

Passo 1 — A conta A (a padrão, ~/.codex)

A conta A normalmente já existe. É a que o Codex usa por padrão quando você roda codex sem nenhuma variável especial.

Para conferir qual conta está ativa:

codex login status

Se você ainda não fez login, o Codex oferece três caminhos oficiais:

# 1. Login via ChatGPT (abre o browser, fluxo OAuth)
codex login

# 2. Login via device code (útil em headless / CI)
codex login --device-auth

# 3. Login via API key (lê a chave do stdin)
printenv OPENAI_API_KEY | codex login --with-api-key

O resultado fica gravado em ~/.codex/auth.json. Você pode abrir esse arquivo e ver o campo auth_mode (chatgpt para login de assinatura, ou apikey) e o account_id — é assim que você confirma qual conta está de fato logada.

A página oficial de authentication detalha os métodos de sign-in. Vale a leitura se você trabalha com orgs múltiplas ou workload identity.

Passo 2 — A conta B (isolada em ~/.codex-lemon-dev)

Aqui está o coração do tutorial. Para criar uma segunda instância com uma segunda conta, você não instala nada de novo. Você só cria um diretório limpo e faz login lá dentro.

# Cria o novo CODEX_HOME
mkdir -p ~/.codex-lemon-dev

# Faz login da conta B DENTRO desse diretório
CODEX_HOME=~/.codex-lemon-dev codex login

A partir desse momento, ~/.codex-lemon-dev é um mundo completo: auth.json próprio, config.toml próprio, sessions/ próprias, skills/ próprios.

Confirme que deu certo comparando os dois auth.json:

grep account_id ~/.codex/auth.json
grep account_id ~/.codex-lemon-dev/auth.json

Se os account_id forem diferentes, você tem duas contas rodando lado a lado.

O gotcha que quebra todo mundo: OPENAI_API_KEY

Existe um erro silencioso que faz a conta B autenticar na conta errada — ou, pior, parecer logada sem estar.

O Codex resolve a autenticação nesta ordem de prioridade:

1. variável de ambiente (OPENAI_API_KEY, CODEX_ACCESS_TOKEN);
2. login salvo no CODEX_HOME (auth.json).

Se o seu shell exporta OPENAI_API_KEY globalmente (muito comum em .zshrc ou .bashrc), qualquer codex que você rodar vai ignorar o login do auth.json e usar a API key. Isso significa que a sua conta B, logada via ChatGPT, na prática autentica como a API key da conta A — o isolamento vai pro espaço sem nenhum aviso.

A correção é uma linha no wrapper:

unset OPENAI_API_KEY

É exatamente isso que o wrapper codex-lemon-dev-cli faz (você vai vê-lo completo daqui a pouco). Essa linha é a diferença entre "duas contas de verdade" e "duas janelas que no fundo são a mesma chave".

Passo 3 — Wrappers: transformando a troca de conta em um comando

Rodar CODEX_HOME=... codex toda vez funciona, mas é frágil. Você esquece o prefixo, o shell antigo vaza a variável, e o isolamento desanda.

A solução é um wrapper — um script mínimo que encapsula o CODEX_HOME e o unset da API key. Dois wrappers cobrem os dois produtos: CLI e App.

Wrapper do CLI: codex-lemon-dev-cli

Crie ~/.local/bin/codex-lemon-dev-cli:

#!/bin/zsh
# Conta B / Lemon Dev — CLI
# Isola a Conta B em ~/.codex-lemon-dev sem tocar em ~/.codex (Conta A).
set -e

export CODEX_HOME="$HOME/.codex-lemon-dev"
mkdir -p "$CODEX_HOME"

# O .zshrc exporta OPENAI_API_KEY globalmente, o que faria a Conta B autenticar
# por API key em vez do login ChatGPT proprio. Removido apenas neste processo.
unset OPENAI_API_KEY

exec codex "$@"

Torne executável:

chmod +x ~/.local/bin/codex-lemon-dev-cli

Agora, a troca de conta é explícita e à prova de erro:

codex                        # Conta A (padrão, ~/.codex)
codex-lemon-dev-cli          # Conta B (~/.codex-lemon-dev)

Wrapper do App: codex-lemon-dev

O CLI é simples. O Codex App tem uma pegadinha extra: ele é um app Chromium e, por padrão, é single-instance. Se você tentar abrir uma segunda cópia, o macOS simplesmente encaminha para a primeira instância já aberta — e o CODEX_HOME dela prevalece. Ou seja, sem cuidado, a "conta B" do App abre, na real, a conta A.

A correção é dar à segunda instância um --user-data-dir próprio. Cada user-data-dir é um perfil Chromium independente, que roda como processo separado e coexiste com o outro.

#!/bin/zsh
# Conta B / Lemon Dev — Desktop App
# Abre o Codex Desktop com CODEX_HOME apontando para a Conta B.
set -e

export CODEX_HOME="$HOME/.codex-lemon-dev"
mkdir -p "$CODEX_HOME"

unset OPENAI_API_KEY

APP="/Applications/ChatGPT.app"
BIN="$APP/Contents/MacOS/ChatGPT"

if [[ ! -x "$BIN" ]]; then
  print -u2 "codex-lemon-dev: $APP nao encontrado."
  exec codex app "$@"
fi

# O app e Chromium e e single-instance por user-data-dir. Com um perfil proprio,
# a Conta B abre como processo separado e coexiste com a Conta A.
PROFILE="$CODEX_HOME/chromium-profile"
mkdir -p "$PROFILE"

# Executa o binario direto: `open` nao propaga variaveis de ambiente.
exec "$BIN" --user-data-dir="$PROFILE" "$@"

Dois detalhes que fazem toda a diferença:

1. exec "$BIN" em vez de open — o open do macOS não propaga variáveis de ambiente para o processo filho. Se você usasse open -a ChatGPT, o CODEX_HOME se perderia. Executar o binário direto garante que o CODEX_HOME chegue intacto.
2. --user-data-dir dedicado — é o que quebra o single-instance do Chromium e permite as duas contas coexistirem.

A documentação oficial de desktop app e de config cobre a base do app e do arquivo de configuração, respectivamente.