Persistent Memory for
OpenCode via MCP

OpenCode is a fast, open-source terminal AI coding tool built in Go — think Claude Code but fully open and model-agnostic. It lives in your terminal, has no GUI to paste context into, and supports MCP servers natively. This guide shows you how to connect Kronvex persistent memory so OpenCode actually remembers what happened in previous sessions.

What is OpenCode?

OpenCode is a terminal-based AI coding assistant written in Go, designed to be the open-source answer to tools like Claude Code and Gemini CLI. It provides an autonomous agent loop that can read files, run shell commands, apply code edits, and iterate on tasks — entirely from the terminal without requiring VS Code or any other editor.

Key characteristics that differentiate OpenCode:

• Terminal-first: a fully interactive TUI (terminal user interface) built with Bubble Tea — fast, keyboard-driven, no Electron overhead
• Model-agnostic: works with OpenAI, Anthropic Claude, Google Gemini, Groq, and any OpenAI-compatible API including local Ollama models
• MCP support: native support for the Model Context Protocol, meaning external tools (including Kronvex memory) integrate as first-class capabilities
• Session-based: like all terminal AI tools, each session is isolated — there is no built-in persistence between invocations

Why terminal AI coding needs memory most

Terminal AI tools face an acute version of the memory problem. In VS Code, you can at least keep a chat window open across sessions and scroll back through history. In a terminal TUI, when you close OpenCode, that history is gone. There's no GUI state to preserve, no chat history panel to re-read — you start from blank every time.

The consequences compound quickly on real engineering work:

• A multi-day debugging session loses all its hypothesis history when you close the terminal
• The agent can't recall that you already tried a specific approach and hit a dead end
• Architectural decisions made in session N are invisible to session N+1
• SSH sessions to remote servers are especially affected — you have no "clipboard" to carry context between connections

Kronvex solves this at the protocol layer. The MCP server runs as a subprocess managed by OpenCode, and the agent can call memory tools as naturally as it calls bash commands or reads files.

Prerequisites

• OpenCode installed — download from opencode.ai or install via brew install opencode on macOS
• Node.js 18+ installed (to run the Kronvex MCP server via npx)
• A Kronvex account — free at kronvex.io/dashboard, no credit card required
• Your Kronvex API key (kv-...) and Agent ID (UUID from the dashboard)

Configure Kronvex MCP in opencode.json

OpenCode reads its configuration from ~/.config/opencode/opencode.json (global) or .opencode/opencode.json in the current project directory (project-local). Add the Kronvex MCP server under the mcp key:

{
  "$schema": "https://opencode.ai/config.json",
  "model": "anthropic/claude-sonnet-4-6",
  "mcp": {
    "kronvex": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "@kronvex/mcp-server"
      ],
      "environment": {
        "KRONVEX_API_KEY": "kv-your-api-key-here",
        "KRONVEX_AGENT_ID": "your-agent-uuid-here"
      }
    }
  }
}

Global vs project-level configuration

OpenCode supports two levels of configuration that merge at runtime:

• Global (~/.config/opencode/opencode.json): loaded every time OpenCode starts, regardless of directory. Put your Kronvex credentials here so the memory server is always available.
• Project-local (.opencode/opencode.json): overrides global settings for the current project. Use this to set a project-specific KRONVEX_AGENT_ID and KRONVEX_DEFAULT_SESSION, so memories are scoped to the project automatically.

{
  "mcp": {
    "kronvex": {
      "type": "local",
      "command": ["npx", "-y", "@kronvex/mcp-server"],
      "environment": {
        "KRONVEX_API_KEY": "$KRONVEX_API_KEY",
        "KRONVEX_AGENT_ID": "project-specific-agent-uuid",
        "KRONVEX_DEFAULT_SESSION": "my-api-service"
      }
    }
  }
}

Verify the MCP connection

Start OpenCode in your project directory. When it initialises, it will spin up the Kronvex MCP server as a background subprocess. You can verify the connection from the OpenCode TUI:

If the server fails to connect, check that Node.js is available in the PATH that OpenCode uses. On macOS with nvm or fnm, you may need to hardcode the node path: replace "npx" with "/Users/you/.nvm/versions/node/v20.0.0/bin/npx".

Using memory in OpenCode sessions

Once connected, the Kronvex tools are available to the agent. The MCP server exposes five tools:

• kronvex_remember — store a memory (content, memory_type, session_id, ttl_days)
• kronvex_recall — semantic search, returns array with confidence scores
• kronvex_inject_context — returns a pre-formatted string for system prompt injection
• kronvex_list_memories — list all memories with optional type/session filters
• kronvex_delete_memory — delete a specific memory by ID

You can ask the agent to use these tools in natural language:

# Store a decision
Remember that we're using Temporal.io for workflow orchestration,
not a custom queue. Decision was made to avoid reimplementing retry logic.

# Retrieve context before a task
Before we start, recall everything you know about our payment integration.

# Search for a specific past event
Have we encountered race conditions in this codebase before?

# Store a procedural pattern
Remember as a procedural memory: always run 'go vet ./...' before
submitting PRs in this repo. CI checks it but local dev often misses it.

Custom agent instructions for memory

OpenCode supports custom agent instructions through the instructions field in opencode.json. Adding memory instructions here ensures the agent uses Kronvex proactively without needing to be prompted every session:

{
  "$schema": "https://opencode.ai/config.json",
  "model": "anthropic/claude-sonnet-4-6",
  "instructions": "You have access to persistent memory via Kronvex MCP tools. At the start of each new task, call kronvex_inject_context with the task description to retrieve relevant past decisions and context. After completing significant work — architectural decisions, root cause findings, important patterns — call kronvex_remember to store them. Use memory_type semantic for facts, episodic for events, procedural for recurring patterns. Always include session_id matching the project name.",
  "mcp": {
    "kronvex": {
      "type": "local",
      "command": ["npx", "-y", "@kronvex/mcp-server"],
      "environment": {
        "KRONVEX_API_KEY": "$KRONVEX_API_KEY",
        "KRONVEX_AGENT_ID": "$KRONVEX_AGENT_ID"
      }
    }
  }
}

Real-world use cases

Remote server coding over SSH

One of the most compelling use cases for OpenCode + Kronvex is coding on remote servers over SSH. When you SSH into a production server to diagnose an issue, OpenCode runs in the terminal and can recall previous debugging sessions, known failure modes, and runbook knowledge. When the SSH session ends, the memories persist in Kronvex — so the next engineer who connects has the benefit of your work.

Infrastructure-as-code development

Terraform and Pulumi codebases accumulate layers of decisions over years — why a specific resource was named a certain way, why a default was overridden, what the blast radius of a change is. Storing this as procedural and semantic memories in Kronvex means OpenCode can surface "we disabled deletion protection on this bucket during the 2025-08 migration — do not re-enable until the data pipeline is updated" before any agent makes a destructive change.

Multi-service backend development

When working across multiple microservices, use different Kronvex agents per service with a shared session_id for cross-service concerns (shared API contracts, service mesh config, shared database schemas). OpenCode can pull relevant context from the right scope depending on what it's working on.

Tips and best practices

Terminal-specific memory patterns

Terminal AI tools tend to work on tasks that have clearer start and end points than chat-based GUI tools. Use this structure: at the start of a task, explicitly ask the agent to recall context. At the end, explicitly ask it to summarize and store. This two-step pattern gives you the most reliable memory persistence.

SSH and remote server memory

When using OpenCode on a remote server, the Kronvex MCP server runs on the remote machine (where OpenCode is running) and makes outbound HTTPS calls to api.kronvex.io. Ensure the remote server has outbound internet access on port 443 and Node.js installed. If Node.js is not available, consider using the Kronvex REST API directly with curl-based memory scripts instead.

• Confidence scoring: Kronvex uses similarity × 0.6 + recency × 0.2 + frequency × 0.2 — memories you access regularly rank higher over time, creating a natural prioritisation toward what actually matters in the codebase
• EU data residency: all memories stored in Frankfurt — no data leaves the EU, GDPR-compliant out of the box
• No rate limits on recall: the recall and inject-context endpoints are optimised for frequent calls — use them freely at the start of every agent task
• Combine with AGENTS.md: OpenCode reads AGENTS.md files for project instructions — use this for static instructions, and Kronvex for dynamic, evolving knowledge