OpenWork: an open-source desktop app and MCP server for sharing AI workflows

What OpenWork solves and who it is aimed at

The problem OpenWork targets is not agent capability. It is the duplication that follows once you have more than one agent. A skill you wrote for Claude Code does not exist in Cursor. An MCP connection you configured in Codex has to be configured again on your laptop at home. The README frames the product as "a free, open-source desktop app made for sharing AI workflows" and positions it as an open-source alternative to Claude Cowork and Codex.

The intended user is someone who already has an agent and wants their configuration to be portable. The README states that the desktop app is optional: "You can use OpenWork from the agent you already have." That single sentence defines the audience. If you want a self-contained workspace, install the app. If you want your existing agent to pick up shared capabilities, add the MCP and skip the app entirely.

The second audience is organizational. OpenWork Den, described in the README as "the control plane for managing OpenWork across a team or organization," handles provisioning inference, inviting teammates, setting desktop policies, and publishing skills and plugins through marketplaces that can be assigned to the whole organization, a team, or specific people. That is a different buyer with a different budget.

The MCP is the product, the desktop app is the wrapper

The architecture is easier to understand if you treat the MCP server as the centre and the Electron app as one possible client. The README describes the OpenWork MCP as bringing "your assigned skills, plugins, MCP connections, Google Workspace, and Microsoft 365 capabilities into any compatible agent." It exposes exactly two tools: `search_capabilities` finds what you can use, and `execute_capability` runs it.

That two-tool surface is a deliberate constraint. Instead of every capability becoming its own tool in your agent's context window, there is one discovery call and one execution call. After adding the MCP, the README says your client opens a browser so you can sign in and choose your OpenWork organization. So the flow is: agent calls `search_capabilities`, the server returns what your account is entitled to, the agent calls `execute_capability`, and the server performs the work against whatever connections were configured.

Den sits behind that. It publishes skills and plugins, assigns them by scope, and imports "Agent Plugins or Anthropic-compatible plugins" so their supported skills and remote MCPs become reachable through the same OpenWork MCP. The consequence is that capability resolution happens server-side, not in your local config files. One trade-off follows immediately: if the network or the OpenWork API is unavailable, the agent has no capabilities to search. The README does not document an offline fallback for the MCP path.

Installing OpenWork and running your first capability

There are two entry points. The README offers a prompt to paste into any agent that can run commands on your computer, which it says will install OpenWork, create your workspace, and open it ready to run:

Install OpenWork on my computer, set up my first workspace, and open it ready to use. Follow the steps in https://openworklabs.com/start.md?v=hero

If you would rather not let an agent drive the install, the README points to a download page at https://openworklabs.com/download. The repository does not list a package manager command for the desktop app, so the download page and the agent prompt are the documented routes.

For the MCP path, register the remote server with your existing client. The README gives a one-liner for Codex:

codex mcp add openwork --url https://api.openworklabs.com/mcp/agent

Claude Code uses a slightly different form because it needs the transport specified:

claude mcp add --transport http openwork https://api.openworklabs.com/mcp/agent

OpenCode is configured through a file instead. The README says to add this to `opencode.json`:

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

Any other MCP client uses the same remote URL, `https://api.openworklabs.com/mcp/agent`. After registration, the client should open a browser for sign-in and organization selection. What you should see next is your agent exposing `search_capabilities` and `execute_capability` as callable tools; if the browser step never appears, the OAuth handshake did not complete and no capabilities will resolve.

The directory-split licence is the real adoption decision

The README describes a directory-split licence "similar to GitLab." Everything outside `ee/` is MIT and free for any use, which covers the desktop app and what the README calls the core platform. Everything under `ee/` is the OpenWork Den control plane, released under the OpenWork EE License, which the README calls a source-available licence.

The practical terms matter more than the label. Production use of `ee/` requires an OpenWork subscription, with three carve-outs stated in the README: free for organizations with up to 5 users, free to evaluate for 30 days at any size, and always free for development and testing. Each `ee/` release also converts to MIT two years after publication. Versions released before this licence was adopted remain under FSL-1.1-MIT.

Read that carefully before you plan a deployment. A five-person team can run Den in production at no cost. A fifty-person team cannot, unless it is inside the 30-day evaluation window or running only outside `ee/`. The two-year conversion means the code you deploy today becomes MIT eventually, but not on a timeline that helps a current rollout. This is a licensing structure question, not a legal one, and the repository's own `ee/LICENSE`, the pricing page and the subscription terms are the documents to read rather than this summary.

Where OpenWork is the wrong tool

The clearest limitation is the one the README states plainly: the MCP depends on a hosted endpoint at `api.openworklabs.com`. There is no documented self-hosted alternative for the agent-facing MCP URL. If your skills touch data that cannot leave your network, or if your organization forbids third-party OAuth flows, the MCP path is closed to you regardless of how permissive the MIT portion is.

The second limitation is licence scope. Teams that read "open source" and assume the whole product is MIT will be surprised by `ee/`. Den is the part that does provisioning, team management, desktop policies and marketplace assignment, which is exactly the part a mid-size company wants. You get the desktop app and core platform under MIT; you rent the control plane.

Third, this is young software. The most recent release listed is v0.18.39 from 2026-08-27, and the version number tells you the API surface is still moving. The README documents the MCP configuration and the local development workflow but does not document rollback, migration between releases, or what happens to published skills when an organization downgrades or leaves. If you need a stable interface contract before you build on top of it, that contract is not in the README.

Finally, the local development story is heavier than the install story. `dev:worktree` exists specifically because running multiple worktrees at once needed profile isolation, mock keychain defaults and dynamic port selection. That is a good sign for the maintainers and a warning for anyone planning to fork and modify the desktop app.

OpenWork compared with wiring each agent separately

The obvious alternative is doing nothing: configure skills and MCP servers independently in Claude Code, Cursor and Codex, and accept that each one drifts. That approach has real advantages. Nothing sits between your agent and your credentials, there is no hosted endpoint in the path, and no licence governs your configuration files. The cost is duplication, and it grows with team size.

A closer alternative is a plugin or skill format tied to a single vendor. Anthropic-compatible plugins are explicitly supported by Den, which the README notes can be imported so their supported skills and remote MCPs become available through the OpenWork MCP. So OpenWork is not really competing with the plugin formats; it is competing with the act of installing them separately in each client.

The difference in approach is where capability resolution lives. Per-client configuration resolves locally, per machine, per agent. OpenWork resolves server-side against your organization membership, which is what makes sharing work and also what makes the network a dependency. If your team is one person on one machine, the per-client approach is simpler and you lose nothing. The crossover point is roughly when the second agent or the second machine appears.

Running OpenWork locally for development

The repository is a pnpm workspace with Turbo, and the root `package.json` shows the entry points. A single checkout uses `pnpm dev`, which the README says reuses the existing shared dev profile when no extra environment variables are set. Multiple git worktrees need the other script:

pnpm dev:worktree

The README states that this sets `OPENWORK_DEV_PROFILE=auto`, derives a stable profile name from the worktree path, lets Electron choose a free CDP port, and asks Vite for a free dev-server port. It also defaults `OPENWORK_ELECTRON_USE_MOCK_KEYCHAIN=1`, with the stated reason that a brand-new profile has no stored credentials and on macOS the real keychain prompts as soon as Chromium persists an authenticated cookie, blocking Electron's main loop until dismissed.

There is also a headless mode for running the UI in a browser against a local `openwork-server`, without the desktop shell:

pnpm world up ./worlds/dev-headless.ts

The README describes this as an isolated launcher that writes `tmp/headless-server.json`, never reads `~/.config/openwork/server.json`, authorizes the chosen workspace root automatically, and defaults to ports 5178 for the web app and 8778 for the server, overridable with `OPENWORK_WEB_PORT` and `OPENWORK_PORT`. It publishes agent-facing URLs and tokens to `tmp/dev-headless-web.json` with `0600` permissions. If you are evaluating OpenWork rather than deploying it, this is the path that avoids installing the desktop app at all.

Editorial conclusion

Adopt OpenWork if you already run an MCP-capable agent and want your skills, plugins and Google Workspace or Microsoft 365 connections to follow you across clients and machines; the one-line MCP registration is the cheapest way to find out. Do not adopt it if you need a fully permissive licence for an organization control plane, because everything under ee/ requires a subscription above five users, or if you want a single-vendor stack with no remote service in the loop. Before committing, verify which release tag you are actually pulling, whether the Den features you need live in ee/, and whether the MCP endpoint at https://api.openworklabs.com/mcp/agent is acceptable for the data your skills touch.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes