fix: project-level permissions to work around config priority bug

[terisuke]

Summary

• Sets comprehensive permission rules at project-level .opencode/opencode.jsonc to work around config priority bug (bug: user-level permission config overridden by project-level config with missing rules #31)
• User-level config (~/.config/opencode/opencode.jsonc) has lower priority than project-level, so permission rules set there are ineffective when project config exists
• Also serves as documentation of the optimal permission config aligned with Claude Code's approval model

Fixes #31
Ref #32

Root Cause Investigation

Issue 1: Config Priority (#31)

• Config hierarchy: System > Project > User (user is lowest priority)
• Permission.fromConfig(cfg.permission) in agent.ts:102 receives already-merged config
• When project config has a permission key, it overrides user-level permission entirely
• Fix: Set permissions at project-level until upstream fixes config merge behavior

Issue 2: Team Gate (#32)

• team.ts:470 hardcodes tasks.length < 2 check
• big() function over-triggers on verbose investigation requests
• Not addressed in this PR — requires code changes

Issue 3: findLast() Evaluation (#31)

• evaluate.ts:10 uses findLast() — last matching rule wins regardless of specificity
• Rule ordering in flattened array determines behavior
• Not addressed in this PR — requires upstream evaluation logic changes

Test plan

• Start OpenCode TUI in this repo
• Verify read operations proceed without prompts
• Verify supabase *, bun *, git * bash commands auto-approve
• Verify rm -rf, sudo are blocked
• Verify .env file access is denied

🤖 Generated with Claude Code

[github-actions]

This PR doesn't fully meet our contributing guidelines and PR template.

What needs to be fixed:

• PR description is missing required template sections. Please use the PR template.

Please edit this PR description to address the above within 2 hours, or it will be automatically closed.

If you believe this was flagged incorrectly, please let a maintainer know.

[Copilot]

Pull request overview

Updates the repository’s project-level OpenCode configuration to define an explicit, comprehensive permission ruleset in .opencode/opencode.jsonc, intended to work around the config priority/merge behavior described in issue #31.

Changes:

• Add project-level default read/edit/tool permissions (including .env and migration path restrictions).
• Define a detailed bash allowlist with a default ask, plus explicit deny rules for a few dangerous commands.
• Enable several non-bash tools (glob, grep, list, webfetch, websearch, etc.) by default.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The goal/test plan says “.env file access is denied”, but bash is configured to allow cat * / head * / tail * without prompting. The bash tool does not consult read permissions for files referenced in shell commands, so cat .env (and similar) will still be auto-approved. To actually block .env reads, add explicit bash deny rules that match .env paths (e.g., deny cat *.env*, head *.env*, tail *.env*, etc.), or change these commands back to ask/deny.

[Copilot]

grep is set to allow, but the grep tool’s permission check is only against the search pattern (not the files searched) and it runs ripgrep across the repo (including hidden files). That means secrets in .env can still be discovered via grep even though read denies .env. If the intent is “.env access is denied”, consider setting grep back to ask/deny (or narrowing it), since the permission model can’t currently restrict grep by filepath.

Suggested change

	"grep": "allow",
	"grep": "ask",

[Copilot]

The deny rules for curl | sh / curl | bash rely on spaces around the pipe ("curl * | sh*"). The bash permission patterns are matched against the raw command text, so variants like curl ...|sh, curl ...| bash, or extra whitespace won’t match and will fall back to the broader "curl *": "allow" rule. Add additional deny patterns that cover common spacing variants (or change curl * to ask).

Suggested change

	"curl * | sh*": "deny",
	"curl * | bash*": "deny",
	"curl * | sh*": "deny",
	"curl *| sh*": "deny",
	"curl * |sh*": "deny",
	"curl *|sh*": "deny",
	"curl * | bash*": "deny",
	"curl *| bash*": "deny",
	"curl * |bash*": "deny",
	"curl *|bash*": "deny",

[Copilot]

pwd is allowed only as an exact match ("pwd"). The bash tool requests permissions against the full command string, so pwd -P / pwd -L will still prompt even though the intent seems to be allowing basic shell utilities. Consider changing this to a wildcard form (e.g., pwd *) for consistency with other entries like ls */cat *.

Suggested change

	"pwd": "allow",
	"pwd *": "allow",

[terisuke]

Closing for now because the workaround is superseded by the broader permission-defaults merge in #30, and the original #31 repro needs a fresh minimal reproduction before we lock in a workaround on dev.