Problem
Kit's child client offers ACP v2, but a v1-only endpoint can reject that initialization instead of selecting v1. The current client handles successful responses selecting either version, but does not recover from this explicit version rejection. Subagent startup then fails with a generic protocol handshake error.
This was reported as a regression in Kit v0.2.0. The local executable used for the direct reproduction below reports kit 0.1.134; these are distinct observations, not a claim that the reproduction binary was the released v0.2.0 binary. Environment: macOS (Darwin arm64), built-in acp.kit child launched from Kit.
Reproduction
Launch a child without sending any model prompt:
kit acp --protocol-version 1 --credential-store memory --internal-no-mcp-config
Send this JSON-RPC line on stdin and leave stdin open:
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":2,"clientInfo":{"name":"kit","version":"0.1.134"},"clientCapabilities":{"session":{"compaction":{}}},"info":{"name":"kit","version":"0.1.134"},"capabilities":{}}}Observed response:
{"code":-32600,"message":"Invalid request","data":"unsupported ACP protocol version 2; this endpoint only supports ACP protocol version 1"}The JSON above is the response's error object. Control probes succeeded: v1 offered to the v1 endpoint selected v1; the same v2 offer sent to kit acp --protocol-version 2 selected v2. No provider request is required.
In the parent, this surfaces as:
ACP harness protocol handshake failure: the child did not complete the ACP handshake (harness="acp.kit", source=built-in current executable, cwd=configured working directory)
Expected behavior
Support v1-only child harnesses without requiring them to accept a v2 initialize request. Define a bounded, protocol-safe fallback or explicit version-selection mechanism. Distinguish an explicit unsupported-version rejection from authentication failures, malformed responses, process exits, and timeouts; do not blindly retry all startup errors or assume repeated initialize requests on the same connection are safe.
Retain normal v2 negotiation and advertise only capabilities appropriate to the selected version. The separate immediate fix to launch Kit's default built-in child explicitly as v2 addresses that launch mismatch, not generic v1 compatibility.
Coverage needed
Exercise the production custom client roles against actual v1-only and v2 endpoints, plus peers that legitimately select v1 in response to a v2 offer. Cover bounded fallback, terminal startup failures, and selected-version session dispatch.
The existing kit_server_advertises_supported_session_discovery_restoration_and_forking test uses the SDK's stock v1 client, which rewrites initialization to v1. Although the test constructs a v2 request, it does not establish that the production client's unchanged v2 wire offer works with a v1 endpoint.
Relevant code: src/acp_child/protocol.rs (initialize_params, initialize, negotiated), src/acp_child.rs (startup error classification), and src/protocols/acp.rs (v1 server).
Problem
Kit's child client offers ACP v2, but a v1-only endpoint can reject that initialization instead of selecting v1. The current client handles successful responses selecting either version, but does not recover from this explicit version rejection. Subagent startup then fails with a generic protocol handshake error.
This was reported as a regression in Kit v0.2.0. The local executable used for the direct reproduction below reports
kit 0.1.134; these are distinct observations, not a claim that the reproduction binary was the released v0.2.0 binary. Environment: macOS (Darwin arm64), built-inacp.kitchild launched from Kit.Reproduction
Launch a child without sending any model prompt:
Send this JSON-RPC line on stdin and leave stdin open:
{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":2,"clientInfo":{"name":"kit","version":"0.1.134"},"clientCapabilities":{"session":{"compaction":{}}},"info":{"name":"kit","version":"0.1.134"},"capabilities":{}}}Observed response:
{"code":-32600,"message":"Invalid request","data":"unsupported ACP protocol version 2; this endpoint only supports ACP protocol version 1"}The JSON above is the response's
errorobject. Control probes succeeded: v1 offered to the v1 endpoint selected v1; the same v2 offer sent tokit acp --protocol-version 2selected v2. No provider request is required.In the parent, this surfaces as:
Expected behavior
Support v1-only child harnesses without requiring them to accept a v2 initialize request. Define a bounded, protocol-safe fallback or explicit version-selection mechanism. Distinguish an explicit unsupported-version rejection from authentication failures, malformed responses, process exits, and timeouts; do not blindly retry all startup errors or assume repeated initialize requests on the same connection are safe.
Retain normal v2 negotiation and advertise only capabilities appropriate to the selected version. The separate immediate fix to launch Kit's default built-in child explicitly as v2 addresses that launch mismatch, not generic v1 compatibility.
Coverage needed
Exercise the production custom client roles against actual v1-only and v2 endpoints, plus peers that legitimately select v1 in response to a v2 offer. Cover bounded fallback, terminal startup failures, and selected-version session dispatch.
The existing
kit_server_advertises_supported_session_discovery_restoration_and_forkingtest uses the SDK's stock v1 client, which rewrites initialization to v1. Although the test constructs a v2 request, it does not establish that the production client's unchanged v2 wire offer works with a v1 endpoint.Relevant code:
src/acp_child/protocol.rs(initialize_params,initialize,negotiated),src/acp_child.rs(startup error classification), andsrc/protocols/acp.rs(v1 server).