Code Review no Codex (/review): um passo a passo com exemplo
O /review é o revisor de diff dedicado do Codex (OpenAI Codex CLI): ele nunca edita arquivos na sua working tree, apenas lê e devolve uma lista priorizada de achados. Você pode rodá-lo pelo CLI, por uma extensão de IDE, pelo app desktop do ChatGPT ou pelo ChatGPT web, com 4 presets dependendo do escopo que você quer revisar. Neste passo a passo eu mostro a mecânica: os 4 presets, as flags de CLI não interativas para scripts/CI, um exemplo real de diff revisado e quando você realmente precisa do gh para ler um PR do GitHub.
- O Codex é uma superfície de recursos que muda rápido; os detalhes abaixo foram conferidos com a documentação oficial no momento em que escrevi (08/2026) - confirme na documentação ao vivo antes de depender do nome exato de uma flag ou de um comportamento.
O que o /review realmente faz
O /review roda um sub-turno separado e somente leitura: ele lê o diff que você aponta e nunca toca nos arquivos da sua working tree. A saída é uma lista priorizada de achados atrelada a posições no diff, não um parágrafo genérico de comentários. Essa é a diferença essencial em relação a colar um diff no chat e perguntar "isso parece ok?" - o /review é um fluxo distinto e estruturado, separado da sua sessão de código ativa.
Segundo a documentação oficial (learn.chatgpt.com/docs/code-review, acesso em 08/2026), ele foi feito para rodar antes de abrir um PR ou antes de dar merge - não é um modo "conserta pra mim" como uma tarefa normal do Codex. Se você está acostumada ao fluxo de review do Claude Code, o modelo mental se aplica: um passo separado, ler antes de escrever.
Os 4 presets de review
O Codex não tem um botão genérico de "review" - você escolhe um preset conforme o escopo do diff que quer revisar:
| Preset | Quando usar | O que ele revisa |
|---|---|---|
| Branch base | Terminou uma branch e quer revisar tudo antes de abrir um PR | O Codex encontra a merge base e revisa o diff da branch em relação a ela |
| Não commitado | No meio da edição, ainda não rodou git add e quer uma checagem antecipada | Mudanças em stage + fora do stage + não rastreadas |
| Um commit | Precisa revisar um commit específico, ex. antes de um rebase/squash | O conjunto de mudanças exatamente daquele commit, nada mais |
| Instruções personalizadas | Você tem seus próprios critérios, ex. só segurança ou um padrão interno de código | Livre - você descreve os critérios e o Codex revisa exatamente contra isso |
No composer, digite /review e escolha um preset no menu. Os três primeiros são "escolha um escopo de diff já existente"; o quarto é onde você escreve seus próprios critérios quando o escopo padrão não basta - ex. "só sinalize vulnerabilidades de autenticação" ou "revise contra o padrão de código no AGENTS.md".
Onde você pode rodar - CLI, IDE, app, web
O /review não está preso a uma única superfície. Quatro superfícies hoje o suportam:
- CLI - digite
/reviewno composer durante uma sessão no terminal, ou rode o comando não interativocodex reviewa partir de um script/CI (veja a seção de flags abaixo). - Extensão de IDE - o mesmo composer, embutido no VS Code/JetBrains, revisando bem ao lado do diff que você tem aberto, sem trocar de janela.
- App desktop do ChatGPT - tem um painel de review dedicado, útil quando você quer a janela de review separada da janela de código.
- ChatGPT web - rode um review direto do navegador, prático quando você não está com sua máquina de desenvolvimento por perto.
As quatro superfícies compartilham o mesmo mecanismo de review por baixo, mas a interface e a nomenclatura exatas de cada uma não têm garantia de bater 1 para 1 - vale confirmar na documentação ao vivo se algum nome de botão ou local de menu neste artigo parecer fora do lugar.
As flags de CLI não interativas (para scripts/CI)
Além do /review no composer, o Codex traz um comando não interativo codex review, feito para scripts ou um pipeline de CI. Segundo learn.chatgpt.com/docs/cli/reference, acesso em 08/2026:
# Review the diff against a base branch
codex review --base main
# Review one specific commit, with an optional title (--title requires --commit)
codex review --commit <sha> --title "Fix invoice endpoint"
# Review uncommitted changes (staged + unstaged + untracked)
codex review --uncommitted
# Freeform prompt, read directly from stdin
git diff | codex review -
# Strict-match config.toml when you need consistent CI behavior
codex review --base main --strict-config
Regra chave: as flags de escopo são mutuamente exclusivas - escolha exatamente uma entre --base, --commit, --uncommitted ou um PROMPT/stdin por execução, nunca misture. Esse é um ponto comum de renomeações silenciosas entre releases do Codex, então reconfira os nomes exatos das flags antes de fixá-los no CI.
Revisando um diff real - um exemplo prático
Teoria à parte, aqui está o tipo de achado que o /review costuma pegar numa pequena rota Node.js (encurtada para ilustrar, não é a saída bruta literal). A rota busca uma fatura por ID num sistema multi-tenant:
// Before
async function getInvoice(req, res) {
const invoice = await db.invoices.findOne({ id: req.params.id });
if (!invoice) return res.status(404).end();
res.json(invoice);
}
Achado 1 (severidade: alta, correto): "Falta o filtro de escopo por tenant - a rota consulta só por id, então um usuário do tenant A pode ver a fatura do tenant B adivinhando o ID. Adicione tenantId: req.user.tenantId ao filtro da consulta." Esse é um bug clássico de IDOR (referência direta insegura a objeto) - sintaticamente ok, roda sem erros, mas vaza dados entre tenants. A correção:
// After
async function getInvoice(req, res) {
const invoice = await db.invoices.findOne({
id: req.params.id,
tenantId: req.user.tenantId,
});
if (!invoice) return res.status(404).end();
res.json(invoice);
}
Achado 2 (severidade: média, precisou de um segundo olhar humano): o /review também sinalizou "esta rota não tem rate limiting." Isso está correto no nível do código - mas depois de checar o gateway.config.ts, a rota já fica atrás do rate limiter global do API gateway. O achado não estava tecnicamente errado, só faltava um contexto que o /review não enxerga (configuração fora do escopo do diff) - um caso em que um humano precisa confirmar antes de agir, não aplicar automaticamente.
Dois achados numa única execução mostram exatamente como ler a saída do /review: o achado 1 é um bug de verdade, corrija agora; o achado 2 é localmente correto, mas sem o contexto do sistema - ele precisa da sua confirmação, não de uma aplicação automática.
Revisando um PR do GitHub - o que precisa de gh
Dois mecanismos distintos do GitHub são fáceis de confundir se você ler por cima:
1. Ler o contexto do PR localmente (precisa do gh). Quando você revisa um PR pelo CLI, app ou IDE, o Codex precisa do gh instalado e autenticado para puxar as informações do PR (título, descrição, comentários). Segundo a documentação: se o gh estiver ausente ou não autenticado, os detalhes do PR podem não aparecer na barra lateral ou no painel de review. A configuração é um comando só:
gh auth login
2. Disparar um review na nuvem por comentário (não precisa do gh local). Comentar @codex review direto num PR do GitHub dispara um review que roda na nuvem - um mecanismo completamente separado da leitura local do contexto do PR acima, e não exige o gh na sua máquina. A condição é que o Codex cloud já esteja configurado para o seu repositório. Esse mecanismo pertence à configuração mais aprofundada do Codex Cloud - se você quiser configurar esse tipo de gatilho de review automático, isso está no guia do Codex Cloud; aqui é só uma linha para você não confundir os dois mecanismos.
Quanto você deve confiar num achado do /review?
Direto ao ponto: um achado do /review é uma sugestão priorizada, não um portão de merge automático. O achado 2 acima deixa isso claro - sintaticamente correto, com lógica localmente correta, mas errado porque falta o contexto do sistema. Esse tipo de falso positivo acontece mais do que você imagina quando um review vê só o diff, não o repositório inteiro.
Então um humano (ou, se você instalou o Engineer Kit do AgentKit, o skill/agente de code-review dele) ainda controla a decisão real de merge - o /review só encurta a parte da varredura mecânica para o revisor humano gastar energia na parte mais difícil. O AgentKit traz um comando /ak:review com um fluxo de review parecido que roda tanto no Claude Code quanto no Codex, útil se você quiser um processo pronto em vez de montar um; mas, para ficar claro, é um kit pago sobreposto - o próprio /review do Codex já é grátis e suficiente para review individual. Se ainda não configurou, veja antes como usar o AgentKit dentro do Codex.
Quer um agente de review dedicado rodando ao lado do /review do Codex? O Engineer Kit do AgentKit traz um skill/agente de code-review via /ak:review, funcionando no Codex e no Claude Code - ele não substitui o /review, adiciona uma camada extra pré-configurada.
Conheça o AgentKit Engineer Kit - 20% de desconto, agora $79.20 →
/review do Codex vs o fluxo de review do Claude Code
Mesma ideia, ferramenta diferente. O Claude Code tem seu próprio /review com o mesmo fluxo de "bloquear o merge enquanto um achado sério permanecer" - o processo de 3 passos e um exemplo real de achado estão no guia de code review com IA para o Claude Code (aquele artigo nunca menciona o Codex, e este não repete o conteúdo dele). Se você usa as duas ferramentas, o princípio de fundo vale dos dois jeitos: revisar sobre o diff, ordenar por severidade e, no fim, um humano ainda decide o merge.
Perguntas frequentes
Quais são os presets do /review do Codex?
Branch base (revisa o diff inteiro contra a merge base), Não commitado (em stage + fora do stage + não rastreadas), Um commit (o conjunto de mudanças daquele commit) e Instruções personalizadas (você descreve seus próprios critérios de review, livre).
O /review edita meu código?
Não. O /review roda um sub-turno somente leitura e nunca toca nos arquivos da sua working tree. Ele só devolve uma lista priorizada de achados - você decide o que corrigir ou ignorar.
Preciso do gh para revisar PRs?
Sim, para ler o contexto do PR localmente (título, descrição, comentários) pelo CLI/app/IDE - o gh precisa estar instalado e autenticado, ou os detalhes do PR podem não aparecer na barra lateral. Isso é diferente de comentar @codex review, que não precisa do gh local.
O que é @codex review no GitHub?
Uma forma de disparar um review na nuvem comentando @codex review direto num PR, separada de ler o contexto do PR localmente. Exige o Codex cloud já configurado para o seu repositório; os detalhes mais profundos pertencem ao Codex Cloud, fora do escopo deste artigo.
Dá para rodar reviews a partir de um script/CI?
Sim, pelo comando não interativo codex review com --base, --commit, --uncommitted ou um PROMPT/stdin - exatamente uma flag de escopo por execução, nunca combinadas.
O /review substitui uma aprovação humana?
Não. Um achado do /review é uma sugestão priorizada que pode estar errada por faltar contexto do sistema (veja o achado 2 acima). Um humano - ou um agente de review dedicado como o que o Engineer Kit do AgentKit traz - ainda dá a palavra final sobre o merge.
Conclusão
Resumindo: o /review do Codex tem 4 presets, roda no CLI/IDE/app/web, nunca edita arquivos por conta própria e precisa do gh quando você quer o contexto do PR localmente - enquanto o @codex review como comentário é um mecanismo separado na nuvem. Leia os achados como sugestões priorizadas, não como um portão de merge automático. Se você também usa o Claude Code, veja o fluxo de code review com IA para o Claude Code; se o Codex é novidade pra você, comece por o que é o OpenAI Codex.