Skip to content

feat: add protocol version 3 support with v3 broadcast event model#4

Open
pjperez wants to merge 5 commits intocopilot-community-sdk:mainfrom
pjperez:fix/protocol-v3-support
Open

feat: add protocol version 3 support with v3 broadcast event model#4
pjperez wants to merge 5 commits intocopilot-community-sdk:mainfrom
pjperez:fix/protocol-v3-support

Conversation

@pjperez
Copy link

@pjperez pjperez commented Mar 9, 2026

Protocol Version 3 Support

Add full protocol v3 support to align with the official GitHub Copilot SDKs (Python, Node.js, Go, .NET).

Problem

The Copilot CLI runtime has updated to protocol version 3, but the Rust SDK only supported version 2 with a strict equality check. This causes a hard failure: Protocol version mismatch: expected 2, got 3.

All official SDKs (in the github/copilot-sdk monorepo) already declare support for protocol versions 2-3 with range-based checking and include v3 broadcast event handling.

Changes

Version constants and range checking:

  • SDK_PROTOCOL_VERSION bumped from 2 to 3
  • Added MIN_PROTOCOL_VERSION = 2 to establish a supported version range
  • verify_protocol_version() now uses MIN..MAX range check instead of strict equality
  • Negotiated protocol version is stored after successful handshake for runtime use
  • ProtocolMismatch error now reports the supported version range

Protocol v3 broadcast event model:

In protocol v3, tool calls and permission requests are sent as broadcast session events (external_tool.requested, permission.requested) instead of JSON-RPC requests. This PR adds:

  • New event data types: ExternalToolRequestedData, PermissionRequestedData
  • New SessionEventData variants for these events
  • handle_broadcast_event() in Session — intercepts v3 events in dispatch_event(), executes the registered tool/permission handlers, and sends results back via session.tools.handlePendingToolCall / session.permissions.handlePendingPermissionRequest RPC calls
  • v2 RPC request handlers (tool.call, permission.request) are kept as backward-compatibility adapters — a v3 server simply never sends them

Comparison with Official SDKs

Feature Official SDKs This PR
Version range (MIN..MAX) 2-3 2-3
SDK_PROTOCOL_VERSION = 3 Yes Yes
Negotiated version stored Yes Yes
v3 broadcast tool calls Yes Yes
v3 broadcast permissions Yes Yes
v2 backward compat adapters Yes Yes

Files changed

  • src/types.rs — Version constants
  • src/error.rs — ProtocolMismatch error format
  • src/events.rs — New v3 event types and parsing
  • src/session.rs — Broadcast event handling in dispatch
  • src/client.rs — Range check, negotiated version, handler comments

pjperez added 5 commits March 9, 2026 08:41
- Bump SDK_PROTOCOL_VERSION to 3 (matches official SDKs)
- Add MIN_PROTOCOL_VERSION = 2 for range-based checking
- SDK now declares support for protocol versions 2-3
Report supported version range (min-max) in error message
instead of a single expected version. Aligns with official SDKs.
Add ExternalToolRequestedData and PermissionRequestedData structs
for the protocol v3 broadcast model where tool calls and permission
requests arrive as session events instead of RPC requests.
Add handle_broadcast_event() to Session::dispatch_event() that
intercepts external_tool.requested and permission.requested events,
executes registered handlers, and responds via handlePendingToolCall
/ handlePendingPermissionRequest RPC. v2 RPC handlers kept as
backward-compat adapters.
- verify_protocol_version() now checks MIN..MAX range
- Stores negotiated_protocol_version for runtime use
- Added v2/v3 backward-compat comments to setup_handlers
- Aligns with official Python/Node/Go SDK implementations
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant