OpenCode

`opencode export` and `opencode import` move single sessions as JSON with one command each, but moving the whole agent (config dir, instructions, skills, credentials, database) means copying documented directories by hand. Export is available immediately.

• packages/opencode/src/cli/cmd/export.ts
• packages/opencode/src/cli/cmd/import.ts
• CLI docs (export/import)

All state is local, so nothing stays with the provider, and MCP OAuth uses dynamic client registration. However, the documented session export carries file-snapshot history only as hash references to a separate internal git store. The documented storage layout is also out of date (it describes per-project JSON storage, while the code uses opencode.db).

• export.ts (snapshot fields exported as hashes)
• Troubleshooting docs: Storage
• core/src/database/database.ts (opencode.db)
• mcp/oauth-provider.ts (dynamic client registration)

The runtime is MIT-licensed with no licence check. The model catalogue fetch from models.opencode.ai times out and falls back to a cache or bundled snapshot, and can be pointed elsewhere or disabled (OPENCODE_MODELS_URL, OPENCODE_DISABLE_MODELS_FETCH). Update checks can be disabled. Needs hands-on confirmation with provider domains blocked.

• LICENSE (MIT)
• core/src/models-dev.ts
• cli/upgrade.ts

Tools run in the runtime, and any AI SDK or OpenAI-compatible provider can be configured, including documented local servers (Ollama, llama.cpp, LM Studio). Web search, on by default only with the provider's own models, can be turned on for any model with documented OPENCODE_ENABLE_EXA / OPENCODE_ENABLE_PARALLEL flags. The docs say the core workflow relies on tool calling.

• Providers docs (local models)
• tool/registry.ts (webSearchEnabled)

Sessions, config, credentials and snapshots live on the owner's machine (~/.local/share/opencode, ~/.config/opencode), so a current copy is always in the owner's hands whatever happens to the provider.

• Troubleshooting docs: Storage
• core/src/database/database.ts

State is in a local SQLite database whose tables are defined in public Drizzle schema files with JSON columns. Config and instructions are JSON/Markdown, snapshots are a git repository, and credentials are unencrypted JSON the owner holds. The published storage docs are out of date, but the schema in source is public.

• core/src/session/sql.ts
• core/src/credential/sql.ts
• core/src/event/sql.ts

Effective merged config is visible through the documented `opencode debug config`, and model and permissions are determinable. The fully assembled context (base prompt files, synthetic plan/build-switch reminders) has no documented viewer and is visible only in source or through experimental OpenTelemetry, so G3 caps this at partial. The default Zen model 'Big Pickle' is documented as a stealth model of undisclosed identity.

• session/llm/request.ts (base prompt selection)
• session/reminders.ts
• Config docs (opencode debug config)
• Zen docs

On the default path, prompts go through the provider's Zen gateway. The privacy policy says personal data is retained 'as long as necessary' for business purposes, with no bounded period and no item-by-item view. For some free models, collected data may be kept to improve the model.

• Privacy policy source (Data Retention)
• Zen docs: Privacy

No paid placement is visible in source, and the owner can replace the default model. However, the default-model ordering hard-codes the provider's own 'big-pickle', and with no key the provider's Zen free models are auto-loaded. The docs do not state this preference at first run, and no binding no-steering commitment exists.

• provider/provider.ts (priority list, opencode autoload)

Sessions record tool calls with inputs and outputs, including subagent child sessions. However, full tool outputs past the truncation limit are stored in tool-output/ and deleted after 7 days by default. Actions taken by plugin hooks are not recorded, and there is no documented alert when recording fails.

• tool/truncate.ts (RETENTION = 7 days)
• Plugins docs

Session, message, part and event rows are plain SQLite with no hashes, signatures or chain, so any edit leaves no trace.

• core/src/event/sql.ts
• core/src/session/sql.ts

Bash is allowed by default and runs without a sandbox as the owner's user, so the agent can modify or delete opencode.db and tool-output files. There is no documented protection for the record.

• Permissions docs: Defaults

All runtime source is MIT and can be built by the owner, but the default distributed builds cannot be tied to source: the publish workflow sets NPM_CONFIG_PROVENANCE: false, and no reproducible-build or attestation process is documented.

• .github/workflows/publish.yml
• LICENSE

The agent has no identity of its own. It acts through the owner's shell, git and provider credentials, and there is no owner-held key or other mechanism that attributes actions to the agent.

• Agents docs

Git-based snapshots show agent-made file changes per session and restore them with /undo and /redo. That covers project-level AGENTS.md and opencode.json when the agent edits them. Global config, model and runtime-version changes are not tracked or attributed, and snapshots are pruned after 7 days.

• TUI docs (/undo, /redo)
• snapshot/index.ts (prune 7 days)

An agent's `prompt` config replaces the model-specific base prompt, and agents, skills and commands are owner-editable files. The synthetic plan and build-switch reminders and the max-steps prompt are hard-coded and can be replaced only by editing source.

• session/llm/request.ts
• session/reminders.ts
• Agents docs: Prompt

OpenCode has no separate hidden memory store. Knowledge carried across sessions lives in owner-editable instruction files (AGENTS.md, skills), and sessions can be listed and deleted with `opencode session`.

• Rules docs
• CLI docs (session delete)

Owners add tools via custom tool files, plugins and MCP servers without review. Any built-in tool can be removed with permission/tools deny rules, including wildcards.

• Custom tools docs
• Agents docs: Tools

Built-in protections (.env read deny, doom_loop and external_directory prompts, snapshots, pruning, autocompaction) are all configurable through documented config or environment variables.

• Permissions docs: Defaults
• CLI docs: Environment variables

By default, patch releases install silently at startup. The owner can set `autoupdate: false` or `"notify"`, pin a version, disable the remote model catalogue fetch, and use their own model provider, so every provider-initiated change can be deferred indefinitely (achievable basis).

• cli/upgrade.ts
• Config docs: Autoupdate

Per-tool, per-command, per-path and per-URL allow/ask/deny rules exist, and spend is treated as met under G11 because there is no payment capability. With default permissions, nothing stops the agent from editing its own project opencode.json or using the unsandboxed shell to get around webfetch domain limits unless the owner writes deny rules.

• Permissions docs

The owner can set any tool, or any command/path pattern, to 'ask', subagents inherit the rules, and auto-approval happens only with the explicit `--auto` flag.

• Permissions docs
• tool/task.ts (subagent cancel on abort)

Esc interrupts the current session and cancels its subagents. There is no documented single stop covering concurrent sessions on a shared server or processes the shell has detached, and no documented guarantee (needs hands-on confirmation).

• Keybinds docs (session_interrupt)
• tool/task.ts

With no key configured, the runtime auto-loads Zen free models and its ordering selects 'big-pickle', for which the Zen docs state that collected data may be used to improve the model during its free period. That is secondary use of content by default, without a specific opt-in. The terms also apply changes when the owner keeps using the service. Sharing is manual (opt-in), and OpenTelemetry export is off unless configured.

• provider/provider.ts (opencode autoload, sort priority)
• Zen docs: Privacy
• Share docs
• Terms of Service source

Credentials are stored locally. `opencode auth list` shows each stored provider credential, and `opencode auth logout` and `opencode mcp logout` revoke each one individually. For the default free Zen path, the runtime uses the literal key 'public' rather than an owner credential.

• CLI docs (auth, mcp logout)
• core/src/credential/sql.ts

`opencode uninstall` removes all local config, data and snapshots in one confirmed command. Deleting data held by the provider's Zen gateway on the default path requires a privacy request by email, with no stated completion limit or confirmation.

• CLI docs (uninstall)
• Privacy policy source