OpenWork

Decouple skills, plugins, and MCP connections from the AI agent you happen to use

OpenWork's core idea is to keep reusable capabilities from being trapped inside one chat UI. The README documents adding the OpenWork MCP to Codex, Claude Code, Cursor, OpenCode, and other compatible agents so they can use assigned skills, plugins, MCP connections, Google Workspace, and Microsoft 365 capabilities.

The remote MCP exposes two tools, search_capabilities and execute_capability, for discovering and running available capabilities. The desktop app provides a dedicated workspace, but the README states that it is not required when you only want to use OpenWork from an agent you already have.

Sources: [2]

Combine an Electron desktop shell, React UI, and OpenCode SDK into one agent workspace

TypeScript is the repository's primary language. apps/app uses React and Vite and depends on the Model Context Protocol SDK and OpenCode SDK. The desktop shell uses Electron 43 and includes better-sqlite3 and terminal-oriented dependencies.

Release v0.18.48 improves live workflow authoring, generated apps, session recovery, and consistency across browser tabs, consent, and session origins, showing that OpenWork is evolving as a persistent agent workspace rather than a simple prompt launcher.

Sources: [6][7][3]

Use OpenWork Den as an organization control plane for capability distribution and access

OpenWork Den provides organization controls for members and teams, model-provider access, desktop policies, skill/plugin marketplaces, and remote MCP distribution.

Den is not part of the same MIT-licensed core as the desktop application. Evaluations should separate the MIT core used by individuals and small deployments from the ee/ control-plane functionality.

Sources: [2][5]

For teams using Claude Code, Codex, Cursor, and OpenCode that do not want to rebuild the same workflow in every tool

OpenWork fits environments where skills and MCP configuration are duplicated across AI coding or agent tools and where a shared workflow should move from one person's machine to a team. The key question is less whether you want another desktop UI and more whether you want a common capability layer that multiple agents can call.

Do not treat the whole repository as MIT: ee/ has a production-restricted EE License

The root LICENSE places the desktop application and core platform outside ee/ under MIT while OpenWork Den under ee/ is covered by the OpenWork EE License. GitHub therefore reports NOASSERTION instead of one SPDX license for the repository.

The EE License exempts production use by organizations with up to five users, internal evaluation for up to 30 days, and development/testing; other production use requires the appropriate subscription. Each version also receives an MIT future license two years after its first public release.

Sources: [4][5][1]

Remote MCP and Den mean the system is not purely local just because a desktop app exists

The documented OpenWork MCP endpoint is a remote server at api.openworklabs.com. Users sign in and select an OpenWork organization before using capabilities, so installing the desktop application does not imply that every workflow remains on the local machine.

For sensitive work, review the data boundary separately for each capability, connected service, model provider, and Den deployment, including authentication and retention.

Sources: [2]

The default branch is dev and releases move quickly, so pin versions when validating workflows

As of September 16, 2026 the default branch is dev, and v0.18.48 was published on September 15. Its release notes still include changes to workflow authoring, session recovery, and browser flows.

For team rollout, pin the desktop distribution and relevant OpenWork MCP/Den versions and regression-test important workflows before wider deployment.

Sources: [1][3]