Skip to content

🐛 xmd plan resolves agents through ACPX's stock registry instead of the embedded adapters #672

Closed

Description

@taras

Report

xmd plan in 0.10.0 fails with both providers, on a machine where codex 0.150.1 and claude 2.1.251 are installed and authenticated:

$ xmd plan "ask me for my name and then write it out"
agent "codex" is unavailable [ACP_BACKEND_UNAVAILABLE]: embedded ACP runtime probe failed (agent=codex; command=npx -y @agentclientprotocol/codex-acp@^0.0.44; cwd=/Users/…/.xmd/plan/sessions/e7cb…; Codex process has exited with code 1)

$ xmd plan "ask me for my name and then write it out" --default-agent=claude
this session still awaits first-turn materialization: the turn ended before the backend accepted it

Cause

xmd plan never installs the embedded ACP adapters, so its provider resolves agents through ACPX's stock registry.

The workflow path overlays them: packages/cli/src/workflow-agent.ts:427 passes agentRegistry: overlaidAdapterRegistry(adapters). The plan path does not: authorshipCeiling() in packages/cli/src/authorship-profile.ts builds the provider from hostAcpDependencies() and profile.acp, neither of which sets agentRegistry, so packages/acp/src/provider.ts falls back to createAgentRegistry() — ACPX's own table, pinned at codex: "^0.0.44" and claude: "^0.37.0" (packages/acp/vendor/acpx/generated/live-checkpoint-*.js, ACP_ADAPTER_PACKAGE_RANGES).

That produces both symptoms:

  • codex — the probe spawns [email protected], which ignores the installed codex and runs its own bundled @openai/[email protected] through node bin/codex.js app-server. Reproduced outside xmd: that adapter answers initialize with Codex process has exited with code 1; the underlying error is spawn …/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/codex/codex ENOENT (the platform binary is absent from the npx cache). The same adapter initializes correctly with CODEX_PATH=$(which codex), so the installed codex is healthy — the failure belongs to the stale pin.
  • claude — the probe passes, the turn runs, but a stock claude-agent-acp never publishes the executablemd.session-materialization/v1 signal (only the patched 0.70.0 in packages/acp/vendor/adapters does, per its PROVENANCE.md), so finalizeRuntimeTurn rejects with the materialization refusal (packages/acp/vendor/acpx/generated/runtime.js, "the turn ended before the backend accepted it").

installRunAgentStack (packages/cli/src/agent-stack.ts, used by xmd run in cli.ts) is built the same way as the plan path and is likely affected too; not reproduced.

Acceptance

  • xmd plan "<request>" and xmd plan … --default-agent=claude complete a first turn against the embedded adapters in a release build, with no npx resolution of a stock adapter.
  • The plan provider resolves codex and claude through the same overlaid registry the workflow path uses, and an embedded provider never falls through to ACPX's pins.
  • installRunAgentStack is checked for the same gap and fixed with it if present.
  • A test pins the registry the plan path hands its provider, so a stock pin cannot return silently.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions