Permission approvals fail with "unexpected user permission response: approved" (recurrence of #1133; now reproduces for both shell and read kinds)

[hukovpet]

Summary

Following up on #1133 (closed, fixed for kind: "shell"): a narrower recurrence
of the same underlying defect exists specifically for kind: "read" permission
requests (e.g. triggered by the built-in grep/search tool). An
onPermissionRequest callback that returns { kind: "approved" } is echoed
back correctly in the permission.completed event (result: { kind: "approved" }),
but the tool call still fails with the CLI's internal
permission orchestrator internal error: unexpected user permission response: approved.

kind: "shell" permissions work correctly on this same CLI version - this is
isolated to kind: "read".

Environment

• OS: Windows 11, PowerShell
• Node: v24.14.1
• @github/copilot-sdk: 1.0.9
• @github/copilot CLI: 1.0.80 (confirmed current via copilot update)
• Models tested: claude-sonnet-5

Repro matrix

Permission kind	Approval timing	Result
shell	near-instant	✅ pass
shell	~4s delay	✅ pass
read	near-instant	❌ unexpected user permission response: approved
read	~4s delay	❌ unexpected user permission response: approved

Minimal reproduction

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

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

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

session.on((e) => {
  if (e.type === "permission.completed" || e.type === "tool.execution_complete") {
    console.log(e.type, JSON.stringify(e.data));
  }
});

// Prompts that make the model use the read/search tool (not a raw shell command).
await session.send("Use the grep/search tool to search for the pattern 'probe' in this directory.");

Observed event sequence

permission.requested  (kind: "read")
permission.completed  {"result":{"kind":"approved"}}
tool.execution_complete  success:false
  error: "Failed to request permission: Error: permission orchestrator internal
          error: unexpected user permission response: approved"

Expected

When onPermissionRequest returns { kind: "approved" } for a kind: "read"
request, the CLI should execute the read/search tool, exactly as it already
does for kind: "shell" on this same CLI version.

[hukovpet]

Update: this is broader than "read-kind only" - shell now fails too, on a brand-new session

Re-tested today on a completely fresh, isolated session (never previously touched, no prior history) with @github/copilot-sdk and CLI still at the versions reported above:

• Asked the agent to run echo hello (a kind: "shell" request, via the built-in powershell/shell tool) and separately to search for *.txt files (a kind: "read" request, via the built-in glob/rg tools).
• Both requests were answered with { kind: "approved" } (confirmed via the emitted permission.completed event, which itself echoes back result: { kind: "approved" } for the correct requestId).
• Both kinds failed identically, on the very first attempt, with:

  permission orchestrator internal error: unexpected user permission response: approved
  

• Retried across a few more turns in the same session (all via an auto-approving handler, not manual click-approval, so timing was near-instant every time): shell failed 3/3 times, read failed 2/2 times.

This contradicts our earlier report that kind: "shell" "works correctly" - that must have been true only transiently. Nothing on our (consumer) side changed between the two tests. Given:

• the failure now reproduces for every kind we've tried,
• on a session with zero prior history (ruling out any per-session accumulated state),
• and the literal error text names the exact value sent (approved) as "unexpected",

this looks like it may be a protocol/serialization-level mismatch between the installed SDK version's permission-decision payload shape and what the current CLI runtime's "permission orchestrator" expects to parse, rather than something scoped to a specific tool kind. In other words, every permission request answered through the SDK's documented onPermissionRequest mechanism currently fails after being approved, regardless of kind, trust profile (confirmed on both plain "approve" and an auto-approving/autopilot-style handler), or session history.

Versions unchanged from the original report (@github/copilot-sdk 1.0.9, CLI 1.0.80/runtime 1.0.77, confirmed current via copilot update). Happy to provide the full raw event log from the fresh reproduction if useful.

[hukovpet]

Correction: this was not a CLI/runtime bug - it was our own consumer-side mistake. Closing.

Sorry for the noise here - after digging further (prompted by a good question about why the raw CLI's own --allow-all never shows this), we found the actual root cause, and it's entirely on our side, not in the CLI/runtime.

Root cause: our onPermissionRequest handler was returning { kind: "approved" } for an approval. That's wrong - "approved" is the past-tense result kind that only ever legitimately appears in a permission.completed event, not something a handler should return. The handler must return a present-tense decision kind instead (approve-once, approve-for-session, etc.).

This is exactly the distinction called out in the fix for #1133 (docs/samples were making the same mistake):

PermissionDecision (present tense) is what an onPermissionRequest handler returns... PermissionResult (past tense) is what shows up in permission.completed session events.

We missed this because the generated PermissionDecision union in generated/rpc.d.ts merges both concepts into one shared type, and "approved" really is a valid literal member of that union - so TypeScript happily compiles { kind: "approved" } as a handler return value even though it's semantically the wrong variant. Confirmed against your own shipped approveAll helper, which correctly returns { kind: "approve-once" }, never "approved".

After changing our handler to return { kind: "approve-once" } (single-request approvals) / { kind: "approve-for-session" } (session-scoped), the exact same reproduction that previously failed 100% of the time on both shell and read kinds now succeeds every time, first try, no other change.

This also explains why raw CLI usage with --allow-all never showed this: it doesn't go through this SDK-consumer-side handler code path at all.

Apologies again for the false alarm - closing this out. One small piece of constructive feedback for the SDK itself, if useful: since PermissionDecision and the past-tense result kinds share one generated union with overlapping/similarly-named literals (approved vs approve-once, approved-for-session vs approve-for-session, etc.), a stricter, separate type for what a handler is allowed to return (rather than the full shared union) would have caught this at compile time instead of only at runtime via the orchestrator's own validation error.

[hukovpet]

Closing per the correction above - this was a bug in our own SDK usage, not the CLI/runtime.