Vou ler a receita codex-runtime-single-file.yaml inteira para te dar o passo a passo real de uso.
Pronto — criei src/main/resources/support/codex-runtime.sh para conversar com a receita da cigna como se fosse o Codex CLI. Aqui está o guia completo de uso:
Como a receita funciona como "Codex"
A codex-runtime-single-file.yaml reproduz o runtime do Codex dentro do engine: cada execução da receita = um turno do Codex, e a conversa continua entre execuções porque a memória CHAT tem persist: true — basta reusar o mesmo sessionUUID. O agente ROOT roda com os agents nativos (Azure: gpt-5.2-codex, gpt-5.1 ou gpt-4.1, escolhido no input clientLLM) e tem o arsenal do Codex: read_file, write_file, apply_patch, shell_command, network_request, delegate_explorer (sub-agente de exploração), run_review (sub-agente revisor), goals, compactação de contexto e memória — tudo com um agente GUARDIAN aprovando operações arriscadas antes de executar.
Passo a passo
1. Suba o engine (precisa do .env com AZURE_OPENAI_API_KEY, já que todos os agents são Azure):
./mvnw spring-boot:run

2. (Recomendado) Clone o Codex CLI da OpenAI — é disso que o Maikon falou:
git clone https://github.com/openai/codex ~/ws/tools/codex

O input codexRoot deve apontar para a raiz do clone (a pasta que contém codex-rs) — a receita lê 28+ arquivos .md de lá: as base instructions reais do Codex, os templates de approval policy e sandbox mode, a rubric de review, a policy do guardian, etc. Sem o clone funciona também: com loadCodexPromptFiles=false ela usa prompts fallback embutidos, só menos fiéis ao original.
3. Prepare o workspace alvo. A receita imita o Codex também aqui: ela lê o AGENTS.md do workspaceRoot como project instructions e carrega .codex/skills/**/SKILL.md como skills — é por isso que o branch cigna adicionou .codex/skills/ neste repo (skills de authoring de receitas, Docusaurus e Storybook). Se você apontar workspaceRoot para o próprio brsp-synthesis-engine, o agente já nasce sabendo escrever receitas.
4. Rode. Duas formas:
Playground UI (http://localhost:8099): selecione a receita, preencha workspaceRoot, userPrompt, codexRoot — os demais inputs são dropdowns com defaults sensatos (taskKind=normal, sandboxMode=workspace-write, approvalPolicy=on-request, collaborationMode, personality). Atenção: os defaults de caminho são Windows (C:/...) — troque pelos seus.
Ou pela linha de comando com o script:
# primeiro turno — devolve o sessionUUID
./src/main/resources/support/codex-runtime.sh \
  -w /caminho/do/projeto-alvo \
  -c ~/ws/tools/codex \
  "Analise o módulo X e corrija o bug Y"

# turnos seguintes — mesma conversa
./src/main/resources/support/codex-runtime.sh \
  -w /caminho/do/projeto-alvo -c ~/ws/tools/codex \
  -s <sessionUUID-devolvido> \
  "Agora escreva testes para isso"

A saída é {"sessionUUID", "status", "response", "review", "guardian"} — a resposta vem do output RESPONSE da receita (codex.lastResponse). Sem -c, o script já seta loadCodexPromptFiles=false sozinho.
5. Modos especiais via -k (input taskKind), espelhando os subcomandos do Codex: review (roda o REVIEWER com a rubric oficial e devolve JSON de findings), compact (compacta a conversa da sessão), init (gera instruções de repositório, como codex init), ask, goal, memory_write/memory_consolidate, realtime e guardian.
Duas observações honestas: o cabeçalho da própria receita documenta os limites (sem paralelismo real de sub-agentes, sem parser completo de apply_patch multi-hunk, maxTurns ainda descritivo — o mesmo gap sem cap de iterações que identifiquei na minha); e ela persiste estado entre turnos em .session/codex-runtime/world-state.json na pasta da sessão, calculando delta de mundo a cada turno — então evite apagar a pasta da sessão se quiser continuidade.
