Goal Mode is security-conscious software for an inherently risky job: letting an AI coding agent run tools in a real repository. Its guardrails are designed to reduce common failures, not to replace sandboxing, least-privilege credentials, or careful review of generated code.

• Completion claims are checked against recorded gate state instead of model confidence.
• Destructive shell patterns are analyzed with tokenization rather than raw regex matching.
• Installer writes are limited to Goal Mode agents, commands, plugins, sidebar config, and its manifest.
• Vulnerability reports are handled privately first so bypasses can be fixed responsibly.

Goal Mode ships from main and follows the latest published release. Security fixes land in a new patch release rather than being back-ported to older minors, so always upgrade to the newest version.

Please report security issues privately via GitHub Security Advisories: Report a vulnerability.

Do not open a public issue for a vulnerability. What to expect:

• Initial response: within 5 business days of the report.
• Triage / severity assessment: within 10 business days.
• Coordinated disclosure: we aim to ship a fix and publish the advisory within 90 days of triage. We will keep the report private (embargoed) until a fix is available or the window elapses, and we credit reporters in the advisory unless you ask otherwise.

GitHub Security Advisories provide a private, access-controlled thread for reports; a separate PGP key is not currently published. If you need an encrypted channel before sending details, say so in the advisory and we will arrange one.

OpenCode Goal Mode is a defense-in-depth tool for an AI coding agent. The goal-guard plugin blocks destructive and remote-execution shell commands using a quote-aware tokenizer, but it is not a sandbox:

• The analyzer fails open on un-analyzable or highly dynamic commands it cannot resolve to a concrete form, deferring to OpenCode's own permission rules. (A genuine parser error, by contrast, fails closed — the command is treated as destructive and blocked.) Treat the guard as a guardrail, not a jail.
• Gate freshness is only as trustworthy as the reviewer subagents' verdicts.
• The installer copies agents/*.md, commands/*.md, and the plugins/ tree, merge-registers the sidebar in tui.json, and writes a manifest — never auth files, tokens, sessions, or provider config.

Reports that meaningfully improve detection of destructive commands, or that demonstrate a bypass of the completion/edit-staleness invariants, are especially welcome.

The shell analyzer is a heuristic classifier, not a sandbox, so a measurable fraction of genuinely destructive commands are not blocked.

• Fail-open rate (about 7.7%). On the external corpus of 704 real third-party commands the analyzer detects 92.3% of destructive commands, so roughly 7.7% (8 of the 104 destructive commands) are not blocked and fall through to OpenCode's own permission rules. See research/benchmarks.md for the methodology.
• What fails open. The remaining misses are dominated by two categories:
  1. Intentionally permitted forms — a plain single-target rm <file> (and rm -i, -v, -d) is not blocked by design; the guard targets rm -r and rm -f, command-substitution, bash -c, and interpreter deletes, and remote execution.
  2. Un-analyzable or highly dynamic commands — when the tokenizer cannot resolve a concrete command (variable interpolation, runtime-built strings) it returns "not blocked" rather than guessing. A parser error, distinct from an un-resolvable command, instead fails closed and blocks.
• Recommended mitigations for the un-blocked tail: keep OpenCode's own permission rules enabled, run the agent against a clean working tree under version control, and add repo-side guards (git pre-commit hooks, protected branches, CI checks) so an irreversible action outside the analyzer's reach is still recoverable. Treat the guard as one layer of defense-in-depth, not a jail.