@kingpower/daytona-opencode

OpenCode plugin that automatically runs all sessions in Daytona sandboxes for isolated, reproducible development environments.

Fork of @daytona/opencode v0.190.0 with self-hosted Daytona fixes. Tracks upstream.

Features

• Securely isolate each OpenCode session in a sandbox environment
• Preserves sandbox environments indefinitely until the OpenCode session is deleted
• Generates live preview links when a server starts in the sandbox
• Synchronizes each OpenCode session to a local git branch

Installation

To add the plugin to a project, edit opencode.json in the project directory:

{
  "$schema": "https://opencode.ai/config.json",
  "plugin": ["@kingpower/daytona-opencode"]
}

Now that the Daytona plugin is in the plugins list, it will automatically be downloaded when OpenCode starts.

To install the plugin globally, edit ~/.config/opencode/opencode.json.

Environment Configuration

This plugin requires a Daytona account and Daytona API key to create sandboxes.

Set your Daytona API key and URL as environment variables:

export DAYTONA_API_KEY="your-api-key"

Or create a .env file in your project root:

DAYTONA_API_KEY=your-api-key

Self-hosted Daytona

This fork adds two fixes for self-hosted Daytona instances:

1. API URL — the Daytona SDK defaults to https://app.daytona.io/api (Daytona Cloud). Point it at your self-hosted API by setting the DAYTONA_API_URL environment variable:

   export DAYTONA_API_URL="https://daytona.example.com/api"

2. Git sync host/port — upstream hardcodes ssh.app.daytona.io for git sync, ignoring the sshCommand returned by your API's createSshAccess. This fork parses host and port from sshAccess.sshCommand, so git sync works against any SSH gateway.

Running OpenCode

Before starting OpenCode, ensure that your project is a git repository:

git init

Now start OpenCode in your project using the OpenCode command:

opencode

To check that the plugin is working, type pwd in the chat. You should see a response like /home/daytona/project, and a toast notification that a new sandbox was created.

OpenCode will create new branches using the format opencode/1, opencode/2, etc. To work with these changes, use normal git commands in a separate terminal window. List branches:

git branch

Check out OpenCode's latest changes on your local system:

git checkout [branch]

To view live logs from the plugin for debugging, run this command in a separate terminal:

tail -f ~/.local/share/opencode/log/daytona.log

How It Works

File Synchronization

The plugin uses git to synchronize files between the sandbox and your local system. This happens automatically and in the background, keeping your copy of the code up-to-date without exposing your system to the agent.

Sandbox Setup

When a new Daytona sandbox is created:

1. The plugin looks for a git repository in the local directory. If none is found, file synchronization will be disabled.
2. A parallel repository is created in the sandbox with a single opencode branch, mirroring the checked out local branch.
3. A new sandbox remote is added to the local repository using an SSH connection to the sandbox.
4. The HEAD of the local repository is pushed to opencode, and the sandbox repository is reset to match this initial state.
5. Each sandbox is assigned a unique incrementing branch number (1, 2, 3, etc.) that persists across sessions.

Synchronization

Each time the agent makes changes:

1. A new commit is created in the sandbox repository on the opencode branch.
2. The plugin pulls the latest commits from the sandbox remote into a unique local branch named opencode/1, opencode/2, etc. This keeps both environments in sync while isolating changes from different sandboxes in separate local branches.

The plugin only synchronizes changes from the sandbox to your system. To pass local changes to the agent, commit them to a local branch, and start a new OpenCode session with that branch checked out.

[!CAUTION] When changes are synchronized to local opencode branches, any locally made changes will be overwritten.

Session to sandbox mapping

The plugin keeps track of which sandbox belongs to each OpenCode project using local state files. This data is stored in a separate JSON file for each project:

• On macOS: ~/.local/share/opencode/storage/daytona/[projectid].json.
• On Windows: %LOCALAPPDATA%\opencode\storage\daytona\[projectid].json.

Each JSON file contains the sandbox metadata for each session in the project, including when the sandbox was created, and when it was last used.

The plugin uses XDG Base Directory specifically to resolve the path to this directory, using the convention set by OpenCode.

Differences from upstream

This fork (@kingpower/daytona-opencode) is based on @daytona/opencode v0.190.0 and adds:

• DAYTONA_API_URL env var support so the SDK points at a self-hosted API instead of Daytona Cloud.
• session-git-manager parses host and port from sshAccess.sshCommand instead of hardcoding ssh.app.daytona.io.

Everything else mirrors upstream.

License

Apache-2.0