Port upstream HTTP requestHandler / llmInference passthrough (BYOK bidirectional streaming)

[krukow]

_{Generated via Copilot on behalf of @krukow}

Summary

Deferred from the v1.0.1 → v1.0.4 upstream sync (@github/copilot 1.0.63 → 1.0.65). The upstream Node.js SDK added an entire HTTP/WebSocket request-handler subsystem for BYOK providers that the runtime can drive over JSON-RPC. This is large, self-contained, and best landed as its own follow-up PR rather than bundled with the smaller config/spec changes in the v1.0.4 sync.

What upstream added

A new ~818-line copilotRequestHandler.ts implementing bidirectional streaming for LLM inference requests proxied from the runtime to the SDK client:

• Buffered + SSE HTTP request/response forwarding.
• WebSocket frame forwarding.
• Dispatched runtime → client over JSON-RPC: llmInference.setProvider, LlmInferenceHttpRequestStart / Chunk, HttpResponseStart / Chunk, error / end-of-stream notifications, and WS frame messages.

Upstream PRs:

• HTTP request callback support github/copilot-sdk#1689
• Clean up HTTP passthrough API github/copilot-sdk#1784
• Address stephentoub review feedback on HTTP request callback support (+ cross-SDK parity) github/copilot-sdk#1775

Python ships the equivalent via httpx + websockets.

Why it's deferred

The Clojure SDK currently has no HTTP or WebSocket client dependency wired in. An idiomatic port needs:

• A streaming HTTP client (buffered + SSE) — likely core.async channels for chunk delivery.
• A WebSocket client for frame forwarding.
• Request cancellation / lifecycle management tied to session teardown.
• New inbound JSON-RPC handlers in setup-request-handler! following the permission-handler precedent.
• Specs + register-fdef! entries for any new public surface.

This is marked @experimental upstream, so there's no parity-breakage risk in shipping it separately.

Scope checklist (for the follow-up PR)

• Choose HTTP + WS client deps (evaluate http-kit, hato/java.net.http, gniazdo/Jetty WS).
• Port llmInference.setProvider registration.
• Port HTTP request-start/chunk/response-start/chunk/error/end streaming over core.async.
• Port WebSocket frame forwarding.
• Cancellation + resource cleanup on session stop.
• Specs + fdefs + instrumentation.
• Red/green TDD against the mock server; E2E if feasible.
• Docs (doc/auth/byok.md, API.md) + CHANGELOG.

References

• Node.js source of truth: nodejs/src/copilotRequestHandler.ts
• Python parity reference: python/copilot/

[krukow]

_{Generated via Copilot on behalf of @krukow}

Closing as not planned (for now).

The upstream HTTP/WebSocket copilotRequestHandler BYOK passthrough is a large (~800 LOC), self-contained, @experimental subsystem that would require pulling in new HTTP and WebSocket client dependencies the Clojure SDK doesn't currently carry, plus streaming/cancellation lifecycle work. Because it's experimental upstream, omitting it does not break parity — the stable SDK contract is unaffected.

I'd rather not add that dependency + maintenance surface speculatively. This is a good candidate to land as its own focused PR when there's concrete demand for BYOK bidirectional streaming from a Clojure consumer. The scope checklist in this issue is preserved for whoever picks it up — reopen (or file a fresh tracking issue) when that demand materializes.