Activity

1. JtMotoX

   added

   discussionUsed for feature requests, proposals, ideas, etc. Open discussionUsed for feature requests, proposals, ideas, etc. Open discussion

   on Jan 31, 2026
2. github-actions

   assigned

   thdxr

   on Jan 31, 2026
3. github-actions commented on Jan 31, 2026

   

   github-actionsBot

   on Jan 31, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [FEATURE]: more general external_directory permissions #4991: [FEATURE]: more general external_directory permissions - Proposes more sophisticated pattern matching for permissions using regex or patterns
   • [FEATURE]: edit/write permission with deny,allow,ask using glob #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.
4. broboa commented on Feb 2, 2026

   

   broboa

   on Feb 2, 2026

   More actions

   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.

   👍React with 👍1Reacted by JtMotoX
5. JtMotoX commented on Feb 3, 2026

   

   JtMotoX

   on Feb 3, 2026

   Author

   More actions

   Created PR #11908

   🎉React with 🎉7Reacted by broboa, Manuel Olguín Muñoz, Ph.D., Maximilian von Teuffenbach, Raphael David François, purefkh, Clément Nerma and Aaron Friesen
6. github-actions commented on Apr 5, 2026

   

   github-actionsBot

   on Apr 5, 2026 – with GitHub Actions

   Contributor

   More actions

   To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.
7. github-actions

   closed this as completedon Apr 5, 2026
8. NicolasWebDev commented on Jun 16, 2026

   

   NicolasWebDev

   on Jun 16, 2026

   More actions

   I understand @JtMotoX that the PR was never merged, right?

   👍React with 👍1Reacted by Mohamed Hafdi Idrissi