Por que criei o cloak: um perfil por diretório para CLIs de IA

O cenário é comum para quem usa CLIs de IA no terminal: várias contas ao mesmo tempo. Uma conta de trabalho no claude. Uma pessoal no codex. Talvez a chave de API de um cliente para um repositório específico.

O problema é que essas ferramentas não foram pensadas para isso. Escrevi o cloak para resolver esse ponto.

O problema: estado global

As CLIs guardam o estado de autenticação de forma global, em um único diretório dentro da home. O Claude Code usa ~/.claude/. O Codex usa ~/.codex/. Não existe um mecanismo nativo para dizer "o repositório A usa a conta de trabalho e o repositório B usa a pessoal" sem fazer logout e login de novo.

Na prática, trocar de contexto vira uma destas opções:

exportar variáveis de ambiente na mão;
mover arquivos de configuração de um lado para o outro;
torcer para não usar a chave errada no projeto errado.

Nenhuma delas escala. E a última é um risco real: uma ANTHROPIC_API_KEY ou OPENAI_API_KEY definida no ambiente acaba chegando à sessão da CLI, seja qual for o projeto.

A ideia: um perfil por diretório

As próprias CLIs já oferecem a peça que faltava. Cada uma aceita uma variável de ambiente que redireciona o diretório de configuração inteiro: CLAUDE_CONFIG_DIR para o Claude, CODEX_HOME para o Codex. Se a variável estiver definida antes de o binário iniciar, sessão e configurações passam a viver no caminho indicado.

O cloak automatiza isso. Ele parte do diretório atual e sobe até a raiz do sistema de arquivos procurando o arquivo .cloak mais próximo. Esse arquivo diz qual perfil usar:

# ~/repos/company-api/.cloak
profile = "work"

Com o perfil resolvido, o cloak define a variável certa apontando para o diretório daquele perfil, remove variáveis de ambiente conflitantes e passa o controle para a CLI real via exec(2).

Não há wrapper rodando em segundo plano. Não há daemon. Não há estado persistente. No Unix, o processo do cloak é substituído pela CLI e pronto.

Se nenhum .cloak for encontrado, ele usa o default_profile definido em ~/.config/cloak/config.toml. Se houver um .cloak na raiz do repositório e outro em uma subpasta, vale o mais próximo.

O que acontece em cada execução

O fluxo do cloak exec é curto:

Carrega a configuração global.
Resolve o perfil pelo .cloak ou pelo perfil padrão.
Garante que existe o diretório daquela CLI dentro do perfil, como profiles/work/claude.
Aponta a variável de configuração da CLI para esse diretório.
Remove as variáveis listadas em remove_env_vars.
Aplica a política de permissões ao primeiro comando repassado, quando houver.
Executa o binário real (exec no Unix).

A remoção de variáveis é o que fecha a porta para o vazamento. Na configuração padrão, o cloak remove ANTHROPIC_API_KEY e ANTHROPIC_AUTH_TOKEN antes de abrir o Claude, OPENAI_API_KEY antes do Codex, GEMINI_API_KEY e GOOGLE_API_KEY antes do Gemini, e XAI_API_KEY e GROK_CODE_XAI_API_KEY antes do Grok.

Como fica no dia a dia

Primeiro, crio os perfis:

cloak profile create work
cloak profile create personal

Depois, vinculo um repositório a um perfil. O cloak use escreve o .cloak no diretório atual:

cd ~/repos/company-api
cloak use work

Em seguida, faço login uma vez em cada perfil:

cloak login claude work
cloak login codex work
cloak login gemini work

O cloak não implementa OAuth. Ele só redireciona a home da CLI. Quando o diretório do perfil está vazio, a própria CLI entra no fluxo de login normal, e as credenciais ficam gravadas dentro daquele perfil.

Por fim, aliases no shell para não precisar digitar cloak exec toda vez:

alias claude='cloak exec claude'
alias codex='cloak exec codex'
alias gemini='cloak exec gemini'
alias grok='cloak exec grok'

A partir daqui, o diretório decide a conta:

cd ~/repos/company-api && claude   # ← usa o perfil "work"
cd ~/side-project      && claude   # ← usa o perfil "personal"

Esse é o ganho principal. Eu não troco de conta. Eu troco de diretório, e a conta vem junto.

Conferir antes de confiar

Isolamento invisível gera dúvida. Por isso o cloak tem comandos para inspecionar o contexto:

cloak profile show
cloak profile account work
cloak doctor

O profile show mostra o perfil resolvido e os caminhos de ambiente de cada CLI. O profile account lê os arquivos locais de credencial de cada CLI dentro do perfil e mostra o melhor indício de identidade que encontrar, ou not authenticated. O doctor valida configuração, binários, estrutura dos perfis e dicas de credenciais.

Se o perfil resolvido não for o esperado, a primeira coisa a checar é se existe um .cloak inesperado mais acima na árvore de diretórios.

O que veio depois

Com perfis isolados, outras coisas passaram a fazer sentido por perfil. O cloak hoje também:

lê snapshots locais de uso de Claude, Codex e Grok e ranqueia perfis pela capacidade semanal disponível, com cloak limits e cloak limits rank;
instala, remove e diagnostica servidores MCP dentro de um perfil, usando a sintaxe nativa de cada CLI;
configura uma política de permissões para shell, arquivos, rede e comandos, sincronizada com os perfis do Claude;
gera backups cifrados com GPG/AES-256, com credenciais OAuth incluídas só quando --include-credentials é passado de forma explícita.

Exemplo de MCP do catálogo embutido instalado em um perfil:

cloak mcp add filesystem --for codex,claude,grok --profile work --yes

E um backup, conferindo antes o que vai entrar:

cloak backup --dry-run
cloak backup

No Unix, diretórios de perfil são criados com permissão 0700 e os arquivos criados pelo cloak usam 0600.

Limites

Alguns limites que vale saber antes de adotar:

O gerenciamento de perfis está habilitado só para claude, codex, gemini e grok. Um bloco [cli.*] extra no config.toml é aceito pela configuração, mas não habilita a CLI no exec nem no login; o comando falha com um erro temporarily disabled. Ampliar essa lista exige mudança no código.
Se o direnv exportar a mesma variável, como CLAUDE_CONFIG_DIR ou CODEX_HOME, vence quem escrever por último. O ideal é escolher um mecanismo por CLI.
A política de permissões no cloak exec olha o primeiro comando repassado. Ao abrir um agente interativo sem comando, não há o que classificar.
O projeto se identifica como MVP.

Como experimentar

O cloak é escrito em Rust. A instalação é a partir do código-fonte, com o repositório clonado:

cd cloak
cargo install --path . --force

Para validar:

which cloak
cloak --help

Depois disso, o caminho mínimo é criar um perfil, rodar cloak use no repositório, fazer o login pelo cloak login e configurar os aliases. A documentação completa, em inglês e em português, está no repositório: github.com/juniormartinxo/cloak.