humaisali What I do
- Review and summarize currently always-allowed commands
- Suggest safe read-only commands for auto-approval
- Add or remove commands from the allow list in opencode.json
- Configure skill-level permissions (allow/deny/ask) with wildcard patterns
- Audit permission configs for security and usability
When to Use
Use this when optimizing opencode's permission settings, reviewing allowed commands, or configuring skill access controls.
Workflow Steps
- Read current config: Load
~/.config/opencode/opencode.jsonor project-levelopencode.json - Summarize permissions: Identify currently allowed commands and skill permissions
- Suggest additions: Propose safe read-only commands for auto-allow (see recommended list below)
- Apply changes: Edit the config to add/remove permission entries
- Validate: Ensure JSON is valid after changes
Complements opencode's built-in allow/deny/ask permissions by auditing current config and recommending adjustments through conversation.
Key Rules
- Never allow commands that modify files, commit, push, or change system state
- Prefer exact command entries such as
git status --short,git diff --stat, andls -la - Avoid trailing wildcards such as
git status*unless the expanded command family has been manually reviewed as read-only - Confirm with user before modifying permission config
- Distinguish between bash command permissions and skill permissions
- Keep config organized: group related commands together
Limitations
- This skill is scoped to opencode permission configuration and should not modify other agent hosts' permission stores.
- Treat all write-capable command permissions as high-risk; review them manually even when a pattern looks narrow.
How to trigger me
Use the Task tool with the permission-manager subagent type:
/permissions
Or in natural language, ask opencode to "manage opencode permissions" or "review allowed commands".