anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-21 17:56:33 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[FEATURE]: Support regex in permissions configuration #8094

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

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

Feature Request: Regex Support for Permissions Configuration

Summary

Permissions currently support only simple wildcards. Adding regex support would reduce repetitive rules and prevent unnecessary permission prompts, especially when the LLM varies argument order.

Problems

  • Repetition: Git commands require many separate wildcard entries.
  • Argument reordering: Commands like kubectl -n default get ... still trigger approval request even when kubectl get * is allowed. In my vscode copilot extension, I have a regex that takes care of this, so any - or -- arguments are completely ignored, while allowing the regex (get|describe|config|logs|api-resources|explain|cluster-info|top|debug|events|diff). This allows commands like kubectl -n myns -o json get pod mypod to run without asking for approval. My entire kubectl configuration is a single line regex in my vscode copilot configuration.

Git Example

Current:

"git": "ask",
"git branch *": "allow",
"git diff *": "allow",
"git log *": "allow",
"git shortlog *": "allow",
"git show *": "allow",
"git status *": "allow",
"git remote -v": "allow",

Desired Example (basically what I currently have configured in my vscode copilot extension):

"git": "ask",
"/^git (branch|diff|log|shortlog|show|status|(remote -v))/": "allow",
Originally created by @JtMotoX on GitHub (Jan 30, 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 # Feature Request: Regex Support for Permissions Configuration ### Summary Permissions currently support only simple wildcards. Adding **regex support** would reduce repetitive rules and prevent unnecessary permission prompts, especially when the LLM varies argument order. --- ### Problems - **Repetition**: Git commands require many separate wildcard entries. - **Argument reordering**: Commands like `kubectl -n default get ...` still trigger approval request even when `kubectl get *` is allowed. In my vscode copilot extension, I have a regex that takes care of this, so any `-` or `--` arguments are completely ignored, while allowing the regex `(get|describe|config|logs|api-resources|explain|cluster-info|top|debug|events|diff)`. This allows commands like `kubectl -n myns -o json get pod mypod` to run without asking for approval. My entire kubectl configuration is a single line regex in my vscode copilot configuration. --- ### Git Example **Current:** ``` "git": "ask", "git branch *": "allow", "git diff *": "allow", "git log *": "allow", "git shortlog *": "allow", "git show *": "allow", "git status *": "allow", "git remote -v": "allow", ``` **Desired Example (basically what I currently have configured in my vscode copilot extension):** ``` "git": "ask", "/^git (branch|diff|log|shortlog|show|status|(remote -v))/": "allow", ```
yindo added the discussion label 2026-02-16 18:09:09 -05:00
yindo commented 2026-02-16 18:09:09 -05:00
Author
Owner
Copy Link
Copy Source

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

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

  • #4991: [FEATURE]: more general external_directory permissions - Proposes more sophisticated pattern matching for permissions using regex or patterns
  • #4287: [FEATURE]: edit/write permission with deny,allow,ask using glob - Explicitly requests glob/pattern matching for permissions to replace simple wildcard matching

Both issues share the core problem: simple wildcard patterns are insufficient for complex permission rules. Your regex approach would directly address these limitations.

Feel free to ignore if your use case differs from these existing requests.

@github-actions[bot] commented on GitHub (Jan 30, 2026): This issue might be a duplicate of existing issues. Please check: - #4991: [FEATURE]: more general external_directory permissions - Proposes more sophisticated pattern matching for permissions using regex or patterns - #4287: [FEATURE]: edit/write permission with deny,allow,ask using glob - Explicitly requests glob/pattern matching for permissions to replace simple wildcard matching Both issues share the core problem: simple wildcard patterns are insufficient for complex permission rules. Your regex approach would directly address these limitations. Feel free to ignore if your use case differs from these existing requests.
yindo commented 2026-02-16 18:09:09 -05:00
Author
Owner
Copy Link
Copy Source

@broboa commented on GitHub (Feb 2, 2026):

Confirming this is somewhat of a blocker when migrating from Kiro to OpenCode. Regex expressions in Kiro's permissions configuration provide both reduced rule verbosity and maintained security without trading off either.

Migration Pain Points

When converting a Kiro configuration with regex-based permissions to OpenCode wildcards, the constraints are stark:

  1. Security regression: Wildcards (*, ?) cannot express the safety constraints that regex enforces. A pattern like "*git commit*--no-gpg-sign*" to deny unsafe git operations becomes impossible to express safely—wildcards would match arbitrary prefixes and allow shell injection vectors.

  2. Argument position sensitivity: Commands with flags in any position (e.g., kubectl -n ns get pods vs kubectl get -n ns pods) require separate wildcard rules. Regex handles this trivially with optional argument groups; wildcards force explicit enumeration or dangerous blanket permissions.

  3. Pipe chain control: Regex can enforce that piping is only allowed to specific safe commands (head, grep, jq, etc.). Wildcards cannot distinguish between kubectl get | grep (safe) and kubectl get | xargs rm -rf (dangerous).

Example: kubectl Configuration

Kiro (single regex):

"^(export\\s+KUBECONFIG=[^;&>`$]+\\s+&&\\s+)?kubectl\\s+(get|describe|logs|top|explain|version|cluster-info)(\\s+[^;&>`$]*)?( \\| (head|tail|grep|wc|sort|uniq|cut|awk|less|more|column|jq|yq)(\\s+[^;&>`$]*)?)*$": "allow"

OpenCode wildcards (requires ~30+ rules or accepts security degradation):

"kubectl get*": "allow"
"kubectl describe*": "allow"
... (compromised: allows arbitrary arguments, pipes, and flags in any order)

Regex support would eliminate this migration friction and restore the security model that made Kiro configurations maintainable.

@broboa commented on GitHub (Feb 2, 2026): Confirming this is somewhat of a blocker when migrating from Kiro to OpenCode. Regex expressions in Kiro's permissions configuration provide both reduced rule verbosity and maintained security without trading off either. ## Migration Pain Points When converting a Kiro configuration with regex-based permissions to OpenCode wildcards, the constraints are stark: 1. **Security regression**: Wildcards (`*`, `?`) cannot express the safety constraints that regex enforces. A pattern like `"*git commit*--no-gpg-sign*"` to deny unsafe git operations becomes impossible to express safely—wildcards would match arbitrary prefixes and allow shell injection vectors. 2. **Argument position sensitivity**: Commands with flags in any position (e.g., `kubectl -n ns get pods` vs `kubectl get -n ns pods`) require separate wildcard rules. Regex handles this trivially with optional argument groups; wildcards force explicit enumeration or dangerous blanket permissions. 3. **Pipe chain control**: Regex can enforce that piping is only allowed to specific safe commands (head, grep, jq, etc.). Wildcards cannot distinguish between `kubectl get | grep` (safe) and `kubectl get | xargs rm -rf` (dangerous). ## Example: kubectl Configuration **Kiro (single regex)**: ``` "^(export\\s+KUBECONFIG=[^;&>`$]+\\s+&&\\s+)?kubectl\\s+(get|describe|logs|top|explain|version|cluster-info)(\\s+[^;&>`$]*)?( \\| (head|tail|grep|wc|sort|uniq|cut|awk|less|more|column|jq|yq)(\\s+[^;&>`$]*)?)*$": "allow" ``` **OpenCode wildcards (requires ~30+ rules or accepts security degradation)**: ``` "kubectl get*": "allow" "kubectl describe*": "allow" ... (compromised: allows arbitrary arguments, pipes, and flags in any order) ``` Regex support would eliminate this migration friction and restore the security model that made Kiro configurations maintainable.
yindo commented 2026-02-16 18:09:09 -05:00
Author
Owner
Copy Link
Copy Source

@JtMotoX commented on GitHub (Feb 3, 2026):

Created PR https://github.com/anomalyco/opencode/pull/11908

@JtMotoX commented on GitHub (Feb 3, 2026): Created PR https://github.com/anomalyco/opencode/pull/11908
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#8094
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?