Open Cowork: A Desktop Shell Around Claude Code, With WSL2 and Lima Sandboxing
Open-source AI agent desktop app for Windows & macOS. One-click install Claude Code, MCP tools, and Skills — with sandbox isolation, multi-model support, and Feishu/Slack integration.
At a glance
- What is it?
- Open Cowork is an MIT-licensed Electron app that puts a GUI on top of Claude Code, OpenAI-compatible endpoints and MCP connectors, and routes shell commands into a WSL2 or Lima VM. The interesting part is the isolation model; the weak part is verification, because the README does not document how the VM boundary is enforced.
- Who is it for?
- Adopt Open Cowork if you want a GUI over Claude Code on a single workstation and you are willing to run Lima or WSL2 so the shell path is isolated. Skip it if you need a headless agent for CI, or if your security review requires documented enforcement code rather than a README table.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is not the model, it is the setup between you and the model
Getting a coding agent to do useful work on a laptop is mostly installation work. You need a runtime, an API key, a set of tool connectors, and a folder the agent is allowed to touch. Open Cowork's pitch is that it collapses that into a downloadable installer for Windows and macOS. The README describes it as an open-source implementation of Claude Cowork with one-click installers, and the feature table positions it against Claude Cowork and OpenClaw on three axes: MCP and Skills support, remote control, and GUI operation. It claims all three, where the other two each claim a subset.
The intended user is someone who wants desktop automation without writing glue code. The README says no coding is required and lists document generation (PPTX, DOCX, XLSX, PDF), file organization, browser and Notion access through MCP, and control of desktop GUI applications. That is a wider brief than a code completion tool. It is closer to a general-purpose local agent with a chat window, which is also why the sandbox question matters more here than it would for an autocomplete plugin.
Two sandbox tiers, and the fallback is the one to watch
The security section is the most concrete part of the README and the part worth reading twice. It defines three levels. Basic is Path Guard on all platforms: file operations are restricted to the workspace folder. Enhanced on Windows is WSL2; when WSL2 is detected, the README states that all Bash commands are routed to a Linux VM and the workspace is synced bidirectionally. Enhanced on macOS is Lima: if Lima is installed, commands run in an Ubuntu VM with /Users mounted.
Then there is the fallback. If no VM is available, commands run natively with path-based restrictions only. That sentence changes the risk profile of the whole product. A user who installs the .dmg or .exe and never installs Lima or enables WSL2 gets the Basic tier, where a shell command is a shell command on the host, constrained by whatever path checks the app performs. The README does not describe how those path checks are implemented, whether they parse commands or intercept file APIs, or what happens with symlinks, subprocesses, or absolute paths outside the workspace. Until that is documented, treat the Basic tier as a convenience boundary, not a security boundary.
There is also a second, quieter caveat. Even in the VM tiers, the macOS configuration mounts /Users into the Ubuntu VM. Mounting your home directory means the isolation is about process and filesystem separation for the VM, not about hiding your files from the agent. The README's own warning says to exercise caution when authorizing file modifications or deletions, and notes that VM isolation does not remove all risk.
What actually runs: Electron, a Skills layer, and MCP connectors
The repository is TypeScript and the topics list electron, so the desktop shell is Electron. That is consistent with the install story: a .exe for Windows, a .dmg for Apple Silicon, and a Homebrew cask. The app is not a thin wrapper around a CLI in the sense of spawning a terminal and showing output. It has a Trace Panel for watching reasoning and tool execution, a Skills system with built-in workflows for document formats, and an MCP connector layer for browser, Notion, and custom apps.
Skills look like the mechanism that turns a general agent into something that produces a specific artifact. The README says custom skill creation and deletion are supported, which implies skills are files or records the user can add, not a fixed compiled list. It does not show the skill format, the directory they live in, or how a skill is invoked, so anyone planning to write their own should expect to read the source rather than the documentation.
Model support is a routing layer rather than a single provider. The README names Claude, OpenAI-compatible APIs, and Chinese models including GLM, MiniMax, and Kimi, configured with OpenRouter, Anthropic, or other API keys. For GUI operation it recommends Gemini-3-Pro. That recommendation is a model-level dependency, not an app capability, and it tells you the GUI automation path is sensitive to which model you point at it.
Install commands, and the Gatekeeper flag you should think about
The README gives three install paths. The recommended macOS route is Homebrew:
brew tap OpenCoworkAI/tap brew install --cask --no-quarantine open-cowork
The README explains the flag plainly: --no-quarantine bypasses macOS Gatekeeper so the "Apple cannot verify this app" warning does not appear. That is an honest disclosure and also a decision you are making on the project's behalf. The alternative is downloading the .dmg from the releases page and going through the normal first-launch prompt, which at least keeps the OS check in the loop.
For source builds the sequence is git clone, npm install, npm run rebuild, npm run dev, with npm run build producing an installer. Node.js 18 or later is the stated requirement. Note that npm run rebuild is a separate step from npm install, which usually means native modules need to be compiled against the Electron ABI. If that step fails on your machine, the failure will be in the native toolchain, not in the TypeScript.
Lima is installed separately, and the README gives the command: brew install lima. Nothing in the README states that the app prompts you to install it, so the Enhanced tier on macOS looks like something you opt into by installing Lima before or after the app.
Where Open Cowork is the wrong tool
The scope is a desktop workstation. There is no mention of a headless mode, a server deployment, or a CI integration. If you want an agent that runs on a build machine, reviews pull requests, or executes on a schedule without a logged-in GUI session, this is not that product, and the Electron dependency makes it unlikely to become one without a separate runtime.
The remote control feature is the closest thing to headless operation. Feishu (Lark) and Slack are named as channels for remote control, which means the app is still running on your machine and you are driving it from a chat client. That is a different architecture from a hosted agent service, and it inherits the same dependency on your laptop being awake.
There is also a platform gap. Windows and macOS are supported; Linux is not listed as a target, even though the sandbox on both platforms is a Linux VM. A Linux user would get the Basic tier at best, and the README offers no Linux installer.
Finally, the documentation thinness is itself a limitation. The README is strong on marketing tables and short on mechanism. There is no architecture diagram, no description of how the VM boundary is enforced, no skill file format, and no configuration reference beyond the install commands. For a tool that asks for permission to modify files and control desktop applications, that is a real gap, and it is the thing a cautious adopter should weigh against the convenience.
The alternative is not another GUI, it is the CLI you already have
The honest comparison is between Open Cowork and running Claude Code directly in a terminal. The CLI gives you the same model access, the same MCP server configuration, and a shell that is already inside whatever sandbox you choose. What it does not give you is a Skills layer with document generation, a trace panel, drag-and-drop multimodal input, or remote control from Feishu and Slack. If those are the features you actually want, the comparison is not close.
The more interesting comparison in the README's own table is OpenClaw, which it lists as supporting MCP and Skills plus remote control but not GUI operation. That is a meaningful split. Open Cowork's distinguishing claim is that it can drive desktop GUI applications, and the README ties that capability to a specific model recommendation. If you do not need GUI automation, you are paying the complexity cost of the Electron app and the VM setup for features a terminal-based agent already covers.
There is also the question of what "open-source implementation of Claude Cowork" means in practice. The MIT license means you can read, modify, and redistribute the code. It also means there is no warranty and no vendor obligation. The README's warning about file modifications is the project telling you, in its own words, that the responsibility sits with you.
Maintenance cost, release cadence and the licence
The release history shows v3.3.0-beta.9 in April 2026, v3.3.0 in April, and v3.3.1 in May, with the last push to the default branch in August 2026. That is a project in active development with a beta channel running ahead of stable releases. If you install a stable build, expect to reinstall periodically as new versions land, and expect the beta channel to contain features that have not settled.
Upgrade cost is mostly the app itself. The heavier dependency is the sandbox layer: WSL2 on Windows and Lima on macOS are separate pieces of software with their own update cycles, and a Lima or WSL2 change can affect whether the Enhanced tier works at all. The README describes the fallback to native execution as automatic, which means a broken VM integration degrades silently into the Basic tier rather than failing loudly. That is the maintenance risk to plan for.
The licence is MIT. That permits commercial use, modification, and redistribution, and it comes with no warranty. It says nothing about the models you connect to: your Anthropic, OpenRouter, or other API keys are governed by those providers' terms, not by this repository. Nothing here is legal advice; if you are deploying this inside a company, the API key handling and the data that passes through MCP connectors are the parts your review should cover.
Editorial conclusion
Adopt Open Cowork if you want a GUI over Claude Code on a single workstation and you are willing to run Lima or WSL2 so the shell path is isolated. Skip it if you need a headless agent for CI, or if your security review requires documented enforcement code rather than a README table. Before installing, verify three things: that WSL2 or Lima is actually detected on your machine, that the workspace folder you select is the one you meant, and how the project handles the Gatekeeper bypass implied by the Homebrew --no-quarantine flag.
Community notes