Add in-process FFI transport for Rust and TypeScript SDKs

[SteveSandersonMS]

Summary

Ports the C# in-process FFI hosting transport (merged in #1901) to the Rust and TypeScript/Node SDKs, mirroring the .NET RuntimeConnection.ForInProcess() API. Both SDKs load the runtime cdylib and speak JSON-RPC over its C ABI (copilot_runtime_host_start / connection_open / connection_write / connection_close / host_shutdown) instead of spawning a stdio/TCP child process. Framing is unchanged — it's a transport swap over the existing LSP Content-Length JSON-RPC codec.

Rust

• New Transport::InProcess variant; COPILOT_SDK_DEFAULT_CONNECTION (inprocess/stdio/unset) selects the default, mirroring .NET's ResolveDefaultConnection.
• rust/src/ffi.rs: libloading C-ABI bindings, AsyncRead/AsyncWrite bridge between the outbound callback and connection_write, ordered teardown.
• build.rs / embeddedcli.rs: best-effort extract + rename of prebuilds/<platform>/runtime.node → libcopilot_runtime.{so,dylib} / copilot_runtime.dll next to the CLI (mirrors the .NET .targets).
• Discovery: flat natural lib name, else prebuilds/<node-platform>-<arch>/runtime.node.
• In-process E2E test + test-inprocess CI job.

TypeScript

• RuntimeConnection.forInProcess() + InProcessRuntimeConnection.
• nodejs/src/ffiRuntimeHost.ts: koffi loads runtime.node directly from the @github/copilot-<platform> package (no rename); async host_start, registered outbound callback bridged to vscode-jsonrpc streams.
• COPILOT_SDK_DEFAULT_CONNECTION default + in-process E2E test + transport CI matrix cell.

CI

Both workflows gain an inprocess transport cell that sets COPILOT_SDK_DEFAULT_CONNECTION=inprocess, matching dotnet-sdk-tests.yml.

Status / known gaps (draft — letting CI surface these)

• Dedicated in-process E2E tests pass locally for both SDKs; Node client.e2e (incl. auth + list-models) passes fully in-process.
• Node MCP tests time out in-process (mcp_and_agents): the in-process host addon runs in the SDK's own process and reads process.env, so the harness-supplied proxy-redirect env (passed as options.env) doesn't reach MCP-related host-side paths the way it does for a spawned stdio child. Needs follow-up on env propagation for the in-process worker/host.
• Rust default (bundled, no COPILOT_CLI_PATH) path is untested locally because the GitHub-release CLI tarball doesn't yet ship runtime.node; CI uses the npm platform package via COPILOT_CLI_PATH.

🤖 Generated with in-process FFI port; opening as draft to let CI run the full matrix.

[github-actions]

Generated by SDK Consistency Review Agent for issue #1915 · sonnet46 2M

[github-actions]

Cross-SDK consistency note — option validation approach differs from .NET

The .NET SDK (added in #1901) throws ArgumentException at construction time if Environment or Telemetry options are set alongside ForInProcess():

// dotnet/src/Client.cs
if (options.Environment is not null)
    throw new ArgumentException("...per-client values. Set the variables on the host process environment instead.");
if (options.Telemetry is not null)
    throw new ArgumentException("...Configure telemetry via the host process environment...");

TypeScript currently documents the limitation in the @experimental tag but silently ignores env, telemetry, gitHubToken, and baseDirectory at runtime without any error or warning. This means a caller who sets gitHubToken and then switches to in-process transport will see silent auth failures rather than a clear error.

Worth considering whether to match .NET's fail-fast approach (throw during CopilotClient construction when incompatible options are detected) so the SDK surface is consistent across languages. Rust takes a third path: it explicitly builds the env and passes it to host_start via the C ABI, so those options are actually honored there.

[github-actions]

Generated by SDK Consistency Review Agent for issue #1915 · sonnet46 2.4M

[github-actions]

Cross-SDK consistency note: The Rust SDK's build_ffi_environment (rust/src/lib.rs:1439) explicitly applies per-client options — github_token → COPILOT_SDK_AUTH_TOKEN, telemetry, base_directory, custom env — to the in-process transport. This method silently ignores those same options, inheriting only the host process's ambient environment.\n\nThis creates a cross-SDK behavioral difference: a user who sets gitHubToken: 'ghp_...' will have auth work automatically in the Rust SDK but will need to manually set COPILOT_SDK_AUTH_TOKEN in the process environment for the TypeScript SDK.\n\nFor short-term alignment with .NET's approach, consider adding validation that throws when options that can't be honored are set in combination with forInProcess(), e.g.:\nts\nif (this.options.gitHubToken) {\n throw new Error(\n 'CopilotClientOptions.gitHubToken is not currently supported with the in-process transport. ' +\n 'Set COPILOT_SDK_AUTH_TOKEN on the host process environment instead. ' +\n 'See https://github.com/github/copilot-sdk/issues/1934.'\n );\n}\n\nThis avoids silent misconfiguration until #1934 is resolved.

[github-actions]

Cross-SDK consistency note: This Rust build_ffi_environment correctly applies per-client options (github_token, telemetry, base_directory, custom env) to the in-process transport, which is more user-friendly than .NET's approach (which rejects Environment/Telemetry with ArgumentException and silently ignores GitHubToken).\n\nHowever, the TypeScript SDK in this same PR takes a third approach: it silently ignores all per-client options for in-process transport (tracked in #1934). It would be worth adding a comment here or in the Rust client docs noting that the Rust in-process transport honors per-client options, since this is a divergence from the TypeScript behavior in this PR.

[github-actions]

Generated by SDK Consistency Review Agent for issue #1915 · sonnet46 2M

Comments that could not be inline-anchored

nodejs/src/client.ts:639

Cross-SDK consistency: missing eager validation for inprocess + incompatible options

The .NET SDK (reference implementation since #1901) throws an ArgumentException in the constructor when Environment or Telemetry options are set alongside InProcessRuntimeConnection — see Client.cs ValidateEnvironmentOptions(). The new TypeScript implementation only documents the limitation in JSDoc but silently ignores those options, which can be confusing.

Suggest adding a "fail fast" chec…

rust/src/lib.rs:1012

Cross-SDK consistency: missing eager validation for Transport::InProcess + incompatible options

The .NET SDK (reference since #1901) rejects incompatible options early with ArgumentException. The TypeScript implementation (also added in this PR) has the same gap. For Rust, suggest adding a validation block after the External checks, mirroring the pattern here:

if matches!(options.transport, Transport::InProcess) {
    if options.github_token.is_some() {
        return Err(Er…

</details>

[github-actions]

Cross-SDK Consistency Review

This PR ports the in-process FFI transport from .NET (#1901) to TypeScript and Rust. Here's how the implementations compare.

✅ API naming — consistent across the three SDKs

SDK	Transport selection	Factory / variant
.NET	RuntimeConnection.ForInProcess()	InProcessRuntimeConnection class
TypeScript	RuntimeConnection.forInProcess()	InProcessRuntimeConnection interface
Rust	Transport::InProcess enum variant	—

COPILOT_SDK_DEFAULT_CONNECTION env-var override is implemented consistently in all three SDKs with the same accepted values (inprocess / stdio / unset) and the same error on any other value. ✅

⚠️ One consistency gap: missing fail-fast validation for per-client options

The .NET SDK throws ArgumentException at construction time if Environment or Telemetry are set alongside RuntimeConnection.ForInProcess() (see ValidateEnvironmentOptions in Client.cs). This gives callers an early, actionable error rather than silently ignoring the config.

Neither the TypeScript nor the Rust SDK currently validate this. A caller who passes gitHubToken / telemetry / env with the in-process transport will see those values silently dropped, which can be hard to debug (especially gitHubToken — auth appearing not to work with no error message).

I've left inline suggestions on the specific lines in nodejs/src/client.ts and rust/src/lib.rs where this validation could be added to match .NET behaviour.

i️ Python, Go, Java — expected gap

None of the three remaining SDKs implement in-process FFI transport yet, and none handle COPILOT_SDK_DEFAULT_CONNECTION. This is an expected gap for a multi-PR rollout (no action needed in this PR), but worth tracking so it doesn't stay inconsistent long-term once the feature graduates from experimental.

Generated by SDK Consistency Review Agent for issue #1915 · sonnet46 2M · ◷

[github-actions]

Generated by SDK Consistency Review Agent for issue #1915 · sonnet46 2M

[github-actions]

Cross-SDK consistency gap: missing validation for per-client options with inprocess transport

The .NET SDK (added in #1901) throws ArgumentException at construction time when Environment or Telemetry options are set alongside RuntimeConnection.ForInProcess() (Client.cs ValidateEnvironmentOptions). This gives callers an early, actionable error rather than silently ignoring the configuration.

The TypeScript SDK documents the limitation well in the JSDoc, but doesn't fail fast. A caller who passes gitHubToken, telemetry, baseDirectory, or env with { kind: "inprocess" } will see those values silently dropped.

To mirror .NET, consider adding a guard in the constructor alongside the existing uri validation above:

if (conn.kind === "inprocess") {
    if (options.gitHubToken !== undefined) {
        throw new Error(
            "gitHubToken is not supported with RuntimeConnection.forInProcess(): the in-process " +
            "transport inherits the host process environment. Set COPILOT_SDK_AUTH_TOKEN on the " +
            "host process instead."
        );
    }
    if (options.telemetry !== undefined) {
        throw new Error(
            "telemetry is not supported with RuntimeConnection.forInProcess(): telemetry config " +
            "is lowered to environment variables that cannot vary per-client in-process."
        );
    }
    // optionally: env, baseDirectory
}

This is especially important for gitHubToken — a caller who sets it expecting authentication to work will get a confusing silent failure without this guard.

[github-actions]

Cross-SDK consistency gap: missing validation for per-client options with Transport::InProcess

The .NET SDK throws ArgumentException when Environment or Telemetry are passed with RuntimeConnection.ForInProcess() (see ValidateEnvironmentOptions in Client.cs). Rust documents the limitation in InProcess's docstring but doesn't return an early Err.

Consider adding a validation block here analogous to the Transport::External check just above:

if matches!(options.transport, Transport::InProcess) {
    if options.github_token.is_some() {
        return Err(Error::with_message(
            ErrorKind::InvalidConfig,
            "github_token cannot be used with Transport::InProcess: the in-process \
             runtime inherits the host process environment. Set COPILOT_SDK_AUTH_TOKEN \
             on the host process instead.",
        ));
    }
    if options.telemetry.is_some() {
        return Err(Error::with_message(
            ErrorKind::InvalidConfig,
            "telemetry cannot be used with Transport::InProcess: telemetry config is \
             lowered to environment variables that cannot vary per-client in-process.",
        ));
    }
    // optionally: env, env_remove, base_directory
}

Without this, callers who set github_token expecting authentication will get a silent failure rather than an actionable error message.