phimage
← Writing

Copilot SDK in technical preview — and why a 4D one is within reach

GitHub put the Copilot SDK into technical preview, giving you programmatic access to the Copilot CLI instead of only driving it by hand in a terminal. It ships in four languages out of the gate:

  • Node.js / TypeScript@github/copilot-cli-sdk
  • Pythoncopilot
  • Gogithub.com/github/copilot-cli-sdk-go
  • .NETGitHub.Copilot.SDK

All four expose the same shape: multi-turn sessions (history kept for context), custom tool execution (define tools the model can call mid-conversation), and full lifecycle control over the client and its sessions. The getting-started guide walks through each.

The trick is the same one, again

Here’s the part worth dwelling on. An SDK in a new language sounds like a big lift, but it isn’t — because under the hood the SDK doesn’t reimplement Copilot. It just launches the copilot CLI as a subprocess (stdio, or HTTP with a port) and talks to it over JSON-RPC.

If that sounds familiar, it should: it’s the exact same plumbing as MCP, LSP, and ACP. One process speaks a line-delimited JSON-RPC protocol; everyone else is a client. Once you’ve internalized that pattern, half the modern agent/tooling ecosystem stops looking like separate magic and starts looking like the same Lego brick wearing different hats.

Which is also why the official four aren’t the ceiling. There’s already a community SDK org filling in more languages, including a C++ one. The barrier to “language X gets a Copilot SDK” is just: can language X spawn a process and read/write JSON? Almost all of them can.

I pulled the Python sources apart to see exactly how the wiring works and wrote it up here: how the Copilot SDK works.

So… a 4D SDK?

This is the bit I keep coming back to. If an SDK is “spawn the CLI + JSON-RPC”, then any app can host a Copilot agent — including a 4D application. 4D can launch worker processes and it speaks HTTP and JSON natively, which is the whole requirement. A small 4D-copilot component wrapping the CLI’s stdio (or HTTP) transport would let a 4D.app — or anything built with 4D — drive an agent the same way the Node and Python SDKs do. No reimplementation, just a transport adapter and a thin session API.

Worth reading


The headline is “Copilot SDK ships in four languages.” The more interesting story is that, thanks to a boring shared transport, the real number is however many languages can run a subprocess — and that list includes the one I write 4D in. 🧩


EDIT — and then I built the 4D one

I ended this post wondering whether a 4D Copilot SDK was reachable. It was — here’s the proof, both from June 2026:

  • mesopelagique/CopilotSDK — a Copilot SDK for 4D, driving the CLI exactly as described above.
  • mesopelagique/CopilotSDKToOpenAI — the piece I actually wanted: it wraps that as an OpenAI-compatible endpoint, so 4D AIKit can point straight at it. The “thin transport adapter” from the last section, made real.

Spawn the CLI, speak JSON-RPC, expose it as /v1/chat/completions — and 4D has a Copilot. The boring shared transport delivered again.


← Back to all writing