Introduction & Overview
Relevant source files
The following files were used as context for generating this wiki page:
OpenWork is an open-source, extensible alternative to "Claude Cowork," designed to turn agentic workflows into premium, guided product experiences for both technical and non-technical users. It acts as a sophisticated experience layer built on top of the OpenCode engine, providing a slick, mobile-first interface for executing tasks, managing specialized skills, and overseeing complex automations with built-in audit trails and safety guardrails.
The system is architected to prioritize local-first execution, least-privilege security, and transparency. By leveraging OpenCode's native primitives—such as sessions, skills, and plugins—OpenWork provides a unified platform where users can describe outcomes, watch real-time plan updates, and manage permissions through a professional UI rather than a terminal.
Sources: README.md:5-15, PRODUCT.md:20-25, AGENTS.md:5-12
Core Product Philosophy
OpenWork is designed to bridge the gap between powerful developer-centric CLI tools and the needs of knowledge workers. The product distinguishes between two primary user personas: "Bob the IT guy," who sets up agents and shared workspaces, and "Susan in accounting," who requires a reliable, "just works" interface for task completion.
Key Success Metrics
- Time to First Task: Less than 5 minutes on a fresh install.
- Task Success Rate: Over 80% without requiring terminal fallback.
- UI Performance: Consistent 60fps with less than 100ms interaction latency.
Sources: PRODUCT.md:4-18, PRODUCT.md:27-31, AGENTS.md:75-81
System Architecture & Modes
OpenWork is built as a Tauri application that can operate in two distinct runtime modes, ensuring accessibility across desktop and mobile platforms.
Runtime Modes
| Mode | Description | Key Components |
|---|---|---|
| Host Mode | Runs locally on a desktop/laptop. | Starts OpenCode locally, binds to loopback (127.0.0.1:4096), UI connects via official SDK. |
| Client Mode | Remote controller for iOS/Android or desktop. | Connects to a running OpenCode server via secure transport (LAN/Tunnel) using QR pairing. |
Sources: ARCHITECTURE.md:46-59, README.md:55-65
High-Level Architecture Flow
The following diagram illustrates the relationship between the OpenWork UI, the Tauri shell, and the underlying OpenCode engine.
This diagram shows the flow from user input through the SDK to the spawned OpenCode process and back via Server-Sent Events (SSE).
Sources: ARCHITECTURE.md:65-90, AGENTS.md:27-32, README.md:120-128
Data Primitives & Extensibility
OpenWork relies heavily on OpenCode's native surfaces for its functionality, treating the UI as a thin but powerful layer over filesystem-based configurations.
1. Primitives
- Tasks & Runs: A task is a user-described outcome; a run is an OpenCode session + event stream.
- Workspaces: Conceptually a project folder containing an
opencode.jsonand a.opencodedirectory for local state. - Audit Logs: Every run exports prompts, plans, tool calls, and permission decisions.
2. Extensibility Options
OpenWork exposes four primary methods for extending functionality, each suited for different risk profiles and technical requirements.
| Primitive | Use Case | Security/Risk |
|---|---|---|
| Skills | Legible, plain-English patterns for repeatable workflows. | High (Safe/FS-based) |
| Plugins | Scoped tools in code for guardrails and capability packaging. | Medium |
| MCP | Authenticated third-party flows (OAuth). | Medium |
| Bash/CLI | Raw CLI access for power users and prototyping. | Low (Highest risk) |
Sources: PRODUCT.md:33-60, ARCHITECTURE.md:6-34, PRINCIPLES.md:12-20
Security & Permission Model
Security in OpenWork is governed by two distinct layers to ensure that agents only operate within authorized boundaries.
- UI Authorization: Users explicitly select allowed folders through a native file picker. The app remembers these allowed roots per profile.
- Server Permissions: The OpenCode engine requests permissions for specific tool calls. OpenWork intercepts these requests via SSE events and displays them to the user.
Permission Response Options
When a permission is requested, the user is presented with three choices:
- Allow Once: Permission granted for the current tool call only.
- Allow for Session: Permission granted for the duration of the current session ID.
- Deny: The request is rejected, and the run fails gracefully.
Sources: ARCHITECTURE.md:144-165, PRODUCT.md:130-136, PRINCIPLES.md:22-30
Technical Stack
OpenWork utilizes a modern, performance-oriented stack to achieve its goal of a "premium" feel.
- Frontend: SolidJS + TailwindCSS for high-performance reactive UI.
- Desktop/Mobile Shell: Tauri 2.x for cross-platform native capabilities.
- Integration: Official OpenCode TS SDK (
@opencode-ai/sdk/v2/client). - State Management: Solid stores combined with IndexedDB for local persistence.
- Communication: Server-Sent Events (SSE) for real-time streaming of assistant responses and tool execution progress.
Sources: AGENTS.md:27-32, ARCHITECTURE.md:67-73, INFRASTRUCTURE.md:40-48
Summary
Introduction & Overview defines OpenWork as a sophisticated bridge between raw AI engine capabilities and end-user productivity. By organizing the system around workspaces, sessions, and a robust permission model, OpenWork provides a safe, auditable, and extensible environment for agentic work. Whether running locally in Host mode or remotely as a Client, the platform maintains parity with OpenCode primitives while delivering a consumer-grade user experience.
Sources: README.md:10-25, PRODUCT.md:20-25, INFRASTRUCTURE.md:70-75