Codex é mais útil para publicação quando o pedido não termina em “gere os arquivos”. O fluxo bom termina com uma URL, uma Version publicada e uma checagem explícita de que o site abriu como esperado.

Com o MCP do Site no Ar conectado, você pode pedir ao Codex para criar a página, rodar a build, selecionar a pasta correta, publicar e devolver a URL final. O ponto importante é manter o contrato claro: o agente opera o deploy, mas você ainda define escopo, slug, pasta e verificação.

Se ainda não conectou o servidor, comece pela documentação de Codex ou pela página geral de configuração. Este guia assume que você está em um projeto local e quer sair dele com um site no ar.

Quando esse fluxo faz sentido

Use Codex para publicar automaticamente quando o resultado final pode virar arquivos estáticos:

  • landing pages;
  • páginas de captura;
  • sites institucionais simples;
  • protótipos de produto;
  • páginas de campanha;
  • documentação ou demos exportadas para HTML, CSS e JavaScript.

O fluxo usa o workspace git do próprio Site. O que não deve acontecer é o agente adivinhar o destino: ele precisa chamar get_context, confirmar o Site e trabalhar sob public/.

Se o projeto depende de banco de dados, backend próprio, jobs, secrets de runtime ou rotas server-side que não viram arquivos estáticos, trate isso como outro tipo de deploy. O Site no Ar publica arquivos; ele não substitui uma plataforma de backend.

Prepare o Codex antes do pedido

O setup mínimo tem duas partes: cliente pronto e MCP configurado.

Terminal window
codex mcp add sitenoar --url https://mcp.sitenoar.dev
codex mcp login sitenoar

O segundo comando abre o Site no Ar no navegador. Conclua a autorização e depois confira se a configuração ficou disponível:

Terminal window
codex mcp list
codex mcp get sitenoar --json

O Codex atual gerencia servidores MCP pelo comando codex mcp, e servidores HTTP remotos usam --url. Se o login expirar, rode codex mcp login sitenoar novamente.

Depois da conexão, deixe claro onde o Site mantém os arquivos:

Antes de publicar, chame get_context e consulte os arquivos atuais.
Mantenha o conteúdo público sob public/.
Se public/index.html não existir, pare e explique o que falta.

Essa instrução evita o erro mais comum: editar o Site errado ou salvar conteúdo fora do diretório publicado.

Peça a criação já pensando no deploy

Um prompt solto costuma gerar uma página bonita, mas não necessariamente publicável. Use um pedido que una produto, arquivo e entrega:

Crie uma landing page estática para validar uma consultoria de automação de atendimento.


Requisitos:
- Use HTML, CSS e JavaScript simples.
- A home precisa estar em public/index.html.
- Não use dependências externas obrigatórias para carregar a página.
- Coloque imagens e scripts em caminhos relativos.
- Ao final, publique pelo Site no Ar com slug automacao-atendimento-demo.


Antes de publicar:
- revise se public/index.html existe;
- abra a página localmente se possível;
- confirme se todos os assets referenciados existem sob public/.

Se o projeto já existe, troque a parte de criação por uma tarefa de ajuste:

Chame get_context, revise a landing page atual e corrija problemas óbvios de layout.
Diretório publicado: public/
Slug: campanha-julho
Use o MCP do Site no Ar para publicar e retorne a URL final.

O Codex pode editar arquivos, rodar comandos e chamar ferramentas. O pedido deve transformar isso em uma sequência controlada, não em uma tentativa aberta de “colocar no ar”.

Checklist antes de publicar

Antes do publish, peça evidência. O checklist pode ser curto:

Item O que confirmar
Site O Site ID foi confirmado com get_context
Pasta As alterações estão sob public/
Home Existe public/index.html
Assets Os caminhos referenciados existem em public/
Rotas Outros arquivos .html são intencionais
Slug O endereço desejado foi informado

O contrato de publicação é baseado em arquivos: public/index.html vira /, outros HTMLs viram rotas e assets preservam seus caminhos. Se uma imagem fica fora de public/, a URL final pode abrir quebrada mesmo que o deploy tenha passado.

O pedido de publicação

Quando a página estiver pronta, use uma instrução objetiva:

Chame get_context, atualize os arquivos deste Site em public/ e publique com deploy.
Slug: campanha-julho
Use public/index.html como página inicial.
Se o slug estiver ocupado, aceite uma sugestão da API e me informe a troca.
Depois abra ou verifique a URL publicada e me retorne:
- URL final;
- slug usado;
- arquivos alterados;
- status final do deploy;
- qualquer limitação encontrada.

Esse formato dá ao agente autorização para lidar com variações normais, como slug ocupado, sem esconder a decisão. Se a conta não tiver acesso de publicação ou o login expirar, o Codex deve parar e apontar a próxima ação.

Como revisar a resposta do Codex

Uma boa resposta final não diz apenas “feito”. Ela deve trazer algo parecido com:

  • URL publicada;
  • qual Site foi alterado;
  • quais arquivos principais foram alterados;
  • se o deploy terminou com sucesso;
  • se a página final foi verificada;
  • se houve mudança de slug.

Se faltar a URL, peça a verificação antes de compartilhar com cliente, time ou campanha. Se faltarem os arquivos alterados, peça para o Codex listá-los. Se ele publicou a versão errada, corrija public/ e republique no mesmo Site.

Erros comuns

Sintoma Correção
O site abre sem CSS confirme caminhos e assets sob public/
URL mostra página antiga peça para republicar o mesmo Site e verificar o deploy mais recente
index.html não encontrado crie ou mova a home para public/index.html
Login expirou rode codex mcp login sitenoar e tente de novo
Slug ocupado aceite uma sugestão ou escolha um slug mais específico

O objetivo é transformar publicação em parte natural do trabalho do Codex: criar, revisar, buildar, publicar e verificar. Para um roteiro mais profundo sobre o protocolo entre agente e hosting, leia também Codex + MCP: o fluxo completo de criação e publicação de sites. Para comparar com outros clientes, veja o guia de Gemini CLI + Site no Ar e o fluxo de Claude Code via MCP.