feat: add tool_use_id and blocked_path to ToolPermissionContext #459
Conversation
Add tool_use_id and blocked_path fields to ToolPermissionContext to match the TypeScript SDK's CanUseTool callback signature. This allows permission callbacks to know which specific tool call is being authorized, enabling proper tracking and UI correlation (e.g., for ACP permission dialogs that need to reference the tool call). Changes: - Add tool_use_id (required) and blocked_path (optional) to ToolPermissionContext - Add tool_use_id to SDKControlPermissionRequest TypedDict - Update _handle_control_request to pass these fields to the callback
There was a problem hiding this comment.
Pull request overview
This pull request adds tool_use_id and blocked_path fields to the ToolPermissionContext to align with the TypeScript SDK's CanUseTool callback signature. This enhancement enables permission callbacks to identify specific tool calls for better tracking and UI correlation, particularly for features like ACP permission dialogs that need to reference individual tool calls.
Key changes:
- Added
tool_use_id(required) andblocked_path(optional) fields toToolPermissionContextdataclass with comprehensive documentation - Updated
SDKControlPermissionRequestTypedDict to includetool_use_idas a required field - Modified
_handle_control_requestto pass these new fields from the CLI request to the callback context
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/claude_agent_sdk/types.py | Added tool_use_id (required) and blocked_path (optional) fields to ToolPermissionContext dataclass and SDKControlPermissionRequest TypedDict with detailed docstring documentation |
| src/claude_agent_sdk/_internal/query.py | Updated _handle_control_request to extract and pass tool_use_id and blocked_path from permission requests to the ToolPermissionContext |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| raise Exception("canUseTool callback is not provided") | ||
|
|
||
| context = ToolPermissionContext( | ||
| tool_use_id=permission_request.get("tool_use_id", ""), |
There was a problem hiding this comment.
The tool_use_id field is marked as required (not optional) in the SDKControlPermissionRequest TypedDict, but here it's being accessed with .get() and defaulting to an empty string. This creates a mismatch: if the CLI fails to send tool_use_id, the code will silently use an empty string instead of failing fast with a clear error. Either:
- Change the TypedDict to make tool_use_id optional (tool_use_id: NotRequired[str]), or
- Access it directly without .get() since it's required: tool_use_id=permission_request["tool_use_id"]
Given that the PR description states this field is needed "to know which specific tool call is being authorized", option 2 (making it truly required) seems more appropriate.
| tool_use_id=permission_request.get("tool_use_id", ""), | |
| tool_use_id=permission_request["tool_use_id"], |
1 participant
Add tool_use_id and blocked_path fields to ToolPermissionContext to match the TypeScript SDK's CanUseTool callback signature.
This allows permission callbacks to know which specific tool call is being authorized, enabling proper tracking and UI correlation (e.g., for ACP permission dialogs that need to reference the tool call).
Changes: