* feat(den): add daytona-backed docker dev flow * fix(den): allow multiple cloud workers in dev * fix(den): use Daytona snapshots for sandbox runtime Use a prebuilt Daytona snapshot for the dev worker runtime so sandboxes start with openwork and opencode already installed. Pass the snapshot through the local Docker flow and add a helper to build the snapshot image for repeatable setup. * chore(den): lower Daytona snapshot defaults Reduce the default snapshot footprint to 1 CPU and 2GB RAM so local Daytona worker testing fits smaller org limits more easily. * Omar is comfortable Make Daytona-backed cloud workers stable enough to reconnect through a dedicated proxy instead of persisting expiring signed preview URLs. Split the proxy into its own deployable service, share Den schema access through a common package, and fix the web badge so healthy workers show ready. * chore(den-db): add Drizzle package scripts Move the shared schema package toward owning its own migration workflow by adding generate and migrate commands plus a local Drizzle config. * chore: update lockfile Refresh the workspace lockfile so the new den-db Drizzle tooling is captured in pnpm-lock.yaml. * feat(den-worker-proxy): make Vercel deployment-ready Align the proxy service with Vercel's Hono runtime entry pattern and keep a separate Node server entry for Docker/local runs. Also scaffold the Vercel project/env setup and wire Render deploy sync to pass Daytona variables needed for daytona mode. * feat(den-db): add db mode switch for PlanetScale Support DB_MODE=planetscale with Drizzle's PlanetScale serverless driver while keeping mysql2 as the local default. This lets Vercel-hosted services use HTTP database access without changing local development workflows. * refactor(den-db): adopt shared TypeID ids Move the Den TypeID system into a shared utils package and use it across auth, org, worker, and sandbox records so fresh databases get one consistent internal ID format. Wire Better Auth into the same generator and update Den request boundaries to normalize typed ids cleanly. * fix(den): restore docker dev stack after refactor Include the shared utils package in the Den Docker images, expose MySQL to the host for local inspection, and fix the remaining Den build/runtime issues surfaced by the Docker path after the shared package and TypeID changes. * docs(den): document Daytona snapshot setup Add README guidance for building and publishing the prebuilt Daytona runtime snapshot, including the helper script, required env, and how to point Den at the snapshot for local Daytona mode. * refactor(den-db): reset migrations and load env files Replace the old Den SQL migration history with a fresh baseline for the current schema, and let Drizzle commands load database credentials from env files. Default to mysql when DATABASE_URL is present and otherwise use PlanetScale credentials so local Docker and hosted environments can share the same DB package cleanly. * fix(den): prepare manual PlanetScale deploys Update the Render workflow and Docker build path for the shared workspace packages, support PlanetScale credentials in the manual SQL migration runner, and stop auto-running DB migrations on Den startup so schema changes stay manual. * feat(den-v2): add Daytona-first control plane Create a new den-v2 service from the current Daytona-enabled control plane, default it to Daytona provisioning, and add a dedicated Render deployment workflow targeting the new v2 Render service. * feat(den-worker-proxy): redirect root to landing Send root proxy traffic to openworklabs.com so direct visits to the worker proxy domain do not hit worker-resolution errors. --------- Co-authored-by: OmarMcAdam <gh@mcadam.io>
OpenWork
OpenWork helps you run your agents, skills, and MCP. It's an open-source alternative to Claude Cowork/Codex (desktop app).
Core Philosophy
- Local-first, cloud-ready: OpenWork runs on your machine in one click. Send a message instantly.
- Composable: desktop app, WhatsApp/Slack/Telegram connector, or server. Use what fits, no lock-in.
- Ejectable: OpenWork is powered by OpenCode, so everything OpenCode can do works in OpenWork, even without a UI yet.
- Sharing is caring: start solo, then share. One CLI or desktop command spins up an instantly shareable instance.
OpenWork is designed around the idea that you can easily ship your agentic workflows as a repeatable, productized process.
Alternate UIs
- OpenWork Orchestrator (CLI host): run OpenCode + OpenWork server without the desktop UI.
- install:
npm install -g openwork-orchestrator - run:
openwork start --workspace /path/to/workspace --approval auto - docs: packages/orchestrator/README.md
- install:
Quick start
Download the correct version in here, in the latest releases or install from source below.
Why
Current CLI and GUIs for opencode are anchored around developers. That means a focus on file diffs, tool names, and hard to extend capabilities without relying on exposing some form of cli.
OpenWork is designed to be:
- Extensible: skill and opencode plugins are installable modules.
- Auditable: show what happened, when, and why.
- Permissioned: access to privileged flows.
- Local/Remote: OpenWork works locally as well as can connect to remote servers.
What’s Included
- Host mode: runs opencode locally on your computer
- Client mode: connect to an existing OpenCode server by URL.
- Sessions: create/select sessions and send prompts.
- Live streaming: SSE
/eventsubscription for realtime updates. - Execution plan: render OpenCode todos as a timeline.
- Permissions: surface permission requests and reply (allow once / always / deny).
- Templates: save and re-run common workflows (stored locally).
- Skills manager:
- list installed
.opencode/skillsfolders - install from OpenPackage (
opkg install ...) - import a local skill folder into
.opencode/skills/<skill-name>
- list installed
Skill Manager
Works on local computer or servers
Quick Start
Requirements
- Node.js +
pnpm - Rust toolchain (for Tauri): install via
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh - Tauri CLI:
cargo install tauri-cli - OpenCode CLI installed and available on PATH:
opencode
Local Dev Prerequisites (Desktop)
Before running pnpm dev, ensure these are installed and active in your shell:
- Node + pnpm (repo uses
pnpm@10.27.0) - Bun 1.3.9+ (
bun --version) - Rust toolchain (for Tauri), with Cargo from current
rustupstable (supportsCargo.lockv4) - Xcode Command Line Tools (macOS)
- On Linux, WebKitGTK 4.1 development packages so
pkg-configcan resolvewebkit2gtk-4.1andjavascriptcoregtk-4.1
One-minute sanity check
Run from repo root:
git checkout dev
git pull --ff-only origin dev
pnpm install --frozen-lockfile
which bun
bun --version
pnpm --filter @different-ai/openwork exec tauri --version
Install
pnpm install
OpenWork now lives in packages/app (UI) and packages/desktop (desktop shell).
Run (Desktop)
pnpm dev
pnpm dev now enables OPENWORK_DEV_MODE=1 automatically, so desktop dev uses an isolated OpenCode state instead of your personal global config/auth/data.
Run (Web UI only)
pnpm dev:ui
All repo dev entrypoints now opt into the same dev-mode isolation so local testing uses the OpenWork-managed OpenCode state consistently.
Arch Users:
sudo pacman -S --needed webkit2gtk-4.1
yay -s opencode # Releases version
Architecture (high-level)
- In Host mode, OpenWork runs a local host stack and connects the UI to it.
- Default runtime:
openwork(installed fromopenwork-orchestrator), which orchestratesopencode,openwork-server, and optionallyopencode-router. - Fallback runtime:
direct, where the desktop app spawnsopencode serve --hostname 127.0.0.1 --port <free-port>directly.
- Default runtime:
When you select a project folder, OpenWork runs the host stack locally using that folder and connects the desktop UI. This lets you run agentic workflows, send prompts, and see progress entirely on your machine without a remote server.
- The UI uses
@opencode-ai/sdk/v2/clientto:- connect to the server
- list/create sessions
- send prompts
- subscribe to SSE events(Server-Sent Events are used to stream real-time updates from the server to the UI.)
- read todos and permission requests
Folder Picker
The folder picker uses the Tauri dialog plugin. Capability permissions are defined in:
packages/desktop/src-tauri/capabilities/default.json
OpenPackage Notes
If opkg is not installed globally, OpenWork falls back to:
pnpm dlx opkg install <package>
OpenCode Plugins
Plugins are the native way to extend OpenCode. OpenWork now manages them from the Skills tab by
reading and writing opencode.json.
- Project scope:
<workspace>/opencode.json - Global scope:
~/.config/opencode/opencode.json(or$XDG_CONFIG_HOME/opencode/opencode.json)
You can still edit opencode.json manually; OpenWork uses the same format as the OpenCode CLI:
{
"$schema": "https://opencode.ai/config.json",
"plugin": ["opencode-wakatime"]
}
Useful Commands
pnpm dev
pnpm dev:ui
pnpm typecheck
pnpm build
pnpm build:ui
pnpm test:e2e
Troubleshooting
Linux / Wayland (Hyprland)
If OpenWork crashes on launch with WebKitGTK errors like Failed to create GBM buffer, disable dmabuf or compositing before launch. Try one of the following environment flags.
WEBKIT_DISABLE_DMABUF_RENDERER=1 openwork
WEBKIT_DISABLE_COMPOSITING_MODE=1 openwork
Security Notes
- OpenWork hides model reasoning and sensitive tool metadata by default.
- Host mode binds to
127.0.0.1by default.
Contributing
- Review
AGENTS.mdplusVISION.md,PRINCIPLES.md,PRODUCT.md, andARCHITECTURE.mdto understand the product goals before making changes. - Ensure Node.js,
pnpm, the Rust toolchain, andopencodeare installed before working inside the repo. - Run
pnpm installonce per checkout, then verify your change withpnpm typecheckpluspnpm test:e2e(or the targeted subset of scripts) before opening a PR. - Use
.github/pull_request_template.mdwhen opening PRs and include exact commands, outcomes, manual verification steps, and evidence. - If CI fails, classify failures in the PR body as either code-related regressions or external/environment/auth blockers.
- Add new PRDs to
packages/app/pr/<name>.mdfollowing the.opencode/skills/prd-conventions/SKILL.mdconventions described inAGENTS.md.
Community docs:
CODE_OF_CONDUCT.mdSECURITY.mdSUPPORT.mdTRIAGE.md
First contribution checklist:
- Run
pnpm installand baseline verification commands. - Confirm your change has a clear issue link and scope.
- Add/update tests for behavioral changes.
- Include commands run and outcomes in your PR.
- Add screenshots/video for user-facing flow changes.
For Teams & Businesses
Interested in using OpenWork in your organization? We'd love to hear from you — reach out at ben@openworklabs.com to chat about your use case.
License
MIT — see LICENSE.
