OpenCode on HELM

What this proves

OpenCode runs through HELM’s fail-closed execution boundary. The launch is driven by a registry-pinned app definition and a safe default-deny policy: HELM installs OpenCode into a sandboxed local container, gates every tool call through the kernel verdict path, and emits a signed receipt for each lifecycle step, from install and healthcheck to teardown. The run ends with an exported EvidencePack that anyone can verify offline, so terminal coding sessions stay inside a provable authority envelope.

flowchart TD
    A[OpenCode Agent] -->|Request Tool Call| B(HELM AI Kernel)
    B -->|Check Policy| C{Verdict}
    C -->|ALLOW| D[Execute Action]
    C -->|DENY| E[Block & Return Error]
    C -->|ESCALATE| F[Step-Up / Operator Approval]
    D -->|Teardown / Receipt| G[EvidencePack Export]

flowchart TD
    A[OpenCode Agent] -->|Request Tool Call| B(HELM AI Kernel)
    B -->|Check Policy| C{Verdict}
    C -->|ALLOW| D[Execute Action]
    C -->|DENY| E[Block & Return Error]
    C -->|ESCALATE| F[Step-Up / Operator Approval]
    D -->|Teardown / Receipt| G[EvidencePack Export]

Headless path

helm-ai-kernel launch opencode local-container --headless --output json

Source Truth

• Registry source: registry/launchpad/apps/opencode.yaml
• Policy source: policies/launchpad/apps/opencode.safe.toml

Evidence requirements

• cpi_output
• kernel_verdict
• sandbox_grant
• launch_receipt
• install_receipt
• healthcheck_receipt
• teardown_receipt
• evidence_pack
• evidence_graph
• mcp_quarantine
• mcp_manifest
• artifact_digest
• cosign_signature
• syft_sbom
• grype_vulnerability_scan

Verify

helm-ai-kernel verify --bundle <pack>