0.1.8 Beta2: Inventory Codex CLI 0.146 tool types and representative Responses lifecycles

[NOirBRight]

Parent

#318 (part of #248)

Outcome

Capture the minimum exact Codex CLI 0.146 runtime and Responses wire evidence needed to define the Beta2 tool compatibility rules. This is a bounded protocol inventory, not a release-forensics platform and not a model qualification gate.

Scope

• Read the installed CLI planner/runtime tool plan before sampling.
• Inventory declaration families by structure: plain function, custom/freeform, namespace, client-executed tool discovery, selected-Provider hosted tools, and unknown future kinds.
• Capture representative request, response, streaming, call/result, and history shapes needed to distinguish native compatibility from a reversible encoding mismatch.
• Include the relevant added/delta/done ordering, IDs, terminal events, and error shapes.
• Bind the retained fixtures to the exact CLI version and source/candidate revision and sanitize all user content.

The inventory is structural. It does not need a permanent list of every tool name, every plugin combination, or every Provider/model.

Acceptance criteria

• The authoritative retained inventory is from Codex CLI 0.146; the legacy 0.144 artifact is reference-only.
• Every declaration kind observed in the selected runtime plan has an explicit structural record.
• Representative native declarations and each incompatible structural family needed by 0.1.8 Beta2: Define tool-type compatibility rules for custom Responses endpoints #65 have a complete declaration/call/result/history/SSE example.
• Hosted declarations are identified as selected-Provider capabilities; no second Provider is contacted to manufacture evidence.
• The capture reports mutation or loss inside the sampled lifecycle and contains no silent disappearance.
• Fixtures and summaries are bounded, sanitized, reproducible, and sufficient for 0.1.8 Beta2: Define tool-type compatibility rules for custom Responses endpoints #65 to assign one of four compatibility dispositions.
• The issue may close once the compatibility table can be decided; live success for every hosted, plugin, App, or unknown tool is not required.

Explicitly out of scope

• GLM/K2.7 capability qualification or production routing policy.
• Exhaustive feature/mode/MCP/App/plugin permutations.
• Dual-sidecar forensic provenance, HMAC/tamper platform work, and complete release-evidence infrastructure.
• Full cross-platform descendant/process-tree proof beyond the bounded capture needed here.
• Code Mode, tool_search, or Collaboration V2 end-to-end qualification.
• Any cross-Provider tool proxy.

Draft PR #349

PR #349 is larger than this reduced issue. Only a minimal, reviewed slice that directly satisfies the acceptance criteria above may be retained for #62. Remaining reusable hardening is tracked by #352 and does not block Beta2 or Beta3.

[NOirBRight]

Current-side diagnostic update (sanitized):

• Codex Desktop registered 15 codex_app tools: 3 Direct and 12 Deferred.
• The 3 Direct tools are callable; all 11 sidebar-visible task tools are Deferred and absent from the model-visible surface. automation_update is the twelfth Deferred tool.
• Codex source at 9e552e9d15ba52bed7077d5357f3e18e330f8f38 enables tool_search only when model supports_search_tool and provider namespace_tools are both true.
• Gateway routing is official Responses-to-Responses transparent passthrough; current evidence does not support Gateway-side tool filtering.
• The applications were cold-started for the initial binding, but the current custom-provider config and complete CodexHub catalog were written after the Codex app-server had constructed ThreadManager. The startup catalog omitted supports_search_tool; the post-switch catalog contains true. No model-manager rebuild occurred, so Deferred tools remained unavailable.
• Repro: powershell scripts/check-codex-thread-tool-surface.ps1 exits 1 deterministically and reports STALE_STATIC_MODEL_MANAGER_AFTER_CONFIG_REWRITE plus the 11 missing visible-task tools.

Remaining control: restart Codex Desktop only after the current CodexHub config/catalog is fully written, resume or create a task on the unchanged CodexHub node, then rerun the same trace. This distinguishes recovery after the relevant app-server cold start from provider switching.