Repository navigation
fix(remote): send integer ACP protocolVersion on the /acp initialize - #46
Merged
Merged
Conversation
Even with the #45 handshake fix, the remote `/acp` connection still fails at `initialize`: Studio sends `"protocolVersion": "2024-11-05"` (an MCP-style date string), but ACP versions the wire protocol with a **u16 integer**. The gateway deserializes the field as `u16`, so the string is rejected: "protocolVersion": "2024-11-05" -> error -32602 "invalid type: string \"2024-11-05\", expected u16" "protocolVersion": 1 -> result { agentCapabilities … } (verified live) Fix: the outer `/acp` handshake now sends `acp::ACP_PROTOCOL_VERSION` (u16 = 1). The *tunnelled* inner MCP `initialize` (relayed to the `oab-mcp` sidecar in `handle_inner`) correctly keeps the MCP date string — that one is MCP, not ACP, and is left untouched. A comment marks the distinction so the two are not "unified" by mistake, and a regression test asserts `ACP_PROTOCOL_VERSION` serializes to a JSON number. Verified live against wss://orca-acp.brettchien.cc/acp: with pv=1 the full initialize -> session/new completes and returns a sessionId (server side confirmed by Jellyfish). acp-tunnel unit tests pass; studio-desktop compilation left to CI. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #45. With the handshake fixed, the
/acpconnection now gets past the WS upgrade but stalls atinitialize.Root cause
Studio's outer ACP
initializesends"protocolVersion": "2024-11-05"— an MCP-style date string. ACP versions its wire protocol with a u16 integer, and the gateway deserializes the field asu16. Verified live on the same connection:(ACP ≠ MCP: MCP uses a date-string protocol version; ACP uses an integer.)
Fix
/acphandshake sendsacp::ACP_PROTOCOL_VERSION(u16 = 1), a new constant inacp-tunnel.initialize(relayed to theoab-mcpsidecar inhandle_inner) still uses the MCP date string — that one is MCP and is correct; a comment marks the distinction so they aren't accidentally unified.ACP_PROTOCOL_VERSIONserializes to a JSON number, not a string.Verification
protocolVersion: 1,initialize -> session/newcompletes and returns asessionIdagainstwss://orca-acp.brettchien.cc/acp(server side confirmed by Jellyfish).cargo test -p acp-tunnel— 20 passed (incl. newacp_protocol_version_is_an_integer_not_an_mcp_date_string).studio-desktopcompilation left to CI (desktop.yml).Together with #45 this makes the end-to-end remote reverse-MCP connection succeed.
🤖 Generated with Claude Code