Modelo padrão do Codex: defina, troque e fixe no config.toml
Como ver com qual modelo o Codex CLI inicia, trocar para uma sessão com /model, definir um padrão permanente com model e model_reasoning_effort no ~/.codex/config.toml, sobrescrever por projeto — e o que o release 0.161.0 mudou em 7 de outubro de 2026.
Respostas rápidas
- Confira o padrão atual sem editar nada: o banner de boas-vindas mostra o modelo ativo quando o Codex inicia, o /status revela dentro da sessão, e o codex doctor --summary informa quais arquivos de configuração carregaram.
- Troque o modelo só para esta sessão com o comando slash /model — a troca morre quando a sessão acaba e o padrão do seu config.toml volta.
- Defina o modelo permanentemente no ~/.codex/config.toml com model = "gpt-6.1-sol" e combine com model_reasoning_effort = "high" para controlar a profundidade do raciocínio.
- Um projeto confiável pode carregar o próprio .codex/config.toml que sobrescreve seu padrão de usuário, e uma pasta aninhada pode sobrescrever de novo — a flag do CLI ou o override com -c sempre ganha. O vídeo prova toda a pilha com uma tabela de escopos.
- O Codex CLI 0.161.0 (7 de outubro de 2026) tornou o GPT-6.1 Sol o modelo padrão nos catálogos embutido e da Amazon Bedrock — atualize e seu padrão pode ter mudado escondido.
Codex CLI Setup & Configuration: Which Setting Wins?
Canal:Coding With Chuck10:12
Config reference — official documentation
Docs:developers.openai.com/codex
Release rust-v0.161.0 — default model swap
Release:github.com/openai/codex
A gravação usa gpt-5.6-terra, gpt-5.6-sol e gpt-5.6-luna como valores de exemplo dentro de um laboratório descartável no CODEX_HOME; as chaves demonstradas — model, approval_policy, sandbox_mode, projects trust_level — são as chaves reais do config.toml da referência oficial. Os comandos em sessão /model e /status vêm da documentação oficial de comandos slash.
Os quadros do vídeo continuam propriedade de Coding With Chuck e são incorporados aqui como documentação passo a passo, com atribuição e deep links.
Definir o modelo padrão do Codex passo a passo
Descubra qual modelo está realmente rodando
- 1
Instale ou abra o Codex pelo hub oficial
Tudo começa em chatgpt.com/codex — a gravação abre o hub e o botão Download antes de tocar no terminal. Se você já tem o CLI, siga adiante; se parece que seu modelo padrão mudou sozinho, confira sua versão primeiro, porque os catálogos embutidos se mexem entre releases.
O hub chatgpt.com/codex com o botão Download for WindowsAssistir em 1:30 - 2
Confirme qual codex seu shell executa
Antes de culpar a configuração, garanta que está rodando o Codex que pensa. No PowerShell, o Get-Command codex resolve para codex.ps1 e mostra o caminho de instalação; no macOS ou Linux, o which codex faz o mesmo. Instalações múltiplas (npm mais um binário avulso) são a razão clássica de uma configuração editada parecer ignorada.
Get-Command codex resolvendo o script de inicialização e o caminho de origemAssistir em 2:00 - 3
Confira a versão e o estado de login
Rode codex --version e depois codex login status. A gravação mostra codex-cli 0.146.1 e "Logged in using ChatGPT". A versão importa aqui: o modelo padrão vem junto com o catálogo embutido do CLI, então duas máquinas com versões diferentes podem discordar até de qual é o padrão.
codex --version e codex login status em uma tela sóAssistir em 2:40 - 4
Inspecione a configuração efetiva com codex doctor
O codex doctor --summary imprime um relatório de saúde: a gravação mostra uma nota "mixed auth signals" (login ChatGPT mais uma variável de ambiente com API key), checks verdes para runtime, install, git e terminal, e uma seção Configuration confirmando config loaded. É o jeito mais rápido de ver se seu arquivo de configuração está sendo lido sequer.
O relatório do doctor com a nota de auth e os checks verdes do ambienteAssistir em 3:00
Defina o padrão no config.toml — usuário, projeto, subpasta
- 5
Localize seu Codex home
Configurações de usuário vivem em ~/.codex, e a variável de ambiente CODEX_HOME pode apontar o Codex para outro lugar completamente — a gravação monta de propósito uma pasta de laboratório descartável e aponta o CODEX_HOME para ela. Se um colega ou um script já definiu CODEX_HOME, suas edições no ~/.codex/config.toml caem num arquivo que o Codex nunca lê.
O script de setup anunciando o laboratório CODEX_HOME isoladoAssistir em 4:30 - 6
Abra o config.toml a nível de usuário
Dentro do Codex home mora o config.toml — o arquivo que a referência oficial de configuração documenta. A gravação expande a pasta codex-home no VS Code e seleciona o config.toml. Numa máquina normal é ~/.codex/config.toml; crie-o se ainda não existe, e mantenha a sintaxe TOML (valores entre aspas, sem vírgulas).
A pasta codex-home com o config.toml selecionado no VS CodeAssistir em 4:53 - 7
Defina o modelo padrão a nível de usuário
Adicione model = "gpt-5.6-terra" — o exemplo da gravação, usando um dos modelos do catálogo daquela época; hoje o padrão embutido é gpt-6.1-sol, então use o ID exato que você viu no /model. O mesmo arquivo carrega approval_policy = "on-request" e sandbox_mode = "workspace-write", mais um bloco [projects.'D:\...\config-lab'] trust_level = "trusted" marcando quais pastas podem carregar a própria configuração de projeto.
model, approval_policy, sandbox_mode e o bloco de projetos confiáveisAssistir em 5:00 - 8
Sobrescreva o modelo por projeto
Um repositório confiável pode carregar o próprio .codex/config.toml. A gravação adiciona um na raiz de config-lab com model = "gpt-5.6-sol" e o comentário "Trusted repository default for this demonstration" — a partir de agora, sessões iniciadas nesse repo usam Sol enquanto todo o resto segue com Terra. Lembre da regra da documentação: arquivos de projeto não podem sobrescrever chaves locais da máquina como model_provider, então deixe a configuração de provedores a nível de usuário.
O .codex/config.toml do projeto fixando gpt-5.6-solAssistir em 5:25 - 9
Aninhe um override para uma subpasta
Um nível mais fundo: config-lab/tools ganha seu próprio .codex/config.toml com model = "gpt-5.6-luna" e o comentário "More specific setting for work launched under tools/". Configurações de projetos confiáveis valem da raiz do repositório até o diretório de trabalho, então a pasta mais específica de onde você lançar define o modelo.
tools/.codex/config.toml fixando gpt-5.6-luna para aquela subárvoreAssistir em 5:50 - 10
Prove qual camada ganhou
A gravação fecha o ciclo com um script run-demo que imprime uma tabela "Effective model": user → terra, project-root → sol, nested-project → luna, cli-override → terra. Toda a pilha de prioridade numa tela — flags de linha de comando e overrides com -c vencem pastas aninhadas, que vencem raízes de projeto, que vencem sua configuração de usuário.
A tabela do modelo efetivo escopo por escopo, com notas do doctor abaixoAssistir em 6:00
Trocas de sessão, reasoning effort e a troca do 0.161.0
- 11
Troque o modelo por uma sessão com /model
Dentro de uma sessão, o /model abre o seletor para trocar de modelo na hora, e o /status reporta o modelo e o reasoning effort vigentes. Trocas de sessão são temporárias por design — saia e rode de novo, e o padrão do config.toml reassume o comando; por isso o /model é o jeito seguro de testar um modelo antes de fixá-lo.
- 12
Conheça a troca de padrão do 0.161.0 (2026-10-07)
O Codex CLI 0.161.0, lançado em 7 de outubro de 2026, afirma: "GPT-6.1 Sol is now the default model in the bundled and Amazon Bedrock catalogs". Se você nunca definiu uma chave model, um upgrade te move para lá em silêncio. Para manter um padrão anterior, escreva-o explicitamente no ~/.codex/config.toml e ajuste a profundidade com model_reasoning_effort ("high" no exemplo da documentação). Equipes também devem saber que agents.default_subagent_model define o modelo padrão dos agentes gerados, e que review_model sobrescreve o modelo usado pelo /review.
Quando o modelo padrão não gruda
Você editou um arquivo de configuração e o Codex continua iniciando no modelo antigo. Antes de editar de novo, percorra esta lista — a causa quase sempre é uma segunda camada de configuração acima da sua.
- 1Arquivo errado para o escopo de onde você lança — um .codex/config.toml de projeto sobrescreve seu ~/.codex/config.toml de usuário, e um aninhado fica acima da raiz do projeto. Rode codex doctor na pasta exata de onde você lança e veja quais configurações ele reporta como carregadas.
- 2Uma flag do CLI ou override pontual com -c vence qualquer arquivo — se um script wrapper, um alias ou uma extensão de IDE lança o codex com --model ou -c model=..., sua configuração nunca vota. Inspecione como o comando é realmente invocado.
- 3CODEX_HOME aponta para outro lugar — editar o ~/.codex/config.toml não adianta nada quando a variável de ambiente CODEX_HOME muda o home de lugar; é exatamente o que o laboratório do vídeo faz. Dê um echo na variável antes de culpar o parser.
- 4O projeto não é confiável — um .codex/config.toml numa pasta não confiável é pulado por inteiro. A confiança é concedida pela entrada projects.'<path>'.trust_level = "trusted" na sua configuração de usuário, como no arquivo de usuário da gravação.
- 5Chaves locais da máquina num arquivo de projeto — model_provider, model_providers, profile e profiles são ignorados em configurações locais de projeto por design. Se você tentou pendurar um provedor personalizado por projeto, mova-o para o nível de usuário e sobrescreva localmente só o id do modelo.
- 6ID de modelo errado ou renomeado — o valor de model precisa bater com o catálogo exatamente (o release 0.161.0 embaralhou os catálogos embutido e da Bedrock). Abra o /model para copiar o id exato e cole no config.toml em vez de digitar de memória.
Depois que as camadas de arquivos fazem sentido, o comportamento é totalmente previsível: padrão de usuário, depois profile, depois configurações de projetos confiáveis da raiz ao diretório, depois flags do CLI. A tabela de escopos da gravação vale a pena reproduzir na sua máquina — preveja as quatro linhas antes de rodar e você nunca mais vai se perguntar qual modelo o Codex vai usar.