Rust external session + MCP tools fail with 'Unhandled permission result kind: [object Object]'

[cay7man]

Summary

Using the Rust SDK against an external headless Copilot CLI, MCP tools can connect and be invoked, but the runtime fails during the permission flow with:

Unhandled permission result kind: [object Object]

I can reproduce this with a read-only MCP server tool (readOnlyHint: true) over an external/TCP session.

Environment

• SDK: github-copilot-sdk = "0.1" (Rust)
• Client OS: Windows
• Transport: external TCP connection to a Linux headless Copilot CLI server
• Model: gpt-5.4
• MCP server type: local/stdio on the Linux host

Repro shape

Rust session config includes:

• with_transport(Transport::External { host, port })
• with_mcp_servers(...)
• with_env_value_mode("direct")
• with_streaming(true)
• with_request_permission(false)

The MCP server exposes two tools:

• search_markdown
• read_markdown_file

Both are advertised with MCP annotations like:

"annotations": {
  "title": "Search Markdown",
  "readOnlyHint": true
}

The server is healthy:

• initialize works
• tools/list works
• the SDK reports the server as connected

Observed behavior

The MCP server connects successfully:

[session.mcp_server_status_changed] {"serverName":"search-md","status":"connected"}
[session.mcp_servers_loaded] {"servers":[{"name":"search-md","status":"connected"}]}

The model then invokes the MCP tool:

[tool.execution_start] {"arguments":{"max_matches":10,"query":"IPF"},"mcpServerName":"search-md","mcpToolName":"search_markdown","toolName":"search-md-search_markdown"}

The runtime still requests permission even though the MCP tool is marked read-only:

[permission.requested] {"permissionRequest":{"args":{"max_matches":10,"query":"IPF"},"kind":"mcp","readOnly":true,"serverName":"search-md","toolName":"search-md-search_markdown","toolTitle":"Search Markdown"},"requestId":"50439ba3-35a3-4cb5-8f96-bdba2e229a79"}

Then it reports a reject result and immediately fails with the permission-kind error:

[permission.completed] {"requestId":"50439ba3-35a3-4cb5-8f96-bdba2e229a79","result":{"kind":"reject"}}
[tool.execution_complete] {"error":{"code":"failure","message":"Unhandled permission result kind: [object Object]"},"success":false,"toolName":"search-md-search_markdown"}

The same happens for read_markdown_file:

[permission.requested] {"permissionRequest":{"args":{"end_line":120,"max_lines":120,"path":"685592_IPF_Client_UG_Rev9p0.md","start_line":1},"kind":"mcp","readOnly":true,"serverName":"search-md","toolName":"search-md-read_markdown_file"}}
[permission.completed] {"result":{"kind":"reject"}}
[tool.execution_complete] {"error":{"code":"failure","message":"Unhandled permission result kind: [object Object]"}}

Expected behavior

One of these should happen:

1. read-only MCP tools should not go through a broken permission round-trip here, or
2. if permission is still required, the runtime should handle the permission result without crashing the tool call.

Notes

• This looks similar in symptom to the previously reported permission-result issues such as PermissionDecision polymorphic base instantiation in ExecutePermissionAndRespondAsync produces empty JSON, breaks built-in tool permission flow #1194 / PermissionDecision polymorphic base instantiation still produces empty JSON for Approved and UserNotAvailable paths — follow-up to #1194 #1403, although this repro is from the Rust SDK with MCP tools over an external headless CLI.
• I also previously saw a very similar failure shape with client-defined custom tools, but this issue is specifically about the MCP path.

If helpful, I can provide a minimal Rust repro plus the tiny Python MCP server used for search_markdown / read_markdown_file.

[github-actions]

Investigation findings

Thanks for the detailed report. I investigated the relevant Rust SDK source and the symptom points to a real bug — labelling this accordingly.

What I looked at

• rust/src/permission.rs — policy helpers (approve_all, deny_all, approve_if)
• rust/src/handler.rs — PermissionResult / PermissionHandler trait definitions
• rust/src/session.rs — notification_permission_payload() and handle_notification() permission dispatch path
• rust/src/generated/api_types.rs — PermissionDecision / PermissionDecisionReject wire types
• rust/src/wire.rs — SessionCreateWire / SessionResumeWire to confirm how request_permission flag is set

What I found

The crash is in the Copilot CLI runtime (JavaScript), not in the Rust SDK itself. The tell-tale sign is the string [object Object] in the error message — that is a JavaScript string-coercion artefact that only appears when a JS object is interpolated into a template literal without being serialised first (e.g. `Unhandled permission result kind: ${result}` where result is the full {kind:"reject"} object rather than just result.kind). The CLI runtime's MCP permission-result handler appears to have a defect in how it accesses the kind discriminant of incoming handlePendingPermissionRequest payloads.

The Rust SDK is doing the right thing: notification_permission_payload() correctly serialises PermissionResult::reject(None) as {"kind":"reject"}, and the unit tests in session.rs verify this. The permission.completed log in the issue confirms the SDK's message was delivered correctly — the runtime just fails to act on it.

Secondary note — with_request_permission(false): The Rust SDK does not expose a with_request_permission() method. The wire flag requestPermission is derived automatically from whether a PermissionHandler / permission policy is attached to the SessionConfig. To suppress permission requests entirely, simply don't call with_permission_handler(...) or any of the approve_*/deny_* policy builders — the SDK will then send requestPermission: false on the wire. The fact that permission.requested fired suggests a handler or policy was active (or that the runtime is routing the request through the permission channel regardless of that flag for MCP tools, which would be a separate runtime-side defect worth noting).

Root cause summary

The CLI runtime's handler for session.permissions.handlePendingPermissionRequest results has a JavaScript bug in the MCP tool code path: it fails to extract the kind field from the incoming result object and instead coerces the whole object to a string, producing [object Object]. This causes every MCP tool invocation that goes through a permission round-trip to fail with code: "failure", regardless of whether the SDK approved or rejected.

Generated by Bug Handler for issue #1440 · ● 8.9M · ◷

[Ram9199]

@cay7man this failure mode is a good example of why MCP permission results need a stable typed contract across SDK/runtime boundaries.

Even for read-only MCP tools, the permission flow should probably preserve:

• kind: mcp
• serverName / toolName
• readOnly hint and source
• decision: allow / deny / ask / error
• reason/error code when the runtime cannot interpret the permission result

If the SDK sees an unknown permission result object, failing with Unhandled permission result kind: [object Object] makes integration hard to diagnose and audit. We have been modeling this as a stable PolicyDecision + AuditRecord boundary in Agent_Sudo: https://github.com/Kisyntra/Agent_Sudo

[roji]

Closing as this can only be reproduced by mixing incompatible versions of the SDK and the runtime. We've had conversations internally about earlier fail-fast catching of such version mismatches; in any case, this is something that would need to be handled at the entire runtime/SDK level rather than for a specific API point like here.