v0.7.11 — Codex CLI as a first-class harness (#549)
What's new in v0.7.11
The headline shipment is Codex CLI as a first-class harness: rapid-mlx now implements the OpenAI Responses API (POST /v1/responses) as a stateless shim, and ships a rapid-mlx agents codex --setup profile that writes a working ~/.codex/config.toml for you.
Codex CLI integration (closes #549)
POST /v1/responsesprotocol shim (#588) — Pydantic models for the polymorphic Responses request/response shape, an adapter that translates Responses-API ⇄ Chat Completions, and a route that emits the 7 SSE event types Codex CLI parses (response.created,response.output_item.added,response.output_text.delta,response.function_call_arguments.delta,response.output_item.done,response.completed,response.failed). Stateless by design — Codex re-sends the full conversation ininput[]every turn (openai/codex#3841), so no response-store layer is needed on the server.- Codex CLI harness profile (#590) — new
codex.yamlprofile,rapid-mlx agents codex --setupwrites a working~/.codex/config.toml, README + newdocs/guides/codex-cli.md, regression tests that render the template throughtomlliband verify it has the keys Codex's loader actually reads. Recommended models:qwen3.6-35b-4bit/qwen3-coder-30b-4bit/qwen3.5-9b-4bit. - Robustness fix — setup work in the SSE stream path is now wrapped in the same
try:that handles theasync forloop, so any setup-time exception emits a cleanresponse.failedto Codex instead of an EOF mid-stream (Codex treats stream-close-without-response.completedas a hard failure).
Try it
rapid-mlx upgrade # or: pip install -U rapid-mlx==0.7.11
rapid-mlx serve qwen3.6-35b-4bit --port 8000
rapid-mlx agents codex --setup
codex # interactive
codex exec "explain this repo" # one-shotIf you start the server with --api-key, see docs/guides/codex-cli.md for the env_key = "RAPID_MLX_API_KEY" snippet (Codex CLI's --strict-config rejects inline api_key = "..." literals).
Follow-ups
- #591 — [HIGH] + [P2] hardening for the
/v1/responsesroute (tool-call channel routing, text-parser path, status-on-truncation semantics). Latent today on Codex CLI's actual request shape; tracked for completeness.
Thanks
@shinrali for the detailed bug report and for cc-ing the SSE event list — saved a few hours of guessing what Codex actually parses.
Install: brew upgrade raullenchai/rapid-mlx/rapid-mlx or pip install -U rapid-mlx==0.7.11 (or just rapid-mlx upgrade).
Post-tag validation
v0.7.11 was published via the auto-release fast path; the full M3 gauntlet (make release-check-m3) was run retroactively after publication and all gates G1–G9 + the new G7b (agent-harness layer: codex / opencode / hermes) green on qwen3.5-4b-4bit. One pre-existing test-runner bug (vllm_mlx/agents/testing.py:617 reading the wrong SSE field name) was surfaced and is fixed in #593 — it never affected any published runtime path. v0.7.11 is not being yanked.
Going forward the harness layer is a hard release gate (see #593 for the SOP change), so the next bump won't have this validation hole.