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

[PR #12801] feat(opencode): mcp permission patterns #14378

New Issue
Open
opened 2026-02-16 18:19:10 -05:00 by yindo · 0 comments
yindo commented 2026-02-16 18:19:10 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/anomalyco/opencode/pull/12801

State: open
Merged: No

Summary

  • Serialize MCP tool arguments into a deterministic sorted key=value pattern string and use it for permission rule matching (instead of always "*")
  • Display MCP tool arguments in the TUI permission prompt so users can see what they're approving
  • Add PermissionNext.serialize() with 13 unit + integration tests

Problem

Granular permission rules didn't work for MCP tools. Pattern matching only applied to built-in tools (bash, edit, read, etc.) because MCP tools always passed patterns: ["*"] — making all user-defined patterns unmatchable.

Solution

Reuse the existing wildcard infrastructure by giving it something meaningful to match. MCP tool args are serialized into a sorted key=value, key=value string (e.g., meetingId=AAMk..., operation=read) and passed as the permission pattern. Users can now write:

"outlook_calendar_meeting": {
  "*": "ask",
  "*operation=read*": "allow",
  "*operation=delete*": "deny"
}

Zero changes to core permission evaluation (evaluate, ask, fromConfig, Wildcard.match). Fully backwards compatible — empty args falls back to ["*"].

Files changed

File Change
src/permission/next.ts Add PermissionNext.serialize()
src/session/prompt.ts Use serialized args as MCP permission pattern
src/cli/cmd/tui/routes/session/permission.tsx Display MCP tool args in permission prompt
test/permission/next.test.ts 8 serialize + 5 integration tests

Closes #12358

**Original Pull Request:** https://github.com/anomalyco/opencode/pull/12801 **State:** open **Merged:** No --- ### Summary - Serialize MCP tool arguments into a deterministic sorted key=value pattern string and use it for permission rule matching (instead of always "*") - Display MCP tool arguments in the TUI permission prompt so users can see what they're approving - Add PermissionNext.serialize() with 13 unit + integration tests ### Problem Granular permission rules didn't work for MCP tools. Pattern matching only applied to built-in tools (bash, edit, read, etc.) because MCP tools always passed patterns: ["*"] — making all user-defined patterns unmatchable. ### Solution Reuse the existing wildcard infrastructure by giving it something meaningful to match. MCP tool args are serialized into a sorted key=value, key=value string (e.g., meetingId=AAMk..., operation=read) and passed as the permission pattern. Users can now write: ```json "outlook_calendar_meeting": { "*": "ask", "*operation=read*": "allow", "*operation=delete*": "deny" } ``` Zero changes to core permission evaluation (evaluate, ask, fromConfig, Wildcard.match). Fully backwards compatible — empty args falls back to ["*"]. Files changed | File | Change | |------|--------| | src/permission/next.ts | Add PermissionNext.serialize() | | src/session/prompt.ts | Use serialized args as MCP permission pattern | | src/cli/cmd/tui/routes/session/permission.tsx | Display MCP tool args in permission prompt | | test/permission/next.test.ts | 8 serialize + 5 integration tests | Closes #12358
yindo added the pull-request label 2026-02-16 18:19:10 -05:00
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 pull-request
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#14378
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?