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]: Allow skills and commands to define scoped permission overrides #4471

New Issue
Open
opened 2026-02-16 17:43:53 -05:00 by yindo · 2 comments
yindo commented 2026-02-16 17:43:53 -05:00
Owner
Copy Link
Copy Source

Originally created by @rcdailey on GitHub (Jan 8, 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

Problem:
When creating skills or commands that need specific tool permissions (e.g., a /commit command that needs git commit and git add), there's no way to scope those permissions to the skill/command invocation. Users must either:

  1. Globally allow those commands (reducing safety)
  2. Keep them as ask and manually approve every time the skill/command runs

Proposed solution:
Allow skills and commands to define permission overrides in their frontmatter that apply only during their execution:

For skills (SKILL.md):

---
name: git-commit
description: Commit workflow with conventional commits
permission:
  bash:
    "git add *": allow
    "git commit *": allow
---

For commands (.opencode/command/commit.md):

---
description: Run commit workflow
permission:
  bash:
    "git add *": allow
    "git commit *": allow
---

Behavior:

  • Permission overrides apply only while the skill is loaded or command is executing
  • Overrides merge with (and take precedence over) global/agent permissions for the duration
  • After skill/command completes, permissions revert to normal
  • Optional: require user confirmation when a skill/command requests elevated permissions (similar to ask but at skill-load time rather than per-command)

Benefits:

  • Enables safe, targeted permission elevation for specific workflows
  • Reduces friction for trusted operations without globally loosening security
  • Aligns with principle of least privilege

Use cases:

  • Git commit workflows that need git add/git commit
  • Release scripts that need gh release create
  • Build commands that need specific npm/cargo/make invocations
Originally created by @rcdailey on GitHub (Jan 8, 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 **Problem:** When creating skills or commands that need specific tool permissions (e.g., a `/commit` command that needs `git commit` and `git add`), there's no way to scope those permissions to the skill/command invocation. Users must either: 1. Globally allow those commands (reducing safety) 2. Keep them as `ask` and manually approve every time the skill/command runs **Proposed solution:** Allow skills and commands to define permission overrides in their frontmatter that apply only during their execution: **For skills (`SKILL.md`):** ```yaml --- name: git-commit description: Commit workflow with conventional commits permission: bash: "git add *": allow "git commit *": allow --- ``` **For commands (`.opencode/command/commit.md`):** ```yaml --- description: Run commit workflow permission: bash: "git add *": allow "git commit *": allow --- ``` **Behavior:** - Permission overrides apply only while the skill is loaded or command is executing - Overrides merge with (and take precedence over) global/agent permissions for the duration - After skill/command completes, permissions revert to normal - Optional: require user confirmation when a skill/command requests elevated permissions (similar to `ask` but at skill-load time rather than per-command) **Benefits:** - Enables safe, targeted permission elevation for specific workflows - Reduces friction for trusted operations without globally loosening security - Aligns with principle of least privilege **Use cases:** - Git commit workflows that need `git add`/`git commit` - Release scripts that need `gh release create` - Build commands that need specific npm/cargo/make invocations
yindo commented 2026-02-16 17:43:53 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 8, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #7296: [FEATURE]: Allow configurable subagent-to-subagent task delegation with call limits
  • #7362: [FEATURE]: Tool call descriptions as skills
  • #7399: [FEATURE]: Filter which tools are loaded from MCP servers (includeTools/excludeTools)

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Jan 8, 2026): This issue might be a duplicate of existing issues. Please check: - #7296: [FEATURE]: Allow configurable subagent-to-subagent task delegation with call limits - #7362: [FEATURE]: Tool call descriptions as skills - #7399: [FEATURE]: Filter which tools are loaded from MCP servers (includeTools/excludeTools) Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:43:53 -05:00
Author
Owner
Copy Link
Copy Source

@einarpersson commented on GitHub (Jan 10, 2026):

What i would like is that tools would not even be visible for an agent until a skill has been loaded.

If i have a skill "calendar/SKILL.md" then i would want that loading it would both give new prompt context AND availablity to tools. I guess this is what this Feature Request is about, but i'd like to emphasis that it should be possible to "load a skill on demand and then suddenly see new tools that it wasnt aware of before".

Question regarding this feature request: why would the permissions be revoked after a skill has been loaded? It makes sense for a command but not for a skill. Once an agent has loaded a skill surely it should keep everything related around? or?

@einarpersson commented on GitHub (Jan 10, 2026): What i would like is that tools would not even be visible for an agent until a skill has been loaded. If i have a skill "calendar/SKILL.md" then i would want that loading it would both give new prompt context AND availablity to tools. I guess this is what this Feature Request is about, but i'd like to emphasis that it should be possible to "load a skill on demand and then suddenly see new tools that it wasnt aware of before". Question regarding this feature request: why would the permissions be revoked after a skill has been loaded? It makes sense for a command but not for a skill. Once an agent has loaded a skill surely it should keep everything related around? or?
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
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#4471
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?