# What Are the Core Components of the OpenWork Project?

> Explore the core components of the OpenWork project: an Electron desktop client, cloud-native Den server, React UI libraries, and an MCP client for AI agents. Discover its monorepo structure.

- Repository: [Different AI/openwork](https://github.com/different-ai/openwork)
- Tags: deep-dive
- Published: 2026-08-13

---

**The OpenWork project is structured as a monorepo containing an Electron-based desktop client, a cloud-native Den server, reusable React UI libraries, and an MCP client that exposes OpenWork capabilities to external AI agents.**

OpenWork is an open-source AI workspace platform that bridges local desktop applications with cloud-native services. Understanding the core components of the OpenWork project is essential for developers extending its functionality or deploying custom instances. The architecture organizes code into distinct packages under the `different-ai/openwork` repository, separating concerns between desktop runtime, server-side logic, and agent interfaces.

## Desktop Client

The **Desktop Client** provides a native macOS, Windows, and Linux interface built on Electron. It hosts a local CDP (Chrome DevTools Protocol) server that enables AI agents to interact with the application runtime.

Located in `apps/desktop`, the entry point is [`apps/desktop/main.ts`](https://github.com/different-ai/openwork/blob/main/apps/desktop/main.ts), which bootstraps the Electron process and initializes the local agent server. This component enables the local-first workflow that characterizes OpenWork, allowing users to run AI-driven automations directly on their machines without cloud dependency.

To launch the desktop client locally:

```bash

# From the repository root

pnpm dev

```

This executes the script defined in the root [`package.json`](https://github.com/different-ai/openwork/blob/main/package.json), which starts the Electron entry point. For isolated development with multiple instances, use:

```bash
pnpm dev:worktree

```

The `dev:worktree` command auto-creates a profile so multiple desktop instances can run side-by-side without configuration conflicts.

## OpenWork Den Server

The **OpenWork Den Server** serves as the cloud-first control plane, managing organizations, team configurations, model provider settings, and skill publications. This server component enables enterprise-scale deployments and multi-user collaboration.

Source code resides in `apps/server` with the main bootstrap file at [`apps/server/src/index.ts`](https://github.com/different-ai/openwork/blob/main/apps/server/src/index.ts). The server exposes APIs that the desktop client and external agents consume for centralized capability management.

To start the Den server locally with its dependencies:

```bash
pnpm dev:den

```

This command executes `scripts/dev-local.mjs`, which orchestrates Docker containers (including MySQL) via [`packaging/docker/docker-compose.web-local.yml`](https://github.com/different-ai/openwork/blob/main/packaging/docker/docker-compose.web-local.yml) before launching the server application.

## UI Component Library

**`@openwork/ui`** is a reusable React component library styled with shadcn principles. Both the desktop client and web interfaces import from this package to maintain visual consistency across the platform.

The library lives in `packages/ui` and exports components through [`packages/ui/src/react/index.ts`](https://github.com/different-ai/openwork/blob/main/packages/ui/src/react/index.ts). The package's [`package.json`](https://github.com/different-ai/openwork/blob/main/package.json) defines the export mappings that make components available to consuming applications.

To use the UI library in a React project:

```tsx
import { Button } from '@openwork/ui/react'

export default function Example() {
  return <Button onClick={() => alert('Hello')}>Click me</Button>
}

```

## MCP Client Integration

The **MCP (Model-Control-Plane) Client** wraps remote OpenWork endpoints, enabling any compatible AI agent—such as Claude Code or Cursor—to invoke OpenWork capabilities. This bridge component transforms OpenWork skills into callable functions for external LLMs.

Implementation resides in `packages/openwork-ui-mcp` with the entry point at [`packages/openwork-ui-mcp/src/index.ts`](https://github.com/different-ai/openwork/blob/main/packages/openwork-ui-mcp/src/index.ts). The client handles authentication, capability discovery, and execution requests against OpenWork servers.

To configure an external agent to use OpenWork:

```json
{
  "mcp": {
    "openwork": {
      "type": "remote",
      "enabled": true,
      "url": "https://api.openworklabs.com/mcp/agent",
      "oauth": {}
    }
  }
}

```

After adding this configuration, agents can call `search_capabilities` and `execute_capability` methods against the OpenWork ecosystem.

## Voice and Automation Layer

The **Hands-Free** package provides speech-to-text processing and command parsing, enabling voice-driven agent interactions. Located in `packages/handsfree`, this layer allows agents to receive commands through audio input rather than text prompts.

The entry point [`packages/handsfree/src/index.ts`](https://github.com/different-ai/openwork/blob/main/packages/handsfree/src/index.ts) exposes speech recognition pipelines and command routing logic. This component integrates with the desktop client to enable accessibility features and hands-free workflows.

To run the voice layer independently:

```bash
pnpm --filter @openwork/handsfree dev

```

## Skill Packages and Automations

Beyond the core infrastructure, OpenWork organizes functionality into **skill packages**—reusable automation modules that agents invoke. These include email processing, connect-link management, and enterprise MCP client implementations.

Each skill resides in its own `packages/*` directory with dedicated `src/` folders and [`package.json`](https://github.com/different-ai/openwork/blob/main/package.json) manifests. This modular approach allows developers to contribute new capabilities without modifying core platform code.

## Configuration and Workspace Tooling

Central configuration files define the monorepo structure and development workflows:

- **[`warden.toml`](https://github.com/different-ai/openwork/blob/main/warden.toml)** – Workspace configuration used by OpenWork's internal tooling for environment management
- **[`package.json`](https://github.com/different-ai/openwork/blob/main/package.json)** (root) – Defines workspace scripts (`pnpm dev`, `pnpm dev:worktree`) and dependency orchestration
- **[`AGENTS.md`](https://github.com/different-ai/openwork/blob/main/AGENTS.md)** – High-level architecture documentation describing the project's philosophy and agent interaction patterns

These files reside in the repository root alongside the `scripts/` directory, which contains automation helpers like `dev-local.mjs` for local server orchestration.

## Summary

- The **Desktop Client** ([`apps/desktop/main.ts`](https://github.com/different-ai/openwork/blob/main/apps/desktop/main.ts)) delivers the Electron-based local runtime with integrated CDP server support
- The **Den Server** ([`apps/server/src/index.ts`](https://github.com/different-ai/openwork/blob/main/apps/server/src/index.ts)) provides the cloud-native control plane for multi-user and enterprise configurations
- **`@openwork/ui`** ([`packages/ui/src/react/index.ts`](https://github.com/different-ai/openwork/blob/main/packages/ui/src/react/index.ts)) supplies reusable React components consumed across all interfaces
- The **MCP Client** ([`packages/openwork-ui-mcp/src/index.ts`](https://github.com/different-ai/openwork/blob/main/packages/openwork-ui-mcp/src/index.ts)) enables external AI agents to discover and execute OpenWork capabilities
- The **Hands-Free** package ([`packages/handsfree/src/index.ts`](https://github.com/different-ai/openwork/blob/main/packages/handsfree/src/index.ts)) adds voice control and speech-to-text processing
- **Skill packages** in `packages/*` extend functionality through modular, agent-callable automations
- **Root configuration files** ([`warden.toml`](https://github.com/different-ai/openwork/blob/main/warden.toml), [`package.json`](https://github.com/different-ai/openwork/blob/main/package.json), [`AGENTS.md`](https://github.com/different-ai/openwork/blob/main/AGENTS.md)) govern workspace structure and development workflows

## Frequently Asked Questions

### What is the entry point for the OpenWork desktop application?

The desktop application initializes through [`apps/desktop/main.ts`](https://github.com/different-ai/openwork/blob/main/apps/desktop/main.ts), which bootstraps the Electron process and starts the local CDP server for agent communication. This file handles window creation, protocol registration, and the local-first runtime environment that distinguishes OpenWork from purely cloud-based alternatives.

### How do external AI agents connect to OpenWork capabilities?

External agents connect through the MCP client implemented in [`packages/openwork-ui-mcp/src/index.ts`](https://github.com/different-ai/openwork/blob/main/packages/openwork-ui-mcp/src/index.ts). By configuring a remote MCP endpoint pointing to `https://api.openworklabs.com/mcp/agent` (or a local equivalent), agents gain access to `search_capabilities` and `execute_capability` methods that invoke OpenWork skills.

### Where is the OpenWork server logic located?

The server-side control plane, referred to as "Den," resides in `apps/server` with its bootstrap logic in [`apps/server/src/index.ts`](https://github.com/different-ai/openwork/blob/main/apps/server/src/index.ts). This Express-style server manages organizations, model provider configurations, and skill publishing through RESTful APIs consumed by both the desktop client and external integrations.

### What package manager does OpenWork use for its monorepo?

OpenWork uses **pnpm** for dependency management and workspace orchestration, as evidenced by the `pnpm dev`, `pnpm dev:den`, and `pnpm --filter` commands defined in the root [`package.json`](https://github.com/different-ai/openwork/blob/main/package.json). The workspace configuration enables efficient dependency sharing across the desktop app, server, and utility packages while supporting isolated development through filter commands.