FIELD GUIDE

OpenCode: Configure Tool Permissions Before an Agent Sees the Repository

OpenCode is useful precisely because the developer can distinguish what the agent may read, edit and execute. That flexibility also creates a configuration risk: documented defaults can be permissive, so opening a sensitive checkout

OpenCode is useful precisely because the developer can distinguish what the agent may read, edit and execute. That flexibility also creates a configuration risk: documented defaults can be permissive, so opening a sensitive checkout before setting policy is not an adequate security review.

Capabilities and integration boundaries

OpenCode documents a permission configuration with three actions: allow, ask and deny. Rules cover read, edit, bash, web access, tasks, skills and access outside the working directory. Custom agents can carry their own permissions. The reference also documents that the older boolean tools configuration was superseded by a permission-based approach in newer releases; administrators need a version-aware migration.

A reproducible developer workflow

Make an audit-only agent whose edit permission is denied, network access is denied and terminal actions require confirmation. Use it to identify the narrowest place for a proposed bug fix. Then run a separate edit agent on a disposable branch with only required paths writable. Ask it to produce one regression test and one patch; reject unrelated dependency or CI changes.

Limitations and failure cases

A global allow rule is not equivalent to safe autonomy; neither is an ask rule a guarantee that every requested action is harmless. Broad command patterns can accept destructive arguments. Rules can also differ between agent and global configuration; a team must inspect the effective configuration, not just the first file located.

Data handling, approvals and security

Deny access outside the worktree unless justified, require approval for execution and network retrieval, block access to secrets and deployment credentials, and inspect subagent delegation. Pin installation versions during evaluation. Because repositories and tool outputs can contain malicious instructions, tool-call proposals should be judged against the human task rather than the model’s explanation.

Who should adopt it

OpenCode is a strong candidate when a team values inspectable agent permission rules and accepts responsibility for maintaining them. Treat documented features as product capabilities; this is not a claim that a custom permission scheme has been tested against attacks.

Alternatives and decision trade-offs

Compare Goose manual approval modes, Claude Code’s terminal permissions, and Codex sandbox profiles. Choose based on the controls your specific installed version can actually enforce.

Version, region and entitlement caveats

Research and first-party documentation checked on 25 October 2026 (cutoff date). Documented version or status scope: not version-pinned. The documentation does not independently establish availability in every country, an exact installed client release, a universal enterprise contract, or a perpetual price. No unverified seat price, request quota, API rate, model entitlement or commercial-license guarantee is supplied here. Check AI 10 dated pricing snapshots and the signed agreement before procurement. The examples are suggested evaluation methods, not experiments or benchmarks performed for this article.

Checklist before production rollout

  1. Record the exact installed version, service account, organization policy and contract or plan applicable to the tested environment.
  2. Create a clean worktree; specify the task boundary, forbidden paths, acceptance criteria and rollback before tool execution.
  3. Audit file, shell, network, extension and repository-app permissions; deny all unnecessary credentials and privileged actions.
  4. Review each resulting diff for unrequested packages, automation changes, data leaks and behavioral regressions.
  5. Run targeted tests, existing integration/regression tests and independent code/security review in a trusted environment.

Sources & Further Reading

CONTINUE EXPLORINGExplore related files ↗