Repository navigation
[BUG]: 0.3.0-java.2: permission.completed cannot deserialize approve-once in PermissionCompletedKind #126
Description
What happened?
I ran into what looks like an internal enum mismatch in copilot-sdk-java:0.3.0-java.2.
After updating only the Java SDK version, tool calls started failing during permission handling.
What happens
The SDK sends the new permission result kind approve-once, but later fails when deserializing the corresponding permission.completed event because com.github.copilot.sdk.generated.PermissionCompletedKind does not recognize that value.
This leads to errors like:
Error: Unhandled permission result kind: [object Object]
Environment
copilot-sdk-java:0.3.0-java.2- CLI version unchanged from the previously working setup
- Java app running inside Eclipse RCP / OSGi
Reproduction
- Update to
copilot-sdk-java:0.3.0-java.2 - Use the normal permission approval flow, for example
PermissionHandler.APPROVE_ALL - Trigger a tool call that requires permission
- Observe the permission flow fail when the
permission.completedevent is processed
Expected behavior
The SDK should consistently handle the new permission result kinds end-to-end.
If PermissionRequestResultKind.APPROVED now maps to approve-once, then PermissionCompletedKind should also accept approve-once.
Actual behavior
The request side uses the new value:
PermissionRequestResultKind.APPROVED = "approve-once"but the generated event enum still only accepts old values such as:
approvedapproved-for-sessionapproved-for-location
and rejects approve-once.
Temporary workaround
For now, I can avoid the failure by not using PermissionHandler.APPROVE_ALL and instead returning the legacy value manually:
.setOnPermissionRequest((_, _) ->
CompletableFuture.completedFuture(
new PermissionRequestResult()
.setKind(new PermissionRequestResultKind("approved"))
)
)That keeps the flow working on my side.
Versions
copilot-sdk-java:0.3.0-java.2
Relevant log output
Code of Conduct
- I agree to follow this project's Code of Conduct
Activity
brunoborges commentedon Apr 27, 2026
This is confirmed as a known issue. The root cause is in the upstream reference implementation (github/copilot-sdk): commit
dd2dcbcchanged the permission kind values but the test harness CLI (v1.0.32) doesn't support the new values yet.Tracked upstream: github/copilot-sdk#1146
Your workaround of manually sending
"approved"is correct for now.brunoborges commentedon Apr 27, 2026
Update: Confirmed that no released CLI version (up to v1.0.36) supports the new permission kind values. This is tracked upstream in github/copilot-sdk#1146 — the fix needs to come from the CLI side.
In the meantime, the workaround of manually sending the old
"approved"string remains the correct approach.edburns commentedon Apr 27, 2026
FWIW, my copilot analysis, which corroborates @brunoborges 's analysis.
Q2: What is this current failure about?
15 test failures (12 Failures + 3 Errors), matching exactly what issue #1146 describes:
Root cause: Reference implementation commit
dd2dcbcmade two breaking protocol changes that require an unreleased CLI version:New permission kind values: The SDK now sends
approve-once,reject,user-not-available(replacing the oldapproved,denied-*strings). CLI v1.0.32 responds withUnhandled permission result kind: [object Object], causing all tool invocations to fail with permission errors — hence the 12 tool/permission test failures.New RPC method
session.auth.getStatus: Not implemented in CLI v1.0.32, causingJsonRpcException: Unhandled method session.auth.getStatus— hence the 3PerSessionAuthTesterrors.Additionally, there's a generated code mismatch: the generated
PermissionCompletedKindenum (from the@github/copilot@1.0.32schema) only contains old values (approved,denied-by-rules, etc.), and throwsIllegalArgumentException: Unknown PermissionCompletedKind value: approve-oncewhen trying to deserialize the new values.edburns commentedon Apr 30, 2026
I attribute this problem to an ordering problem regarding the agentic workflow sync. This problem has been resolved in #137 and related PRs.