[FEATURE] `canUseTool` callback provides `tool_use_id`

Resolved 💬 2 comments Opened Sep 16, 2025 by benbrandt Closed Nov 4, 2025

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

The canUseTool callback is a huge improvement over the permissionToolName!

However, it is missing one key piece of information for us to migrate over: a tool_use_id.

If we had this, we should be able to migrate to this completely and not have to spawn a separate HTTP MCP server just for this

(Note: it appears you can't use an SDK MCP server for this, because it goes into a different map, so the check for the permission name fails)

Proposed Solution

To make it a non-breaking change, add the tool_use_id as a third parameter to canUseTool.

Alternative Solutions

If, for whatever reason, that isn't an easy fix, it would be amazing if the permission tool could be passed via an SDK MCP server instead of an HTTP one 🙏🏻

Priority

Medium - Would be very helpful

Feature Category

Developer tools/SDK

Use Case Example

We're using this in our Zed integration: https://github.com/zed-industries/claude-code-acp/blob/main/src/mcp-server.ts#L649
So we need to know which tool call that is currently rendered needs to be updated with a permission prompt

Additional Context

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗