Skip to content

v0.7.11 — Codex CLI as a first-class harness (#549)

Choose a tag to compare

@raullenchai raullenchai released this 16 Jun 00:34

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/responses protocol 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 in input[] every turn (openai/codex#3841), so no response-store layer is needed on the server.
  • Codex CLI harness profile (#590) — new codex.yaml profile, rapid-mlx agents codex --setup writes a working ~/.codex/config.toml, README + new docs/guides/codex-cli.md, regression tests that render the template through tomllib and 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 the async for loop, so any setup-time exception emits a clean response.failed to Codex instead of an EOF mid-stream (Codex treats stream-close-without-response.completed as 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-shot

If 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/responses route (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.