Repository navigation
0.1.8 Beta4: Reconcile the exact Codex Collaboration V2 runtime/wire contract #392
Description
Parent
Outcome
Reconcile the exact candidate-bound Codex Collaboration V1/V2 runtime and wire contract before Beta4 changes production adaptation.
The current closed #64 artifact is a structural source contract with capture_status=not_observed and describes V2 as a collaboration namespace. Codex 0.146 source instead exposes V1 through the multi_agent_v1 namespace and V2 as direct function tools. Beta4 must resolve that mismatch from the exact supported Codex CLI/Desktop runtime rather than implementing against an assumed namespace.
Required evidence
- Bind the report to the exact Codex CLI/Desktop version, source-equivalent revision, Beta4 candidate SHA, and isolated capture Home.
- Capture the model-visible V1 namespace and V2 direct-function declarations, exact parameter/output schemas, tool-choice forms, and the authoritative version-selection signal used before repair.
- Record the six V2 tools:
spawn_agent,send_message,followup_task,wait_agent,interrupt_agent, andlist_agents. - Distinguish model-wire
function_call/result/history items, anyagent_messageinput item, canonical task identity, and Codex App task events rather than treating them as one schema. - Record added/delta/done, terminal/error, replay, and same-Home restart/readback shapes without retaining prompts, credentials, content, or opaque task/call identities.
- Correct 0.1.8 Beta2: Define the Codex CLI 0.146 Collaboration V1/V2 schema boundary #64 artifacts, ADR-0002 wording, and focused contract tests where the exact evidence disproves the historical assumption.
Acceptance criteria
- V1 and V2 are decidable before any schema injection, semantic repair, state, or scheduler behavior.
- Shared direct function names such as
spawn_agentandwait_agentare not classified by name alone. -
task_name, canonical task path, continuation identity, call/item IDs, andagent_messageare assigned to their exact protocol layers. - Unknown, missing, conflicting, or mixed version signals fail closed.
- The resulting contract is sufficient for 0.1.8 Beta4: Implement runtime-derived Collaboration V2 direct-tool and lifecycle adaptation #282/0.1.8 Beta4: Verify the complete generic Collaboration V2 lifecycle #283 without inventing a V2 namespace or a Gateway-owned scheduler.
- Evidence is bounded, sanitized, candidate/runtime bound, and reproducibly validated.
- No production routing, model selection, fallback, history rewrite, or capability enablement is included.
Verification class
Strict: runtime protocol and release evidence contract.
Activity
NOirBRight commentedon Aug 10, 2026
Phase 1 blocker (frozen-runtime observation, 2026-08-10)
A fresh isolated
CODEX_HOMEprobe against a loopback custom Responses provider was run with the exact frozen CLI:codex-cli 0.146.1ae9d865f3d346a1a2a60c4e84775622d74e3e7ef53e0dede9c68b81eab306ccarust-v0.146.1/79b4f03d35962b005b007a015113b389307116652f2da02f3562065e286e9c510bb6b9b1812ed6c8The actual Responses request exposed one
type=namespace,name=collaborationdeclaration containing exactlyfollowup_task,interrupt_agent,list_agents,send_message,spawn_agent, andwait_agent. It did not expose six direct top-level function declarations. Requestclient_metadataalso did not carrymulti_agent_version; the request-visible discriminator was the complete namespace/schema shape.The source explains the apparent contradiction: each V2 handler begins as
ToolSpec::Function(multi_agents_spec.rs), butspec_plan.rs:825-883applies the configured namespace andspec_plan.rs:1056-1087rewrites it toToolSpec::Namespace. The frozen default istool_namespace = "collaboration"(config/mod.rs:252,1206), and custom providers report namespace support.This conflicts with #392's current premise and the Beta4 plan requirement that the CLI->Responses wire surface is six direct functions. Per the plan's fail-closed/stop condition, no production routing/adaptation change has been made. Beta4 must either (1) correct #392/#282 to the actual 0.146.1 namespace wire contract, while still distinguishing it from the client dispatch recipient namespace and App events, or (2) re-freeze on a runtime/configuration proven to emit direct functions and redo all runtime evidence.
NOirBRight commentedon Aug 10, 2026
Decision: keep the frozen Codex CLI/runtime
0.146.1and correct the Beta4 contract to the observed Responses wire shape. For Beta4, V2 is thecollaborationnamespace containing the six function children; the client dispatch recipient namespace, Responses namespace declaration/call shape, rollout metadata, model-wireagent_message, and Desktop App events remain separate protocol layers. Implementation resumes on this corrected basis.NOirBRight commentedon Aug 10, 2026
#392 is complete in PR #399, merged to
devat386802c848cc02d00cc879471462d4327b8b7c62.Evidence:
be10f62f44b22fa8c84510238250ae11fb3ecab4c3625259ecf8e7e00b639f74c79af154a45224eeae9d865f3d346a1a2a60c4e84775622d74e3e7ef53e0dede9c68b81eab306cca/ source79b4f03d35962b005b007a015113b38930711665fb5c760e14cf8fe86e12e49e8a3e7f237af06082d6b9fe1e411e463b7229c916/ source618b8e9111da9f57fe380b09d0f6516e3f343536docs/evidence/issue-392/collaboration-runtime-observations.jsondocs/evidence/issue-392/collaboration-runtime-contract.jsongit diff --check: passThe calibrated request-visible rule is V1
multi_agent_v1namespace vs V2collaborationnamespace with six children; direct/shared names alone do not classify, and mixed/malformed signals fail closed.