Cloud sessions: `createSession({ cloud })` fails with -32601 since runtime 1.0.81, and SDK-created cloud tasks never start a sandbox

The failing call is createSession in nodejs/src/client.ts, where the SDK sets requestPermission and includeSubAgentStreamingEvents on session.create; the runtime returns -32601 for those fields when cloud is present. Reproduce by sending session.create with cloud and one callback field at a time against a local runtime. Part 2 (sandbox never starting) depends on the runtime and GitHub's task service, so a first-timer cannot verify it from the repo. Done means the cloud create reaches GitHub or fails with a named validation error.

Summary

The Cloud sessions feature doesn't work from the SDK on current releases. There are two separate problems:

1. Regression since runtime 1.0.81. createSession({ cloud }) fails at once with -32601 "Unhandled method session.create" when the request has any callback field. The SDK always sends two of them, so the docs example always fails.
2. No sandbox for SDK-created tasks. If we leave out those fields, the request reaches GitHub and creates a task. On an org repository where the cloud agent is enabled, no sandbox starts: the SDK times out after about 63 s and the task stays queued. On the same repository and account, a GitHub Copilot app cloud session starts a sandbox in about 10 s, and the interactive CLI (copilot --cloud --ui-server) in about 40 s.

Environment

• @github/copilot-sdk 1.0.28 (latest), 1.0.29-preview.1 and 1.0.0
• Runtime (@github/copilot) 1.0.105 (bundled copilot-runtime.exe and npm copilot.exe) and 1.0.106-2
• Windows 11 x64, Node 20. Token auth (gitHubToken, useLoggedInUser: false), isolated baseDirectory.
• The account has Copilot with cloud-agent entitlement. The same account creates cloud sessions with copilot --cloud --ui-server and the GitHub Copilot app.

Problem 1: -32601 on cloud create

Repro

The docs example:

const client = new CopilotClient({ gitHubToken, useLoggedInUser: false });
await client.start();
await client.createSession({
  onPermissionRequest: async () => ({ kind: "approve-once" }),
  cloud: { repository: { owner, name, branch: "main" } },
});
// JSON-RPC -32601 "Unhandled method session.create" after 2–5 ms.
// No network call, no task created.

Local createSession (no cloud) on the same SDK and runtime works and replies.

Which side returns the error

A stdio trace shows the runtime returning the error as the direct reply to session.create. It sends no request to the SDK first:

SDK->RT {"id":2,"method":"session.create","params":{"requestPermission":true,"requestUserInput":false,
         "requestElicitation":false,"requestExitPlanMode":false,"requestAutoModeSwitch":false,"hooks":false,
         "includeSubAgentStreamingEvents":true,"envValueMode":"direct",
         "cloud":{"repository":{"owner":"<owner>","name":"<repo>","branch":"main"}}, ...}}
RT->SDK {"id":2,"error":{"code":-32601,"message":"Unhandled method session.create"}}   (+2 ms)

Which fields trigger it

We sent session.create directly with cloud and one field at a time:

Fields sent with cloud	Result
requestPermission: true	-32601
includeSubAgentStreamingEvents: true	-32601
requestUserInput, requestElicitation, requestExitPlanMode, requestAutoModeSwitch or hooks = true	-32601 (each)
non-empty tools	-32601
all of the above false or absent	Reaches GitHub
name, provider, sessionId or managedSettings	Clear validation error, for example "Cannot specify name when creating a remote session in the cloud."

The SDK always sends requestPermission: true when onPermissionRequest is set, as in the docs example. It also sends includeSubAgentStreamingEvents: true by default (since #1108):

https://github.com/github/copilot-sdk/blob/68de1a7afe4bc9e7435d185825043bd9dc9c47cf/nodejs/src/client.ts#L1942

https://github.com/github/copilot-sdk/blob/68de1a7afe4bc9e7435d185825043bd9dc9c47cf/nodejs/src/client.ts#L1957

When it started

Runtime	Result
1.0.58, 1.0.70, 1.0.75, 1.0.78, 1.0.79, 1.0.80 (14 Aug)	Request reaches GitHub
1.0.81 (27 Aug), 1.0.82, 1.0.105, 1.0.106-2	-32601 in 2–5 ms

SDK 1.0.0 and SDK 1.0.28 give the same result on runtimes 1.0.80 and 1.0.105, so the change is in the runtime. The 1.0.81 changelog has no entry about cloud sessions or SDK callbacks. The Python cloud e2e test added in #2724 (20 Sep) creates a cloud session with a permission handler, but it runs against a fake CLI, so it couldn't catch this.

Workaround

Leave out onPermissionRequest (and all other on…Request handlers, tools and hooks), and set includeSubAgentStreamingEvents: false. The request then reaches GitHub. See Problem 2 for what happens next.

Problem 2: SDK-created cloud tasks never start a sandbox

Repro

The Problem 1 workaround on runtime 1.0.105, or the unchanged docs example on runtime 1.0.80:

await client.createSession({
  cloud: { repository: { owner, name, branch: "main" } },
  includeSubAgentStreamingEvents: false,
});

Repository: a private org repository with the cloud agent enabled (other agent tasks run there).

Result, on runtime 1.0.80 and on 1.0.105 with the workaround: after about 63 s, -32603 "Timed out waiting for the remote sandbox to start. The cloud session was created but its CLI host did not connect in time. Please try again." The task is still queued, with only a session.requested event, 15–20 minutes later.

On the same day, with the same account, the interactive CLI (copilot --cloud --ui-server) started a working sandbox on the same repository in about 40 s.

Control, to rule out capacity. We first deleted all of the account's earlier test tasks, so no idle sandboxes were left. Then we retried the SDK (runtime 1.0.105, with the workaround), and its task stayed queued again (timeout after 63.6 s). Two minutes later, a GitHub Copilot app cloud session on the same repository and account started a sandbox and finished its first turn in about 11 s.

The request bodies differ

We pointed COPILOT_MC_BASE_URL at a local mock to capture the task-creation request:

Path	Request	copilot-integration-id	Body
SDK createSession({ cloud })	POST /agents/tasks	copilot-sdk	{"repositories":[{"owner":"<owner>","name":"<repo>"}]} (no branch)
copilot --cloud --ui-server (interactive)	POST /agents/tasks	copilot-developer-cli	{"compute":{"scope":"<owner>"}}

Setting GITHUB_COPILOT_INTEGRATION_ID=copilot-developer-cli on the SDK path doesn't change the result. session.create ignores cloud.owner. sessions.open { kind: "cloud" } fails headless with "Unsupported native server host request 'request_sessions_open_remote'" (--headless, --server) or "Standalone server does not support host call 'request_sessions_open_remote'" (bundled runtime, in-process). We found no SDK call that sends the compute body on current runtimes.

Expected

• Problem 1: the docs example reaches GitHub, as it did on runtime 1.0.80. If callback fields aren't supported for cloud sessions, a validation error that names the field, as other unsupported cloud options already get.
• Problem 2: the sandbox starts and the session emits session.start from copilot-agent, as the docs describe and as copilot --cloud and app cloud sessions do.

Why it matters

We want a GitHub Actions workflow to start long-running cloud agents from event triggers, and to wake the agents later on CI or review events so they keep their context. The Actions-based cloud agent has a one-hour limit and starts each follow-up without the earlier conversation. The SDK cloud sessions feature is the documented way to do this from a script.

Wire traces, mock captures and task IDs are available on request.