SDK transitively installs @github/copilot@1.0.35, which regresses approved-permission handling → unexpected user permission response

[liamehenderson]

Summary

We consume Copilot programmatically via @github/copilot-sdk. The SDK declares @github/copilot as a dependency with a non-pinned range, so a fresh install pulls the latest CLI — currently 1.0.35. With CLI 1.0.35, the very first shell tool invocation fails with unexpected user permission response, even though our onPermissionRequest callback returns { kind: 'approved' }.

Forcing the CLI back to @github/copilot@1.0.34 (with the same SDK version) makes the problem disappear, so the regression appears to be CLI-side. Because most SDK consumers won't pin the transitive CLI version, anyone doing a clean install today picks up the broken combination by default.

Environment

• OS: Windows 11, PowerShell
• Node: 25.8.1
• Consumer: Node app using @github/copilot-sdk (no direct CLI usage)
• Models tested: gpt-5-mini (and others)

Repro matrix

In each case, only @github/copilot-sdk was added as a direct dependency; the CLI was either left to install transitively or explicitly pinned to confirm the cause.

@github/copilot-sdk	@github/copilot (transitive)	Result
0.2.0	1.0.34 (pinned)	✅ pass
0.2.2	1.0.34 (pinned)	✅ pass
0.2.2	1.0.35 (latest, default)	❌ unexpected user permission response
0.3.0-preview.0	1.0.35 (latest, default)	❌ unexpected user permission response

The SDK version is not the determining factor — the CLI version is.

Minimal reproduction (SDK only)

import { CopilotClient } from '@github/copilot-sdk';

const client = new CopilotClient({ logLevel: 'info' });
await client.start();

const session = await client.createSession({
  model: 'gpt-5-mini',
  workingDirectory: process.cwd(),
  onPermissionRequest: () => ({ kind: 'approved' }),
});

session.on('event', (e) => {
  if (e.type === 'tool.execution_complete' && e.error) {
    console.log('error:', e.error);
  }
});

await session.sendAndWait(
  "Run one shell command: `echo permission-probe`. Do not ask follow-up questions."
);

await client.stop();

Observed event sequence with the SDK + transitively installed CLI 1.0.35:

tool.execution_start: powershell (call_xxx)
tool.execution_complete error: unexpected user permission response

With the CLI pinned to 1.0.34 (same SDK code, same callback), the tool runs to completion.

Expected

When an SDK consumer's onPermissionRequest returns { kind: 'approved' }, the CLI should execute the requested tool.

Actual

The CLI rejects the SDK's approval payload with unexpected user permission response, failing the tool call on the very first attempt.

Workaround

SDK consumers must explicitly pin @github/copilot@1.0.34 alongside the SDK. Without an explicit pin, fresh installs pick up the broken CLI version.

[github-actions]

Investigation findings

Thanks for the detailed repro matrix — this is a genuine bug. Here's what I found:

What I looked at

• nodejs/src/session.ts — permission event dispatch and _executePermissionAndRespond
• nodejs/src/client.ts — v2/v3 protocol permission request routing
• nodejs/src/generated/rpc.ts — PermissionDecision types and handlePendingPermissionRequest
• nodejs/src/types.ts — PermissionRequestResult, approveAll, PermissionHandler
• nodejs/package.json — CLI dependency range
• sdk-protocol-version.json — current SDK protocol version

What I found

The SDK's onPermissionRequest handler is being used correctly. Returning { kind: 'approved' } is the documented, supported way to approve a permission request — it matches the PermissionDecisionApproved type in the generated RPC schema.

The root cause is a CLI compatibility break. When an onPermissionRequest handler returns { kind: 'approved' }, the SDK (in protocol v3 mode) responds via the session.permissions.handlePendingPermissionRequest RPC with { sessionId, requestId, result: { kind: 'approved' } }. CLI 1.0.34 accepted this; CLI 1.0.35 rejects it with unexpected user permission response.

The SDK repo already reflects awareness of this CLI version. The current main branch of the SDK already specifies "@github/copilot": "^1.0.35-0" as its minimum CLI dependency, meaning a protocol or behavioral change in 1.0.35 is known. However, the corresponding SDK fix has not yet been published to npm — released versions (0.2.x, 0.3.0-preview.0) were cut before or without the fix, and consumers on those versions are therefore exposed to the broken CLI by default.

Why it's a bug

The onPermissionRequest callback returning { kind: 'approved' } is the explicitly documented and tested API for allowing tool execution. The combination of the released SDK's ^ dependency range on @github/copilot transitively pulling in the broken CLI 1.0.35 — with no SDK update to compensate — means users' working permission handlers silently start failing on a clean install. This is a regression in expected behavior.

Workaround (until a fixed release ships)

Pin the transitive CLI version in your project:

npm install `@github/copilot`@1.0.34

Generated by Bug Handler for issue #1133 · ● 1.8M · ◷