Return each embedded ACP adapter to a qualifying upstream release #636

Purpose

Issue #622 embeds one npm tarball per provider under packages/acp/vendor/adapters and runs those instead of the adapter npx would resolve, because no published Codex or Claude release names the turn a Prompt completed.

Remove each snapshot when an exact upstream release carries its contract. The two are independent: one provider may return to a published release while the other's snapshot stays, and this issue closes only when both have.

This is not an adapter upgrade. Returning to a release and moving to a newer adapter are separate changes and are not done together.

Separate protocol integration from adapter retirement

The work is split into two tickets:

1. Support ACP v2 acceptance and completion in the runtime integration #1073 — ACP v2 runtime support. Integrate v2 acceptance, streaming and terminal outcomes into the existing runtime while preserving current Session/Prompt and REPL behavior.
2. This issue — released-adapter qualification and snapshot retirement. Compare each exact released adapter with the behavior our actual consumers require, then retire that provider's snapshot only after its applicable gates pass.

Completing #1073 does not establish an adapter's completed-prompt checkpoint, native identity or history behavior, and does not close this issue. If a candidate requires v2, its qualification uses the completed v2 integration; an independently qualifying provider is not blocked on unrelated provider work.

Continue evaluating supported released behavioral equivalents within this issue. A missing old custom field alone is not a reason to reject an equivalent public path. A new protocol integration or contract redesign belongs outside this issue and is not added by an unresolved source finding.

Exit gate, per provider

A candidate release replaces that provider's snapshot only when all of these pass on one exact revision:

• a normally completed prompt's response carries the contract above, and the value is byte-for-byte the identity the provider surface emitted;
• interleaved turns each carry their own identity, so nothing session-global is being read;
• cancelled, failed, refused, malformed, ambiguous and metadata-free completions each carry none, and nothing reconstructs one;
• the released version is selected exactly, never through a moving range;
• Tier AD, Tier AM and the Retain provider checkpoint tokens for workflow Agent Prompts #622 T1 evidence pass against the released adapter with no alternative token source added; and
• the Deno cached/no-node-modules build and release compile, the npm package, the JSR dry run and the repository clean/composability verifier pass.

Removal, per provider

• drop that provider's tarball and LICENSE from packages/acp/vendor/adapters/<provider>/;
• remove its entry from MANIFEST.json and regenerate generated/snapshots.ts;
• remove its REVIEWED entry and any provider-specific case from scripts/tests/adapter-vendor.test.ts;
• restore that provider to the published command in the registry the workflow Agent profile installs, keeping the registry closed to the providers this host serves; and
• update packages/acp/vendor/adapters/PROVENANCE.md.

When the last snapshot goes, remove packages/acp/src/adapter-snapshots.ts, scripts/build-adapter-snapshots.ts, Tier AD and Tier AM, and the adapters seam on the workflow Agent profile.

Not this issue

• Remove the vendored ACPX checkpoint-metadata patch after a released runtime carries response _meta #629 owns the vendored ACPX checkpointMeta patch, and Remove the vendored ACPX transient-environment patch after a released scoped seam passes continuity #566 owns the ACPX agentProcessEnv patch. Those patch a runtime this repository imports; this issue is about whole packages it executes.
• The retention contract. What a checkpoint is, and what a run does with one, is specs/workflow-workspace-spec.md §8.6 and does not change when a snapshot is removed.

Context

• packages/acp/vendor/adapters/PROVENANCE.md
• packages/acp/src/adapter-snapshots.ts
• Tier AD: scripts/tests/adapter-vendor.test.ts
• Tier AM: packages/acp/tests/adapter-materialization.test.ts

Current contracts and release assessment (2026-10-28)

The embedded snapshots now serve more than the original checkpoint fields:

Retirement preserves all applicable contracts, including refusal before acceptance and exact native identity; successful protocol initialization, echoed IDs, transport writes and ordinary output do not replace those facts. See packages/acp/vendor/adapters/PROVENANCE.md and its manifest for the separately recorded contracts. Providers still retire independently.

Latest inspected releases are Claude ACP 0.99.0 and Codex ACP 2.3.0. Claude 0.99.0 adds thinking-display configuration, embedded prompt blobs, MCP startup-failure reporting, Agent SDK 0.3.312, and permission/configuration fixes. Since the pinned snapshot, 0.71.0 also added message-specific forks, and recent releases add experimental ACP v2 and richer background/subagent handling. Codex 2.3.0 adds ACP v2, append-mode system prompts and session/subagent improvements.

The Claude checkpoint proposal #1047 was closed without merging on October 26, with a maintainer pointing to #1046. Message-specific forking is useful upstream functionality, but it does not itself report the exact completed prompt's assistant UUID on its response. The inspected 0.99.0 adapter contains neither that response field nor the current XMD acceptance marker. The Codex checkpoint proposal #438 remains open/unmerged; the inspected 2.3.0 adapter likewise lacks the current XMD response-checkpoint and acceptance contracts.

These are source findings, not real-provider tests or proof that no alternative supported integration can be designed. Neither release is established as a drop-in snapshot replacement. Keep removal conditional until the existing contracts pass against an exact released candidate or an explicitly accepted equivalent integration. Do not remove either snapshot simply for a newer SDK, ACP v2 support or an upstream PR closure. No recurring paid per-release certification is introduced; #891's compatibility policy remains applicable.

#566 and #629 have concrete released ACPX candidates for two independent runtime patch retirements. Their progress does not make this adapter-removal gate ready.

Maintainer-guided qualification of the released fork interface

The maintainer's October 26 comment on #1047 says “covered in #1046.” PR #1046 merged on August 28 and shipped in 0.71.0. It accepts a specific ACP message ID via _meta.jetbrains.air.fork = { version: 1, messageId }, resolves that ID to the SDK's message UUID within the adapter, and calls the SDK fork operation with upToMessageId. Missing fork points refuse rather than silently selecting the latest message. The released 0.99.0 implementation retains this interface.

Therefore evaluate this released behavioral alternative now; do not block qualification solely because the old custom response field is absent. The earlier release assessment establishes that the old patch was not merged verbatim, not that exact-point forking is unavailable upstream.

A bounded qualification determines whether XMD can obtain and retain an unambiguous provider-supplied point for each completed prompt, then reopen or fork the intended prefix through the released interface. Cover prompts producing several assistant messages, interleaved activity, cancellation/refusal and metadata-free cases, a later-advanced parent conversation, cold reopening, and unknown-point refusal. Use protocol-supplied identities; XMD must not match transcript text or assume that the last observed output chunk is an authoritative completed-turn checkpoint. Compare the full behavior, including the separate first-turn acceptance requirement, and explicitly reconcile any necessary contract amendment before production adoption.

This is actionable release qualification under this existing ticket, not a claim that all vendor-removal gates pass or a requirement to obtain the old wire spelling upstream. The separate native-history-loss report #1019 remains open with no maintainer comments at this check; the comment on #1047 is evidence about exact-message forking, not proof that native-to-ACP history continuity was repaired.