feat(daemon): use AgentConnect Codex ACP build

[zfy0701]

Summary

• Add an AgentConnect-managed runtime layer that follows the public @agentconnect.md/codex-acp@agentconnect release channel without pinning a concrete version.
• Keep precedence explicit: public registry < AgentConnect-managed build < operator runtimes configuration.
• Carry the full per-prompt usage and auto-review approval fixes from upstream PRs #353 and #350.
• Keep bearer-bearing remote MCP access fail-closed for this build until it passes the non-vacuous tool/retry harness.

Release provenance

• Fork integration and upstream sync: agentconnect-md/codex-acp#1
• Staged scoped-package metadata fix: agentconnect-md/codex-acp#2
• Published package: @agentconnect.md/codex-acp@1.1.8-agentconnect.1

The fork keeps the upstream source package metadata and documentation unchanged. Its release workflow stages the AgentConnect scope/version only in the publish job, advances the agentconnect dist-tag, and uses npm trusted publishing. The daemon reports the concrete version learned from the ACP probe.

Validation

• Fresh anonymous @agentconnect.md/codex-acp@agentconnect invocation resolves and reports @agentconnect.md/codex-acp 1.1.8-agentconnect.1.
• pnpm --filter @agentconnect.md/daemon typecheck
• Focused registry and remote-MCP policy tests: 34 passed.
• pnpm --filter @agentconnect.md/daemon build (including self-contained bundle assertion).
• Full daemon suite assertions: 150 files passed, 2 skipped; 2,594 tests passed, 7 skipped. The command then exited non-zero because the local runner exhausted file watchers (EMFILE, 1,059 teardown/unhandled watcher errors).
• Live remote-MCP harness connected to the scoped adapter descriptor, but two explicit probe turns produced zero tools/call requests. The exact managed launch is therefore recorded as not admitted; normal ACP sessions are unaffected.

Created by Codex . GPT-5.6 Sol

[agentconnect-md-test]

Overview: Adds a MANAGED_RUNTIME_CATALOG layer (runtimes/managed.ts) pinning codex-acp to @agentconnect.md/codex-acp@1.1.8-agentconnect.1, and wires it into resolveRuntimeCatalog between the public registry and operator runtimes config, matching the stated precedence.

Correctness

• Layering order in registry.ts (curated → registry → managed → user, each overwriting the prior) correctly implements "registry < managed-build < operator config."
• localCoversNeeded extension to skip the network registry fetch when MANAGED_RUNTIME_CATALOG covers all needed ids is safe: managed entries are applied unconditionally after the registry loop, so a stale/skipped registry fetch can't leak a wrong codex-acp definition through.
• isValidatedRemoteMcpRuntime already fails closed for any source other than 'curated'/'registry', so the new 'managed' source is correctly excluded without further code changes — the diff there is comment-only, which matches the PR's "keep fail-closed" claim. Confirmed via the new remote-mcp-runtimes.test.ts case.

Tests: New registry.test.ts case covers both the default-managed-build path and the operator-override path; remote-mcp-runtimes.test.ts covers the fail-closed managed case. Adequate for the change's scope.

Nits (non-blocking)

• The updated doc-comment list item in remote-mcp-runtimes.ts ("...and an AgentConnect-managed build without passing evidence are never admitted") reads slightly awkwardly grafted onto the existing sentence — could be split for clarity, but not blocking.

No correctness, security, or test-coverage issues found. LGTM.

_{sent by review-bot-fast (Claude Agent · sonnet) · open in session}

[agentconnect-md-test]

Approved for commit 9d04a25fbb992039730db3d880ce2f7968dcb331. I found no blocking correctness, security, or maintainability issues.

The managed catalog establishes the intended precedence (registry < managed < operator config), preserves the existing Codex installation/auth probe, and carries source metadata through runtime reporting. The bearer-bearing remote MCP path remains fail-closed because managed entries are excluded from the validated curated | registry launch sources, with a focused regression test documenting the current harness result.

Validation performed:

• daemon-focused registry and remote-MCP tests: 33 passed; live adapter tests skipped unless explicitly enabled
• daemon typecheck and changed-file lint: passed
• daemon build and self-contained bundle assertion: passed
• exact published package metadata verified as @agentconnect.md/codex-acp@1.1.8-agentconnect.1 with the codex-acp binary
• GitHub Build, Check, Unit Test, and both Integration test jobs: passed

Non-blocking warning: this managed Codex build intentionally does not receive the remote agentconnect-admin MCP descriptor until it passes the non-vacuous tool/retry harness; ordinary ACP sessions are unaffected.

_{sent by review-bot (Codex · gpt-5.6-sol) · open in session}

[agentconnect-md-test]

Re-reviewed this revision. The layering/precedence logic (registry → managed → user) and the fail-closed remote-MCP admission (managed source stays excluded, unchanged) are still correct and well tested.

Blocking: the pin regressed from an exact version to a floating dist-tag.

packages/daemon/src/runtimes/managed.ts now launches npx -y @agentconnect.md/codex-acp@agentconnect instead of the exact @agentconnect.md/codex-acp@1.1.8-agentconnect.1 used in the previous revision (and still claimed in the PR description). version is also now '' for this entry.

This matters specifically because of this file's own design premise: remote-mcp-runtimes.ts documents byte-exact, harness-validated launches and calls out that "a later release, a prerelease, an extra adapter flag... is a DIFFERENT, unvalidated launch configuration." The new "NOT admitted" entry you added there is evidence for codex-acp@1.1.8-agentconnect.1 specifically — but @agentconnect is a moving tag, so the actual binary npx resolves at any given install time can silently become a version that was never run through the §13 harness, with no corresponding PR/diff in this repo and no version string here to reveal the drift (you'd only learn the real version from the ACP-probed agentInfo.version after the fact). That's the exact failure mode the rest of this file is built to prevent for validated adapters, and it's now unguarded for the default/managed Codex path.

Every other source in this catalog pins exactly (registry entries carry whatever exact version string the registry doc declares; curated entries call bare, unversioned operator-installed binaries — a different, already-accepted trust boundary). The new managed source is the odd one out: it's an npm-hosted, code-execution runtime resolved at your own scope, but not pinned exactly.

Ask: either pin managed.ts back to the exact validated version (@agentconnect.md/codex-acp@1.1.8-agentconnect.1), or, if the @agentconnect channel tag is intentional (e.g. it's meant to only ever advance via an audited release+harness step on your side), say so explicitly in the code comment and update the PR description so it matches — right now the description and the diff disagree about what's actually pinned.

Everything else (catalog wiring, tests, comment updates) looks correct.

_{sent by review-bot-fast (Claude Agent · sonnet) · open in session}