SDK 0.3.0 fails to connect to remote headless CLI 1.0.36 over JSON-RPC

[mhartvig]

Summary

GitHub.Copilot.SDK 0.3.0 fails to connect to a remote @github/copilot 1.0.36 CLI running in headless JSON-RPC mode (--headless --port 4321). The same setup works against SDK 0.2.2 / CLI 1.0.21. The pairing in each case is the matching SDK→CLI version that ships with that SDK release, so this is not a deliberately
mismatched combination — it only manifests when the SDK talks to a CLI it does not spawn itself.

Environment

• SDK: GitHub.Copilot.SDK 0.3.0 (NuGet)
• CLI: @github/copilot 1.0.36, installed globally inside node:20-bookworm-slim
• CLI launch: copilot --no-auto-update --headless --port 4321
• Client config: CopilotClientOptions { CliUrl = "localhost:4322", UseStdio = false } (host port 4322 mapped to container 4321)
• Host OS: Windows 11, .NET 10
• Auth: COPILOT_GITHUB_TOKEN PAT with Copilot access, passed into the container via -e

Expected

CopilotClient.StartAsync connects, CreateSessionAsync succeeds, and SendAndWaitAsync({ Prompt = "Hi" }) returns a response — same as the 0.2.2 / 1.0.21 baseline.

Actual

StartAsync (or the first session call — whichever is hit first) throws a JSON-RPC error:

Unhandled exception. System.IO.IOException: Communication error with Copilot CLI: The JSON-RPC connection with the remote party was lost before the request could complete.
---> StreamJsonRpc.ConnectionLostException: The JSON-RPC connection with the remote party was lost before the request could complete.
---> System.OperationCanceledException: The operation was canceled.
  at System.Threading.CancellationToken.ThrowOperationCanceledException()
  at System.Threading.CancellationToken.ThrowIfCancellationRequested()
  at StreamJsonRpc.MessageHandlerBase.WriteAsync(JsonRpcMessage content, CancellationToken cancellationToken)
  at StreamJsonRpc.JsonRpc.SendAsync(JsonRpcMessage message, CancellationToken cancellationToken)
  at StreamJsonRpc.JsonRpc.InvokeCoreAsync(JsonRpcRequest request, Type expectedResultType, CancellationToken cancellationToken)
  --- End of inner exception stack trace ---
  at StreamJsonRpc.JsonRpc.InvokeCoreAsync(JsonRpcRequest request, Type expectedResultType, CancellationToken cancellationToken)
  at StreamJsonRpc.JsonRpc.InvokeCoreAsync[TResult](RequestId id, String targetName, IReadOnlyList`1 arguments, IReadOnlyList`1 positionalArgumentDeclaredTypes, IReadOnlyDictionary`2 namedArgumentDeclaredTypes, CancellationToken cancellationToken, Boolean isParameterObject)
  at GitHub.Copilot.SDK.CopilotClient.InvokeRpcAsync[T](JsonRpc rpc, String method, Object[] args, StringBuilder stderrBuffer, CancellationToken cancellationToken)
  --- End of inner exception stack trace ---
  at GitHub.Copilot.SDK.CopilotClient.InvokeRpcAsync[T](JsonRpc rpc, String method, Object[] args, StringBuilder stderrBuffer, CancellationToken cancellationToken)
  at GitHub.Copilot.SDK.CopilotClient.VerifyProtocolVersionAsync(Connection connection, CancellationToken cancellationToken)
  at GitHub.Copilot.SDK.CopilotClient.<StartAsync>g__StartCoreAsync|25_0(CancellationToken ct)
  at GitHub.Copilot.SDK.CopilotClient.CleanupConnectionAsync(List`1 errors)
  at GitHub.Copilot.SDK.CopilotClient.ForceStopAsync()
  at GitHub.Copilot.SDK.CopilotClient.DisposeAsync()
  at Program.<Main>$(String[] args) in C:\Code\copilot-sdk-docker-remote\src\BrokenRepro\Program.cs:line 52
  at Program.<Main>(String[] args)

The container is reachable on the mapped port (TCP connect succeeds before the SDK call) and the CLI process inside the container is running and listening. The same client code against CLI 1.0.21 with SDK 0.2.2 succeeds against an otherwise identical container.

Repro

Minimal repro (Dockerfile + two side-by-side console projects, one per SDK/CLI pairing):
https://github.com/mhartvig/copilot-sdk-docker-remote

./run.sh working --token # SDK 0.2.2 + CLI 1.0.21 — succeeds
./run.sh broken --token # SDK 0.3.0 + CLI 1.0.36 — fails

Each launcher builds the pinned CLI image, starts the container with --headless --port 4321, waits for the port, then runs:

var clientOptions = new CopilotClientOptions { CliUrl = cliUrl, UseStdio = false };
await using var client = new CopilotClient(clientOptions);
await client.StartAsync(ct);

var session = await client.CreateSessionAsync(new SessionConfig
{
SessionId = "user-123-task-456",
OnPermissionRequest = PermissionHandler.ApproveAll,
});

await session.SendAndWaitAsync(new MessageOptions { Prompt = "Hi" });

Notes

• UseStdio = false + CliUrl is used, so the SDK is acting purely as a JSON-RPC client; it is not spawning the bundled CLI binary that ships with the NuGet package.
• The CLI version installed in the container matches the version the SDK release ships with, so the SDK/CLI pair is the intended pairing — just not the one being launched in-process.
• Container is stock node:20-bookworm-slim plus git and ca-certificates; no proxy or custom networking.

[github-actions]

Investigation findings

Thanks for the detailed repro! I investigated the reported failure and believe this is a genuine bug.

What I looked at

• dotnet/src/Client.cs — ParseCliUrl, ConnectToServerAsync, VerifyProtocolVersionAsync, StartCoreAsync, and the dispose/cleanup paths
• The full stack trace and error chain you provided
• The diff between v0.2.2 and v0.3.0 (PR Per-session GitHub authentication for all SDK languages #1124 and related), and the git log between the two tags
• The multi-client E2E tests (MultiClientTests.cs) that exercise the CliUrl path
• The Node SDK and Go SDK TCP connection paths for comparison
• The CLI version shipped with each SDK release (1.0.21 for 0.2.2, 1.0.36-0 for 0.3.0)

What I found

The CliUrl pattern is intentionally supported and tested. The multi-client E2E tests (MultiClientTests.cs) exercise the exact same code path — one client spawns the CLI, a second client connects via CliUrl = $"localhost:{port}". If this path were generally broken it would show up in CI.

The SDK connection code is unchanged between v0.2.2 and v0.3.0. ConnectToServerAsync, ParseCliUrl, and VerifyProtocolVersionAsync are identical in both versions. The ping-based protocol handshake was already present in 0.2.2. The only meaningful changes in 0.3.0 (PR #1124) were adding GitHubToken to session create/resume requests and renaming a permission enum value — neither touches connection establishment.

The error indicates the CLI is closing the TCP connection before the first message can be sent. The innermost exception OperationCanceledException at CancellationToken.ThrowIfCancellationRequested() inside WriteAsync is how StreamJsonRpc reports "the connection was already closed when you tried to write." This means rpc.StartListening() detected a closed socket (EOF/RST from the CLI side) before VerifyProtocolVersionAsync could enqueue its ping. The stack trace being routed through DisposeAsync is secondary — the await using var client block calls DisposeAsync after the exception from StartAsync, and CleanupConnectionAsync re-surfaces the same faulted _connectionTask.

CLI 1.0.36 is the likely source of the regression. The SDK wire protocol (LSP-framed JSON over raw TCP: Content-Length: N\r\n\r\n{...}) is the same in both versions. What's different is the CLI. Between 1.0.21 and 1.0.36 something changed in the server's connection-handling behavior that causes it to close external TCP connections immediately — possibly a new authentication initialization sequence, a startup-readiness race (port open but JSON-RPC not yet ready), or a new connection-acceptance requirement introduced alongside the per-session-auth feature in CLI 1.0.36.

The fact that SDK 0.3.0 works when it spawns CLI 1.0.36 itself (because it waits for the "listening on port" stderr signal and potentially benefits from different startup flags or timing) but fails when connecting to an externally-started CLI 1.0.36 strongly points to a CLI-side change that the SDK's external connection path hasn't been updated to accommodate.

Why this is a bug

The CliUrl external-server pattern is documented, tested, and supported. SDK 0.3.0 shipping with CLI 1.0.36 means these two versions are the intended pairing, and external CliUrl connections must work. The regression from 0.2.2 → 0.3.0 in this specific configuration is a bug.

Suggested next steps

1. Check CLI 1.0.36 server logs (stderr from the container) for any error or "connection rejected" message when the .NET SDK connects.
2. Compare the CLI's startup behavior: try adding --log-level debug to the container's copilot invocation.
3. Confirm whether Node or Go SDKs also fail with the same CLI 1.0.36 external setup, or if the issue is .NET-specific (this would help narrow down whether it's a CLI-level or transport-level issue).

Generated by Bug Handler for issue #1153 · ● 3.6M · ◷