codex ACP client sends initialize without protocolVersion — incompatible with all codex-acp versions

[Ji-Sir]

Summary

The aioncore codex ACP client cannot complete the ACP handshake with any released @zed-industries/codex-acp version, so the built-in "Codex CLI" agent always fails with "The upstream Agent failed while handling the request".

Evidence (aioncore 0.1.70 & 0.1.71, macOS arm64)

aioncore spawns codex-acp (builtin registry pins bun x --bun @zed-industries/codex-acp@0.14.0) and sends an initialize request without the protocolVersion field. Every codex-acp version rejects it:

{"jsonrpc":"2.0","error":{"code":-32602,"message":"Invalid params","data":{"error":"missing field `protocolVersion` at line 1 column 125"},"id":1}}

Tested matrix (all fail the same way at initialize):

codex-acp	result
0.9.5	-32602 missing protocolVersion
0.14.0	-32602 missing protocolVersion
0.15.0	-32602 missing protocolVersion
0.16.0	-32602 missing protocolVersion (+ thread/start method not found)

Log excerpt (aioncore log, session handshake):

codex <- frame {"jsonrpc":"2.0","error":{"code":-32602,...missing field `protocolVersion`...,"id":1}}
codex <- frame {"jsonrpc":"2.0","error":{"code":-32601,"message":"Method not found","data":"thread/start"},"id":2}
codex <- frame {"jsonrpc":"2.0","error":{"code":-32601,"message":"Method not found","data":"model/list"},"id":3}
Agent send_message failed ... "The upstream Agent failed while handling the request"

The ACP spec requires initialize params to include protocolVersion (integer). The client sends only clientInfo + capabilities.

Repro

1. AionUi desktop (backend aioncore 0.1.70 or 0.1.71), enable the builtin Codex CLI agent, ensure codex login (ChatGPT account) is done.
2. New conversation with backend=codex, send any message.
3. Turn fails: "The upstream Agent failed while handling the request".

Expected

initialize should include protocolVersion (e.g. 1), and the client should handle both the old session/new and new thread/start generations of codex-acp, or pin a codex-acp version it actually interoperates with.

Separately (harder blocker for codex-acp 0.14 specifically): 0.14's embedded codex ignores the CODEX_HOME env var and always reads the real user ~/.codex; if the user's ~/.codex/config.toml contains keys newer CLI versions write (e.g. service_tier = "default" from the ChatGPT desktop app), codex-acp 0.14 fails at startup with unknown variant 'default'. codex-acp >= 0.15 honors CODEX_HOME. Agents should pass CODEX_HOME (already respected by newer codex-acp) to isolate config, or document the requirement.

[Ji-Sir]

Additional finding while integrating codex-acp behind a protocol shim (we inject the missing protocolVersion into initialize, which gets the handshake + session/new working against codex-acp 0.15/0.16):

codex-acp's vendored codex engine can no longer talk to the ChatGPT backend. With codex-acp 0.15 (engine rust-v0.133.0) and 0.16 (engine rust-v0.137.0), after a successful handshake and session/new, sending a session/prompt produces no model events for 5+ minutes — the turn just hangs (only an available_commands_update arrives). The current codex CLI 0.142 with the same ChatGPT account, same CODEX_HOME, and same model (gpt-5.5) responds instantly via codex exec.

Also noteworthy for anyone pinning codex-acp: engines ≤0.137 fail to decode the model catalog the ChatGPT backend now serves (unknown variant max, expected ... xhigh``), so models refresh loops errors unless a local `model_catalog_json` is supplied.

Suggestion: when fixing the ACP client initialize, also bump the bundled codex-acp to a release whose vendored engine is new enough for the current ChatGPT backend (or build codex-acp against a recent codex tag).