OpenAI Codex Security CLI: quanto custa uma varredura real

Um arquivo, nove linhas de código Express e uma conta que chegou ao teto de US$ 6,00 em oito minutos e meio. Esse foi o resultado do meu primeiro teste com o novo Codex Security CLI: 7,0 milhões de tokens de entrada consumidos para gerar um modelo de ameaças de 1.605 palavras — e nenhum achado. Para quem pensa em colocar a ferramenta no CI, a conclusão é direta: o custo acompanha o ciclo de raciocínio do agente, não o número de linhas. Configure --max-cost antes de qualquer outra coisa.

A ferramenta ainda merece atenção porque é a primeira versão do Codex Security que pode rodar sem entregar seu repositório a um GitHub App.

O que o CLI faz — e o que ele não faz

O Codex Security não é exatamente uma novidade. A OpenAI o colocou em prévia de pesquisa em março de 2026 como um serviço hospedado: você conecta um repositório do GitHub, ele cria um modelo de ameaças, examina o histórico de commits em um ambiente isolado e apresenta os achados em um workspace do ChatGPT. A SecurityWeek informou que o recurso está disponível para clientes ChatGPT Pro, Enterprise, Business e Edu.

O lançamento de 28 de julho de 2026 é outra proposta. O openai/codex-security é um CLI e SDK em TypeScript sob licença Apache-2.0, publicado no npm como versão 0.1.0 às 17:09 UTC; a 0.1.1 saiu às 23:48 UTC no mesmo dia. No momento da publicação, o projeto mostrava 1,8 mil estrelas e 28 issues abertas. É um projeto que acabou de nascer.

A instalação exige Node.js 22 ou superior e Python 3.10 ou superior, já que o mecanismo de varredura vem como um plugin Python empacotado:

npm install @openai/codex-security
npx codex-security info

O comando info é a forma mais rápida de conferir o que foi instalado:

sdkVersion: 0.1.1
bundledPluginVersion: 0.1.14
cliVersion: 0.1.1
codexVersion: 0.144.6
model: gpt-5.6-sol
reasoningEffort: xhigh

As duas últimas linhas resumem toda a questão do custo. Nesta instalação, as varreduras usam por padrão o GPT-5.6 Sol com esforço de raciocínio xhigh. O parâmetro --model permite trocar o modelo, mas o plugin foi construído em torno de um ciclo agêntico profundo — e é esse ciclo que entra na conta.

A superfície de comandos é maior do que o produto hospedado sugere: scan, validate, patch, scans para listar, mostrar, repetir, comparar e buscar correspondências, bulk-scan, export para CSV, JSON ou SARIF, install-hook e ainda um modo mcp, que registra a ferramenta como servidor MCP. Vale notar que o info também exibe scanMcp: false, pois não é possível cancelar varreduras pelo transporte MCP.

Dois caminhos de autenticação — e o que pode travar tudo

npx codex-security login autentica com uma conta ChatGPT; --device-auth atende máquinas sem interface gráfica; e OPENAI_API_KEY serve para CI. Quando há uma chave e uma sessão autenticada ao mesmo tempo, varreduras interativas perguntam qual usar, enquanto execuções não interativas dão prioridade à chave de API.

Há uma ressalva na documentação oficial que merece atenção redobrada: varreduras do repositório inteiro também podem exigir Trusted Access for Cyber. Nem fazer login nem definir uma chave de API concede esse acesso. Planeje uma solicitação de acesso, não apenas uma autenticação.

Usando o OpenAI Codex Security CLI com um endpoint compatível

O primeiro erro é definir OPENAI_API_KEY com uma chave de terceiros e esperar que o tráfego seja redirecionado automaticamente:

codex-security: Authentication failed using OPENAI_API_KEY.

A chave, sozinha, não muda o destino porque o runtime embutido do Codex continua apontando para a URL-base da própria OpenAI e ignora OPENAI_BASE_URL. É preciso sobrescrever a configuração do provedor via --codex, que recebe valores TOML:

OPENAI_API_KEY=sk-... npx codex-security scan . --auth api-key --max-cost 5 \
  --codex 'model_provider="relay"' \
  --codex 'model_providers.relay.name="relay"' \
  --codex 'model_providers.relay.base_url="https://your-endpoint/api/v1"' \
  --codex 'model_providers.relay.env_key="OPENAI_API_KEY"' \
  --codex 'model_providers.relay.wire_api="responses"'

Dois detalhes me custaram uma execução cada. Valores sem aspas falham com Invalid --codex TOML value. E wire_api="chat" é rejeitado diretamente pelo Codex 0.144.6, com um erro que aponta para a discussion #7782 e instrui a usar responses. Seu endpoint precisa implementar a Responses API, e não apenas Chat Completions.

O mesmo ajuste determina onde cai a cobrança do modelo. O CLI sempre calcula a estimativa com os preços de tabela da OpenAI para o GPT-5.6 Sol, independentemente do endpoint escolhido. Portanto, o total em execução é uma conta baseada em tokens, não a sua fatura. Se você encaminhar o mesmo tráfego por um endpoint que cobra metade do preço de tabela, a execução de US$ 6,03 abaixo custará cerca de US$ 3, enquanto o CLI continuará exibindo US$ 6,03.

O custo de uma varredura

Leia os números abaixo com uma condição importante: as cinco execuções passaram por endpoints de terceiros compatíveis com OpenAI, pois eu não tinha uma autenticação ChatGPT Business ou Enterprise para testar o caminho oficial. Os dados mostram o CLI como um desenvolvedor comum consegue executá-lo hoje, não o comportamento do serviço hospedado em uma conta com acesso habilitado.

O repositório de teste é propositalmente pequeno e propositalmente vulnerável. São nove linhas e quatro falhas inseridas:

const express = require('express');
const { exec } = require('child_process');
const db = require('./db');
const app = express();
const API_KEY = "sk-live-9f3a2b7c1d4e5f6a8b9c0d1e2f3a4b5c";
app.get('/u', (req, res) => db.query("SELECT * FROM users WHERE id = " + req.query.id, (e, r) => res.json(r)));
app.get('/ping', (req, res) => exec("ping -c 1 " + req.query.host, (e, o) => res.send(o)));
app.get('/f', (req, res) => res.sendFile(__dirname + "/files/" + req.query.name));
app.listen(3000);

Há SQL concatenado como string, child_process.exec usando um parâmetro de query, um caminho sendFile sem sanitização e uma chave fixa no código. Ambiente: macOS, Node v22.17.0, Python 3.14.6, @openai/[email protected], plugin empacotado 0.1.14; todas as execuções ocorreram em 2026-07-29, entre 02:20 e 03:05 UTC.

Os valores em dólar são estimativas do próprio CLI, exibidas durante a varredura e armazenadas em scans list. Eles são calculados a partir da contagem de tokens nos preços de tabela da OpenAI, e não pelo que um endpoint realmente fatura. A entrada em cache explica por que os totais parecem baixos diante do volume de tokens. A execução 2 fecha exatamente usando US$ 5,00 por milhão de tokens de entrada nova, US$ 0,50 por milhão de entrada em cache e US$ 30,00 por milhão de tokens de saída:

331,330 x $5.00/M   = $1.657
6,654,720 x $0.50/M = $3.327
34,946 x $30.00/M   = $1.048
                      ------
                      $6.032   (CLI reported $6.03239)

As mesmas três tarifas reproduzem os totais das cinco execuções até os centavos, uma verificação útil caso seus próprios números pareçam estranhos.

Nenhuma das cinco execuções foi concluída. Todas pararam por orçamento, e scans list registra cada uma como phase: preflight, status: failed, com coverage: worklistRows 0. Em outras palavras, nenhuma chegou à etapa que reporta vulnerabilidades.

A execução 4 é o controle. Meu primeiro repositório estava incompleto de propósito: não havia package.json e o código importava ./db, mas o arquivo não existia. O próprio modelo de ameaças da ferramenta marcou isso como uma incógnita explícita. Depois de reconstruir o projeto corretamente, com quatro arquivos, treze linhas e dependências declaradas, o custo aumentou em vez de cair: US$ 8,54 e 7,9 milhões de tokens de entrada.

A curva não é linear. O custo sobe lentamente nos primeiros três minutos e então dá dois saltos; cada um coincide com o agente ampliando o trabalho. O log explica o mecanismo uma vez, aos 51 segundos: Preflight: worker delegation supported (up to 8 worker slots).

95% dos tokens de entrada vieram do cache, sinal de que o mesmo contexto foi reenviado a cada turno, em vez de ser lido novamente. O preço por token é baixo, mas essa continua sendo a maior linha da conta. Sete milhões de tokens somam bastante mesmo na tarifa de entrada em cache — para um arquivo de nove linhas.

É aqui que a estimativa repetida de aproximadamente US$ 0,02 por 1.000 linhas de código deixa de fazer sentido. Nessa conta, meu repositório deveria custar uma fração de centavo.

Reduzir o raciocínio ajuda menos do que parece

A execução 5 define model_reasoning_effort="low" no mesmo projeto da execução 4. O consumo caiu de cerca de 1,0 milhão de tokens por minuto para 0,5 milhão por minuto; assim, o mesmo dólar compra o dobro de tempo de execução. Ainda assim, ela atingiu o teto na mesma fase de preflight, sem nada para reportar. Cortar a taxa de consumo pela metade não resolve se o pipeline precisa de mais turnos do que o orçamento permite de qualquer forma.

--max-cost é ponto de controle, não freio de emergência

A documentação oficial do CLI informa que requisições já em andamento podem terminar acima do limite. O que ela não diz é quanto acima. Nas cinco execuções, o excesso variou de 0,5% a 46%: o limite de US$ 1,00 parou em US$ 1,46; o de US$ 6,00, em US$ 6,03; e os três limites intermediários terminaram entre 2% e 7% acima. O estouro equivale ao que o agente tinha em voo, portanto o caso caro é uma distribuição de workers chegando perto do teto. Defina o limite abaixo do valor que você realmente não pode ultrapassar.

O hook de pre-commit não é o caminho barato

A resposta mais óbvia para uma varredura completa fora de controle seria analisar apenas o que mudou. Fiz um commit com uma base limpa, adicionei uma linha vulnerável — uma cláusula LIKE montada por concatenação de strings — e executei --working-tree --base HEAD.

Custou mais do que a primeira varredura completa: 9m46s, 2,276,160 tokens de entrada e parada em US$ 3,06, com teto de US$ 3,00. Ela avançou mais no pipeline do que as varreduras completas, gerando uma lista priorizada de revisão (rank_input.jsonl, deep_review_input.jsonl) antes de esgotar o orçamento, mas também não produziu achados. Limitar o escopo ao diff não reduz o contexto de cada turno: o agente ainda lê o repositório, ainda escreve um modelo de ameaças completo e ainda distribui tarefas para workers.

install-hook conecta a ferramenta a um hook Git de pre-commit que bloqueia achados de alta severidade e erros de varredura. Antes de instalar isso para uma equipe, calcule o preço de uma única varredura de diff na sua base de código, porque esse hook pode acrescentar minutos e dólares a cada commit.

O que a ferramenta ainda não consegue enxergar

O modelo de ameaças produzido para nove linhas é um bom trabalho. Ele identifica as quatro fronteiras de confiança, chama o módulo ./db ausente de incógnita explícita e não atribui ao Express proteções que não consegue verificar. Também declara sua própria limitação sem rodeios: "Controls not present in the repository must not be assumed."

Essa é a restrição estrutural. O código-fonte é a única entrada, então tudo que é decidido no deploy permanece invisível: política de CORS, modo de depuração deixado ativo, TLS fraco, headers de segurança ausentes, cache poisoning e autorização em runtime entre serviços. Falhas de autorização no nível do objeto, em especial, exigem requisições autenticadas de duas identidades reais para confirmação — algo que a simples leitura do código não oferece.

A profundidade de cobertura entre linguagens também parece desigual. Um relato prático sobre o serviço hospedado aponta cobertura mais forte em Python, JavaScript, TypeScript, Go e Java, com Ruby, PHP e Kotlin atrás. Testei apenas JavaScript, então trate isso como informação de segunda mão.

Vale a pena usar?

Instale hoje se você quer o modelo de ameaças. Esse foi o único artefato que recebi em todas as execuções: um documento de 1.605 palavras que mapeia fronteiras de confiança, lista cenários de atacante e define o que crítico, alto, médio e baixo significam para aquele serviço específico. Ele também é uma entrada útil para as demais ferramentas que você usa, já que --knowledge-base aceita sua própria documentação de arquitetura e o modelo gerado pode ser editado.

Espere se você precisa de gasto previsível ou de uma lista efetiva de achados. Em cinco configurações, não obtive nenhum dos dois, pagando entre US$ 1,46 e US$ 8,54 por execução em um repositório que se lê em dez segundos. As saídas documentadas nas etapas posteriores do pipeline — findings.json, coverage.json e report.md — nunca foram geradas nos meus testes. A questão em aberto, que estes testes não respondem, é se uma conta ChatGPT Business com acesso habilitado se comporta de outra forma.

Nenhuma das duas alavancas óbvias de custo funcionou aqui: limitar ao diff e reduzir o esforço de raciocínio bateram na mesma barreira. O que alterou a conta foi a tarifa do modelo, pois a estimativa é calculada com base nos tokens e no preço de tabela; logo, um endpoint pela metade do preço também corta pela metade o custo da mesma execução. Faça orçamento com base em execuções medidas, não no tamanho do repositório, e defina o teto abaixo do seu limite real pelo tamanho de uma rodada de workers: meu maior estouro foi de 46% do limite.

Perguntas frequentes

O Codex Security CLI é gratuito?

O CLI e o SDK usam Apache-2.0 e não custam nada para instalar. As varreduras não são gratuitas. Elas consomem tokens do GPT-5.6 Sol na credencial usada para autenticação, e o CLI exibe uma estimativa em execução pelos preços de tabela da OpenAI.

Preciso de um plano ChatGPT Business ou Enterprise?

Para a integração hospedada com GitHub, sim: esse caminho é limitado a Pro, Enterprise, Business e Edu. O CLI aceita uma OPENAI_API_KEY comum, mas a documentação alerta que varreduras do repositório inteiro ainda podem exigir Trusted Access for Cyber, algo que nenhum plano concede automaticamente.

Ele roda em CI?

Sim. Defina OPENAI_API_KEY, use --fail-on-severity para transformar achados em um código de saída diferente de zero e aponte CODEX_SECURITY_STATE_DIR para um caminho gravável fora do repositório. Por padrão, as varreduras apenas geram relatórios.

Funciona com um endpoint de terceiros compatível com OpenAI?

Funciona, desde que o endpoint implemente a Responses API. É necessário sobrescrever a configuração do provedor Codex com flags --codex, porque apenas definir OPENAI_API_KEY faz a autenticação falhar.

Qual é a diferença entre o CLI e o plugin Codex Security?

O mecanismo de varredura é o mesmo; o ponto de entrada muda. O plugin roda na infraestrutura da OpenAI contra um repositório GitHub conectado. O CLI roda na sua máquina contra um caminho local, guarda o histórico das varreduras em um diretório de estado local e acrescenta varreduras limitadas a diff, hook de pre-commit, exportação SARIF e registro MCP.

Leia também: Guia de preços do GPT-5.6 · Modo automático do Codex