anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[FEATURE]: Granular permission pattern matching for MCP tools #8638

New Issue
Open
opened 2026-02-16 18:10:28 -05:00 by yindo · 1 comment
yindo commented 2026-02-16 18:10:28 -05:00
Owner
Copy Link
Copy Source

Originally created by @karlkurzer on GitHub (Feb 5, 2026).

Originally assigned to: @thdxr on GitHub.

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Describe the enhancement you want to request

Problem

Granular permission rules (object syntax) documented at https://opencode.ai/docs/permissions/#granular-rules-object-syntax don't work for MCP tools. Pattern matching only applies to built-in tools (bash, edit, read, etc.).
Many MCP tools bundle multiple operations behind a single tool name (e.g., outlook_calendar_meeting with operation=create|read|update|delete). There's no way to allow read-only operations while requiring approval for mutations.
Tested patterns (none matched)

The permission prompt shows MCP tool input as:
outlook_calendar_meeting operation=read, meetingId=AAMk..., meetingChangeKey=DwAA...
Patterns tried in opencode.jsonc — none bypassed the prompt:

"outlook_calendar_meeting": {
  "*": "ask",
  "operation=read*": "allow",
  "*operation=read*": "allow",
  "*\"operation\":\"read\"*": "allow",
  "[operation=read*": "allow"
}

Root cause

As identified in #12111, MCP tools fall through to a generic case in permission.tsx (line 262-264) that doesn't run the input() data through pattern matching the way built-in tools do.
Expected behavior
Granular permission patterns should work for MCP tools the same way they work for built-in tools. Using the displayed format [key=value, ...] as the match string would be consistent:
outlook_calendar_meeting: { *: ask, *operation=read*: allow }

Use case

MCP servers like Outlook, Slack, or database tools often expose a single tool with CRUD operations. Users need to:

  • Allow read operations (calendar reads, email inbox) without prompts
  • Ask for write operations (sending emails, creating meetings)
  • Deny destructive operations (deleting events)

Possible approach

The input() memo in permission.tsx (lines 128-138) already holds the MCP tool parameters. The fix would involve serializing those parameters into a matchable string (e.g., the same key=value, ... format shown in the prompt) and running it through the existing pattern matching logic that built-in tools already use. This could potentially be addressed alongside #12111 since both touch the same MCP fallback path.

Related

  • #12111 — Display MCP tool parameters in permission dialog
Originally created by @karlkurzer on GitHub (Feb 5, 2026). Originally assigned to: @thdxr on GitHub. ### Feature hasn't been suggested before. - [x] I have verified this feature I'm about to request hasn't been suggested before. ### Describe the enhancement you want to request ### Describe the enhancement you want to request #### Problem Granular permission rules (object syntax) documented at https://opencode.ai/docs/permissions/#granular-rules-object-syntax don't work for MCP tools. Pattern matching only applies to built-in tools (`bash`, `edit`, `read`, etc.). Many MCP tools bundle multiple operations behind a single tool name (e.g., `outlook_calendar_meeting` with `operation=create|read|update|delete`). There's no way to allow read-only operations while requiring approval for mutations. Tested patterns (none matched) The permission prompt shows MCP tool input as: outlook_calendar_meeting operation=read, meetingId=AAMk..., meetingChangeKey=DwAA... Patterns tried in `opencode.jsonc` — none bypassed the prompt: ```json "outlook_calendar_meeting": { "*": "ask", "operation=read*": "allow", "*operation=read*": "allow", "*\"operation\":\"read\"*": "allow", "[operation=read*": "allow" } ``` #### Root cause As identified in #12111, MCP tools fall through to a generic case in permission.tsx (line 262-264) that doesn't run the input() data through pattern matching the way built-in tools do. Expected behavior Granular permission patterns should work for MCP tools the same way they work for built-in tools. Using the displayed format [key=value, ...] as the match string would be consistent: ` outlook_calendar_meeting: { *: ask, *operation=read*: allow }` #### Use case MCP servers like Outlook, Slack, or database tools often expose a single tool with CRUD operations. Users need to: - Allow read operations (calendar reads, email inbox) without prompts - Ask for write operations (sending emails, creating meetings) - Deny destructive operations (deleting events) #### Possible approach The input() memo in permission.tsx (lines 128-138) already holds the MCP tool parameters. The fix would involve serializing those parameters into a matchable string (e.g., the same key=value, ... format shown in the prompt) and running it through the existing pattern matching logic that built-in tools already use. This could potentially be addressed alongside #12111 since both touch the same MCP fallback path. #### Related - #12111 — Display MCP tool parameters in permission dialog
yindo added the discussion label 2026-02-16 18:10:28 -05:00
yindo commented 2026-02-16 18:10:28 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Feb 5, 2026):

This issue might be related to existing issues. Please check:

  • #12111: Display MCP Tool Parameters in Permission Dialog (prerequisite for implementing this feature)
  • #6892: MCP tool permissions not working after migration from tools to permissions (baseline MCP permission support)
  • #11397: Support regex in permissions configuration (broader pattern matching enhancement)

This feature builds upon the improvements proposed in these issues, particularly #12111 which needs to be addressed first to display the tool parameters that would be matched against the patterns.

@github-actions[bot] commented on GitHub (Feb 5, 2026): This issue might be related to existing issues. Please check: - #12111: Display MCP Tool Parameters in Permission Dialog (prerequisite for implementing this feature) - #6892: MCP tool permissions not working after migration from tools to permissions (baseline MCP permission support) - #11397: Support regex in permissions configuration (broader pattern matching enhancement) This feature builds upon the improvements proposed in these issues, particularly #12111 which needs to be addressed first to display the tool parameters that would be matched against the patterns.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label discussion
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#8638
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?