feat: add codex executor for OpenAI GPT/Codex via bedrock-mantle

[sfreudenthaler]

Adds a codex executor so openai.* model IDs (openai.gpt-5.5, openai.gpt-5.4) route to OpenAI's GPT/Codex models on AWS. Part of dotCMS/Infrastructure-as-code#7836.

These models are not on bedrock-runtime — there is no InvokeModel/Converse. They are served only by the separate bedrock-mantle endpoint (OpenAI Responses API, https://bedrock-mantle.{region}.api.aws/v1/responses), so the existing generic Converse executor can't reach them.

Consumers change nothing but model_id — the orchestrator routes, the executor handles region/auth/streaming. Same "magic" as the provider-family pattern.

Auth: OpenAI SDK + short-term Bedrock bearer token minted from the OIDC session (no long-lived secret, ≤1h lifetime, nothing to clean up). See the decision + token-lifecycle notes on #7836.

What changed

• codex-executor.yml (new):
  • Calls mantle with the OpenAI SDK authenticated by a short-term Bedrock bearer token minted in-process from the OIDC-assumed-role session (aws-bedrock-token-generator). The SDK can't consume SigV4, but a short-term key keeps the OIDC-only posture: derived from the STS session, no long-lived secret, not a stored resource (nothing to clean up), expires with the role session (≤1h), never written to env/disk/logs.
  • Streams SSE and accumulates response.output_text.delta. Streaming is mandatory — GPT-5.x reasons before emitting, so a non-streaming call buffers and looks like a 60–100s hang.
  • Remaps the orchestrator's us-east-1 default → us-east-2, where GPT-5.5/5.4 are served. The mantle endpoint exists in us-east-1, but the models are not there yet — verified live via the Models API (us-east-1 lists gpt-oss but no gpt-5*). GPT-5.4 also accepts explicit us-west-2.
  • Sends store: false for zero data retention — the Responses API otherwise defaults store: true (retains input+output 30 days in-region for previous_response_id chaining), which single-shot review doesn't need.
  • Reuses the /tmp sticky-comment helper + sticky_namespace. Adds reasoning_effort (default medium). max_output_tokens caps only the visible answer, not reasoning tokens.
  • Dependencies (openai + aws-bedrock-token-generator) are declared as PEP 723 inline script metadata and run via uv run (with astral-sh/setup-uv, cache enabled) — ephemeral, cached env; no system pip install.
• claude-orchestrator.yml: anchored ^([a-z]+\.)?openai\. route → openai-mantle → codex-mantle job, checked before the generic fallback. Optional reasoning_effort pass-through.
• CLAUDE.md / ARCHITECTURE.md: routing tables, executor docs, mermaid diagram.

Validation

• actionlint (rhysd/actionlint:1.7.7) → exit 0
• YAML parses (orchestrator + new executor)
• Embedded Python compiles (py_compile)
• Live-verified against the R&D account Models API: correct path is /v1 (not /openai/v1, which 404s), and GPT-5.5/5.4 are present in us-east-2 only. The raw SigV4-against-mantle primitive was proven in the auth spike (dotCMS/Infrastructure-as-code#7836). Pending: a full end-to-end executor run on a real PR (validates the exact Responses-API SSE event shapes + the narrow IAM grant) — see #7836 sequencing. Recommend piloting on dotCMS/core.

Ships with

dotCMS/Infrastructure-as-code IAM PR #7842 (bedrock-mantle:CreateInference + CallWithBearerToken scoped to SHORT_TERM) — merge/apply as a pair so IAM is never open without an execution path.

🤖 Generated with Claude Code

[sfreudenthaler]

sadly all the inline scripts have to stay because of the way uses: and relative paths work in github actions when using reusable workflows. the tl;dr is that they resolve to the callers local repo / checkout not the ai-workflows one. so those other files outside the action wouldn't be reachable without some ugly kludges.

Created a new issue in #32 that would explore moving to a full blown github app approach