openwork

OpenWork is a cross-platform desktop application (macOS, Windows, Linux) that lets you run agentic AI workflows entirely on your own machine, powered by opencode under the hood. Instead of locking you into a single provider, it lets you connect any of 50+ LLM providers using your own API keys — from Anthropic and OpenAI to Ollama and local models — and then point those agents at whatever workspace folder you choose.

The application is built around a local-first philosophy: open a project folder, start a session, send prompts to AI agents, and watch them execute in real time via streaming SSE events — all without a cloud intermediary. When you’re ready to scale up, OpenWork can optionally connect to remote OpenCode servers or the hosted OpenWork Cloud for distributed agent workers.

Extensibility is a first-class design goal. OpenWork’s skills and plugin system lets you install shareable agent configurations stored as .opencode/skills folders, and manage OpenCode plugins directly from the UI by editing opencode.json. The MCP (Model Context Protocol) server integration allows connecting any external tool or data source as a context provider for agents. Teams can package entire agentic workflows as repeatable, productized processes and share complete setups with a single link.

The project also ships an optional CLI host — the openwork-orchestrator npm package — that runs opencode, the OpenWork server, and an optional opencode-router without the desktop UI, making it suitable for server deployments, CI environments, or headless automation pipelines.

What You Get

• Cross-platform desktop app (macOS, Windows, Linux) built with Tauri + React 19 that runs opencode agents locally with zero cloud dependency
• Support for 50+ LLM providers via bring-your-own-key connections, including Anthropic, OpenAI, Ollama, and any OpenAI-compatible endpoint
• Real-time session streaming using Server-Sent Events (SSE) to show agent progress, todos, tool calls, and permission requests as they happen
• A skills manager for installing, importing, and sharing .opencode/skills agent configurations, and an OpenCode plugin manager for opencode.json
• MCP (Model Context Protocol) server integration allowing any external tool, data source, or service to be wired in as agent context
• An orchestrator CLI (openwork-orchestrator) for headless or server deployments without the desktop UI
• A team-sharing model where complete agent setups — LLM config, skills, plugins, MCP servers — can be distributed in a single shareable link
• Optional remote worker support: connect to hosted OpenWork Cloud workers or self-hosted remote OpenCode servers from the desktop app

Common Use Cases

• Running AI coding agents on local repositories without sending source code to third-party cloud services
• Teams sharing standardized agentic workflows as reusable skill packages that colleagues can install in one step
• Organizations running OpenWork in server/headless mode via the orchestrator CLI to automate pipelines in CI or production
• Developers evaluating multiple LLM providers side-by-side on the same tasks using different API key configurations
• Self-hosters who want Claude Cowork or Codex-style AI agent capabilities without managed-service pricing
• Enterprises deploying OpenWork with organizational SSO/SAML, desktop policies, and version controls via the Den backend

Under The Hood

Architecture OpenWork is structured as a layered monorepo with strict dependency rules enforced by circular-import detection. The innermost layer is a framework-agnostic application core containing all clients, wire types, and feature helpers with zero React imports — a hard invariant verified at build time. Sitting above it is the React layer organized into a kernel (app-wide Zustand state and provider stack), an infra layer (TanStack Query singleton), a design-system layer (presentational primitives), and a domain layer with feature-scoped modules for session, workspace, settings, connections, cloud, and onboarding. The shell layer at the top composes providers, routing, and boot state. This strict layering means UI frameworks can be swapped without touching business logic — the team recently migrated from a Solid runtime to React 19 without rewriting the agnostic core. The Tauri desktop shell wraps the Vite-built web app, and the same web bundle runs in a browser or on a server, distinguished at runtime by deployment detection. Dependency flow is unidirectional: kernel never imports domains, domains never import shell, and shared wire types live in a dedicated types package.

Tech Stack The frontend is React 19 with Vite as the bundler, TypeScript in strict mode, TanStack Query for server state, and Zustand for client-side application state. UI components are built on Radix UI primitives with Tailwind CSS and a Lexical-based rich-text composer. The desktop shell is Tauri (Rust), giving native OS integration for the folder picker, system tray, and auto-updater. The opencode integration happens through the @opencode-ai/sdk v2 client over HTTP and SSE. The orchestrator CLI is compiled to a standalone binary via Bun, then published as an npm package with platform-specific optional dependencies. The enterprise backend (Den) is a separate Next.js web app, a Hono API server on Node.js, a MySQL database accessed through Drizzle ORM, and a worker proxy — all in the ee/ directory under the FSL-1.1-MIT license. Internationalization is handled through a custom i18n layer supporting ten languages.

Code Quality The test suite uses Bun’s built-in test runner and spans approximately 100 test files covering composer state management, session sync, permission approval flows, SSE event handling, todo rendering, notification stores, mention encoding, and Electron-specific runtime logic. Integration scripts written in Node.js and Bun serve as end-to-end verifiers for health, sessions, events, permissions, browser entry, and fs-engine behavior. TypeScript strict mode is enforced project-wide with pnpm typecheck as a required CI step. The architecture enforces zero circular imports (verified via madge) as a codified quality gate. Error handling is explicit: permission requests surface to the user for allow-once/always/deny decisions rather than being silently auto-approved. The codebase has extensive inline documentation including a detailed ARCHITECTURE.md, AGENTS.md contributor guide, VISION.md, PRINCIPLES.md, PRODUCT.md, and a PR template that requires evidence of manual verification.

What Makes It Unique OpenWork’s most distinctive technical choice is the clean separation between the UI host and the agent runtime through the opencode protocol. The desktop app is deliberately a thin client over the opencode SSE API, which means the entire agent execution engine is replaceable or runnable independently via the orchestrator CLI. This architecture enables the same session, skill, and plugin configurations to work identically in desktop, headless server, Slack/Telegram connector, and browser deployments — a composability guarantee most AI desktop tools cannot make. The skill-sharing model is also architecturally interesting: skills are portable folder structures that encode complete agent behaviors, and the Skills Manager in the UI is a first-class distribution mechanism rather than an afterthought. Combined with shareable workspace links that bundle LLM config, skills, plugins, and MCP servers, OpenWork operationalizes the concept of reproducible AI workflows in a way that is structurally enforced rather than merely documented.

Self-Hosting

OpenWork is dual-licensed. The core desktop application, UI, server, and orchestrator packages are released under the MIT License, which permits free use, modification, redistribution, and commercial deployment without restriction or royalty. However, all content residing under the ee/ directory — which includes the Den backend (API server, web dashboard, worker runtime, and database layer) — is licensed under the Functional Source License 1.1 with MIT Future License (FSL-1.1-MIT). FSL is a source-available license that restricts production use of the ee/ code for competing commercial products for a two-year period, after which it converts to MIT. For the vast majority of self-hosters, this distinction is immaterial: the desktop app and headless orchestrator are pure MIT and cover the entire local-first use case. The FSL applies only if you attempt to run and monetize the Den team backend.

Operationally, self-hosting the core app is straightforward — it is a downloadable binary with no infrastructure requirements beyond the machine it runs on. The openwork-orchestrator CLI adds a sidecar download mechanism that fetches openwork-server, opencode-router, and opencode binaries on first run, caching them locally. For team or server deployments, the Den backend requires a MySQL database, a Node.js API server (Hono), a Next.js web frontend, optional worker proxy nodes, and configuration of auth secrets. There is no official Helm chart or managed installer for Den; operators are responsible for provisioning the database, managing encryption keys, handling backups, and coordinating upgrades across the web, API, and worker tiers. The ee/apps/den-api package contains Drizzle ORM migrations that must be applied on each update.

Compared to the hosted OpenWork Cloud offering, self-hosters forgo managed worker provisioning (Cloud workers are launched from the web app and connected over the network), professional support SLAs, and automatic updates. The Enterprise plan adds SSO/SAML with SCIM provisioning, desktop policy management (enforcing minimum versions and allowed extensions across an organization), managed deployment assistance, and dedicated MCP consulting. Windows support currently requires a paid support plan. Self-hosters who need SSO or desktop policy enforcement will need to either license the Enterprise plan or operate the Den backend with the FSL-1.1-MIT licensed ee/ code outside its commercial-use restrictions.