[BUG]: 0.3.0-java.2: permission.completed cannot deserialize approve-once in PermissionCompletedKind

[bytehaufen]

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

1. Update to copilot-sdk-java:0.3.0-java.2
2. Use the normal permission approval flow, for example PermissionHandler.APPROVE_ALL
3. Trigger a tool call that requires permission
4. Observe the permission flow fail when the permission.completed event 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:

• approved
• approved-for-session
• approved-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

[brunoborges]

This is confirmed as a known issue. The root cause is in the upstream reference implementation (github/copilot-sdk): commit dd2dcbc changed 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]

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]

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 dd2dcbc made two breaking protocol changes that require an unreleased CLI version:

1. New permission kind values: The SDK now sends approve-once, reject, user-not-available (replacing the old approved, denied-* strings). CLI v1.0.32 responds with Unhandled permission result kind: [object Object], causing all tool invocations to fail with permission errors — hence the 12 tool/permission test failures.

2. New RPC method session.auth.getStatus: Not implemented in CLI v1.0.32, causing JsonRpcException: Unhandled method session.auth.getStatus — hence the 3 PerSessionAuthTest errors.

Additionally, there's a generated code mismatch: the generated PermissionCompletedKind enum (from the @github/copilot@1.0.32 schema) only contains old values (approved, denied-by-rules, etc.), and throws IllegalArgumentException: Unknown PermissionCompletedKind value: approve-once when trying to deserialize the new values.