Struct OpenCode 

pub struct OpenCode;

Trait Implementations

impl AgentAdapter for OpenCode

fn mcp_config_relpath(&self) -> &'static str

MCP servers join the policy rules in .opencode/opencode.json, which OpenCode merges over the project’s opencode.json, so the project’s own file is never edited.

fn mcp_env_reference(&self, var: &str) -> String

OpenCode expands {env:VAR} in its config.

fn mcp_server_entry(&self, server: &McpServerConfig) -> Value

OpenCode’s mcp.<id> entry: type is local or remote, a local server’s program and arguments are one command array, and its variables sit under environment.

fn id(&self) -> &'static str

fn display_name(&self) -> &'static str

fn dir_prefix(&self) -> &'static str

fn supported_agents(&self) -> &[&'static str]

fn kinds_supported(&self) -> &[CapabilityType]

fn hook_compatibility(&self) -> &'static CompatibilityMatrix

fn hook_settings_relpath(&self) -> &'static str

fn scaffold_hook_event(&self) -> &'static str

The native event tuff create registers a scaffolded hook under.

fn hook_settings_shape(&self) -> HookSettingsShape

How the settings file at hook_settings_relpath lays out its registrations. This is the whole of what differs between harnesses in hook handling; the merge and removal follow from it.

fn policy_compatibility(&self) -> Vec<PolicyCoverageEntry>

How this harness enforces each kind of policy rule, one row per effect and subject. The default says, for every row, that Tuff does not compile policies for this harness, so a policy is refused for it rather than reported as installed.

fn permissions_settings_relpath(&self) -> Option<&'static str>

The settings file this harness reads native permission rules from, when it has one a repository can carry.

fn native_permission_rules( &self, rule: &PolicyRule, ) -> Result<Option<Vec<String>>>

The native permission rules one policy rule compiles to on this harness, or None when the harness has no such rules. The list the rules go in follows the policy rule’s effect.

fn detect(&self, repo_root: &Path) -> bool

Whether a project already uses this harness.

fn hook_filename(&self) -> &'static str

fn hook_file_content(&self, hook_cfg: &HookConfig) -> Result<Vec<u8>, TuffError>

fn render_standard_hook( &self, context: HookRenderContext<'_>, ) -> Result<HookRenderPlan, TuffError>

fn command_hook_fragment(&self, native_event: &str, command: &str) -> Value

The hooks-only fragment that registers command under native_event.

fn merge_hook_fragment( &self, existing: Option<&[u8]>, fragment: &Value, ) -> Result<Vec<u8>, TuffError>

Merge a hooks-only fragment into the settings file’s current bytes.

fn remove_hook_settings( &self, repo_root: &Path, managed_hooks: &[ManagedHook], ) -> Result<(), TuffError>

Take Tuff’s registrations out of the settings file, leaving the user’s own alone.

fn permission_relpath_for( &self, _subject: PolicySubjectKind, ) -> Option<&'static str>

The settings file rules of one subject compile into, for a harness that keeps different kinds of rule in different files. The default is permissions_settings_relpath.

fn policy_rule_gap( &self, _rule: &PolicyRule, ) -> Result<Option<String>, TuffError>

Why this harness cannot enforce one rule that its matrix row covers, such as a pattern its native setting has no form for, or None.

fn policy_hook_use( &self, _rule: &PolicyRule, ) -> Result<PolicyHookUse, TuffError>

Whether this harness enforces one policy rule through the tuff policy evaluate hook (RFC-107 D3). The default is never.

fn policy_hook_fragment( &self, _command: &str, _subjects: &[PolicySubjectKind], ) -> Option<Value>

The hooks-only fragment that registers command for rules of these subjects, in the file at hook_settings_relpath, or None when this harness has no hook for policies.

fn policy_hook_request( &self, _input: &Value, ) -> Result<PolicyHookRequest, TuffError>

Read the tool call a policy hook was run for from the harness’s hook input.

fn policy_hook_answer( &self, _event: &str, verdict: PolicyVerdict<'_>, ) -> PolicyHookAnswer

The answer a policy hook gives the harness. The default refuses every call it has a reason to and says nothing otherwise.

fn supports(&self, capability_type: CapabilityType) -> bool

fn native_hook_event(&self, raw_event: &str) -> Result<&'static str, TuffError>

fn canonical_hook_event( &self, raw_event: &str, ) -> Result<&'static str, TuffError>

fn ensure_project_dir(&self, repo_root: &Path) -> Result<(), Error>

fn mcp_http_declares_type(&self) -> bool

Whether this harness wants an explicit "type": "http" on a remote server entry. Claude Code and Codex do; Cursor infers the transport from url and has no type key for remote servers.

fn mcp_server_entry_checked( &self, server: &McpServerConfig, ) -> Result<Value, TuffError>

mcp_server_entry, for a harness whose config cannot express every declaration. The default expresses everything; an override refuses what its harness would silently get wrong, such as a renamed variable, so the install stops before anything is written.

fn install_note(&self, _kind: CapabilityType) -> Option<&'static str>

A note tuff add prints after installing a capability of this kind, for a harness that applies the installed files only under a condition the file itself cannot state, such as Codex loading a project’s .codex/ layer only once the project is trusted.

fn plan( &self, capability: &ResolvedCapability, repo_root: &Path, ) -> Result<Vec<PlannedFile>, TuffError>

fn remove( &self, primitive_id: &str, repo_root: &Path, managed_hooks: &[ManagedHook], ) -> Result<(), TuffError>

fn plan_skill( &self, capability: &ResolvedCapability, repo_root: &Path, ) -> Result<Vec<PlannedFile>, TuffError>

fn plan_tool( &self, capability: &ResolvedCapability, repo_root: &Path, ) -> Result<Vec<PlannedFile>, TuffError>

fn plan_hook( &self, capability: &ResolvedCapability, repo_root: &Path, ) -> Result<Vec<PlannedFile>, TuffError>

fn plan_native_hook( &self, capability: &ResolvedCapability, native: &NativeHookConfig, repo_root: &Path, ) -> Result<Vec<PlannedFile>, TuffError>

fn plan_mcp_server( &self, capability: &ResolvedCapability, repo_root: &Path, ) -> Result<Vec<PlannedFile>, TuffError>

Emit the canonical server.toml record. The JSON entry in the harness’s MCP config is the artifact the harness reads; this file is what gives the capability a tree to hash, so check/diff/delete work exactly as they do for every other kind.

fn plan_policy( &self, capability: &ResolvedCapability, repo_root: &Path, ) -> Result<Vec<PlannedFile>, TuffError>

Emit the canonical policy.toml record. The rules the harness reads live in its settings file; this record gives the capability a tree to hash, so check, diff, and delete treat it like every other kind, and update can tell when the policy’s rules changed.

fn remove_dir( &self, repo_root: &Path, base: &str, kind: &str, primitive_id: &str, ) -> Result<(), TuffError>