You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The SDK and CLI must have compatible protocol versions. The SDK will log warnings if versions are mismatched.
182
+
The SDK and CLI negotiate a compatible protocol version at startup. The SDK advertises a supported range (`minVersion`–`version`) and the CLI reports its version via `ping`. If the CLI's version falls within the SDK's range, the connection succeeds; otherwise, the SDK throws an error.
## Protocol v3: Broadcast Events and Multi-Client Sessions
192
+
193
+
Protocol v3 changes how the SDK handles tool calls and permission requests internally. **No user-facing API changes are required** — existing code continues to work.
194
+
195
+
### What Changed
196
+
197
+
| Aspect | Protocol v2 | Protocol v3 |
198
+
|--------|-------------|-------------|
199
+
|**Tool calls**| CLI sends RPC request directly to the SDK | CLI broadcasts `external_tool.requested` event to all connected clients |
200
+
|**Permission requests**| CLI sends RPC request directly to the SDK | CLI broadcasts `permission.requested` event to all connected clients |
201
+
|**Multi-client**| One SDK client per CLI server | Multiple SDK clients can share a CLI server and session |
202
+
203
+
### How It Works
204
+
205
+
In v3, the CLI broadcasts tool and permission events to every connected client. Each client checks whether it has a matching handler:
206
+
207
+
- If the client has a handler for the requested tool, it executes the tool and sends the result back via `session.tools.handlePendingToolCall`.
208
+
- If the client doesn't have the handler, it responds with an "unsupported" result.
209
+
- Permission requests follow the same pattern via `session.permissions.handlePendingPermissionRequest`.
210
+
211
+
The SDK handles all of this automatically — you register tools and permission handlers the same way as before:
With v3, multiple SDK clients can connect to the same CLI server (via `cliUrl`) and share sessions. Each client can register different tools, and the broadcast model routes tool calls to the client that has the matching handler.
234
+
235
+
See the [Multi-Client Session Sharing](./guides/session-persistence.md#multi-client-session-sharing) section in the Session Persistence guide for details and code samples.
236
+
237
+
## Upgrading from v2 to v3
238
+
239
+
Upgrading is straightforward — no code changes required:
240
+
241
+
1.**Update the SDK package** to the latest version
242
+
2.**Update the CLI** to a version that supports protocol v3
243
+
3.**That's it** — the SDK auto-negotiates the protocol version
244
+
245
+
The SDK remains backward-compatible with v2 CLI servers. If the CLI only supports v2, the SDK operates in v2 mode automatically. Multi-client session features are only available when both the SDK and CLI use v3.
246
+
247
+
| Step | TypeScript | Python | Go | .NET |
248
+
|------|-----------|--------|-----|------|
249
+
| Update SDK |`npm install @github/copilot-sdk@latest`|`pip install --upgrade copilot-sdk`|`go get github.com/github/copilot-sdk/go@latest`| Update `PackageReference` version |
250
+
| Update CLI |`npm install @github/copilot@latest`| Bundled with SDK | External install | Bundled with SDK |
|**BYOK re-authentication**| API keys aren't persisted | Store keys in your secret manager; provide on resume |
504
504
|**Writable storage**|`~/.copilot/session-state/` must be writable | Mount persistent volume in containers |
505
-
|**No session locking**| Concurrent access to same session is undefined | Implement application-level locking or queue |
506
505
|**Tool state not persisted**| In-memory tool state is lost | Design tools to be stateless or persist their own state |
507
506
508
507
### Handling Concurrent Access
509
508
510
-
The SDK doesn't provide built-in session locking. If multiple clients might access the same session:
509
+
With protocol v3, the SDK supports **multi-client session sharing** — multiple SDK clients can connect to the same CLI server and operate on the same session simultaneously. The CLI broadcasts tool and permission events to all connected clients, and each client handles the events for tools it has registered.
510
+
511
+
If your use case requires **strict serialization** (e.g., only one client sends prompts at a time), you can still use application-level locking:
For multi-client session sharing without locking, see the next section.
545
+
546
+
## Multi-Client Session Sharing
547
+
548
+
Protocol v3 enables multiple SDK clients to share a session via broadcast events. This is useful for architectures where different services each provide different tools, or where a session needs to be accessible from multiple processes.
549
+
550
+
```mermaid
551
+
flowchart TB
552
+
subgraph clients["SDK Clients"]
553
+
A["Client A<br/>(tool: search_docs)"]
554
+
B["Client B<br/>(tool: run_tests)"]
555
+
end
556
+
557
+
subgraph server["CLI Server"]
558
+
CLI["Copilot CLI<br/>cliUrl: localhost:3000"]
559
+
S["Session: task-123"]
560
+
end
561
+
562
+
A -->|cliUrl| CLI
563
+
B -->|cliUrl| CLI
564
+
CLI --> S
565
+
S -->|broadcast: external_tool.requested| A
566
+
S -->|broadcast: external_tool.requested| B
567
+
```
568
+
569
+
### How It Works
570
+
571
+
1. Start a CLI server (or use an existing one accessible via `cliUrl`)
572
+
2. Client A connects and creates a session, registering its tools
573
+
3. Client B connects and resumes the same session, registering different tools
574
+
4. When the model calls a tool, the CLI broadcasts the request to all clients
575
+
5. Each client checks if it has the requested tool and responds accordingly
|**Distribute tools uniquely**| Each tool should be registered on exactly one client. If multiple clients register the same tool, only one response will be used. |
740
+
|**Always provide `onPermissionRequest`**| Each client that might receive permission broadcasts should have a handler. |
741
+
|**Use meaningful session IDs**| Shared sessions need predictable IDs so all clients can find them. |
742
+
|**Handle disconnections gracefully**| If a client disconnects, its tools become unavailable. Design your system so remaining clients can still operate. |
743
+
543
744
## Summary
544
745
545
746
| Feature | How to Use |
546
747
|---------|------------|
547
748
|**Create resumable session**| Provide your own `sessionId`|
0 commit comments