Open Cowork: a desktop GUI for Claude Code with WSL2 and Lima sandboxing

The gap Open Cowork fills between a terminal agent and a non-technical user

Claude Code is a command-line tool. Open Cowork's README frames the project as an open-source implementation of Claude Cowork, and the problem it targets is the setup step: getting a coding agent, its model credentials, its tool connectors and a sandbox onto a laptop without asking the user to edit config files. The README states that the app ships pre-built installers for Windows and macOS and that no environment setup is needed.

The intended audience is not a backend engineer. It is someone who wants an agent to reorganize a folder, produce a PPTX from a set of source files, or drive a desktop application through the GUI, and who would otherwise be blocked by the installation. The feature table in the README positions Open Cowork against Claude Cowork and against a project it calls OpenClaw: all three are marked as supporting MCP and Skills, only Open Cowork and OpenClaw are marked for remote control, and only Open Cowork is marked for GUI operation.

That last column is the differentiator the project is selling. The README recommends Gemini-3-Pro specifically for GUI understanding and control, which is an admission that the capability depends on the model you plug in rather than on the app alone.

How the sandbox, Skills and MCP layers actually fit together

The architecture visible in the repository is an Electron application (the package is named open-cowork, the entry point is dist-electron/main/index.js, and the build runs through Vite and electron-builder) with a sandbox layer underneath it. The README describes three protection levels. Basic is a path guard available on all platforms: file operations are restricted to the workspace folder. Enhanced on Windows routes Bash commands into a WSL2 Linux VM, and Enhanced on macOS routes them into a Lima Ubuntu VM with /Users mounted. The README states that the workspace is synced bidirectionally in the WSL2 case, and that when no VM is available commands fall back to running natively with path restrictions only.

That fallback is the most important sentence in the security section. The app does not refuse to run without a VM; it degrades. The README labels VM setup as optional and recommended, which means a user who never installs Lima on macOS is running the agent against the host filesystem with nothing but path checks between it and the rest of the disk.

The Skills system is the second layer. The README describes built-in workflows for generating and processing PPTX, DOCX, PDF and XLSX, and says custom skills can be created and deleted. MCP connectors are the third: browser, Notion and custom applications are named as integrations, and the README describes a Trace Panel that shows reasoning and tool calls as they execute. The build scripts confirm the MCP bundling is a real compilation step (npm run build:mcp runs scripts/bundle-mcp.js), and the sandbox agents for WSL2 and Lima each have their own TypeScript build target.

Installing Open Cowork on macOS, Windows and from source

The README gives three installation paths. On macOS the recommended route is Homebrew through the project's own tap. The --no-quarantine flag is documented as bypassing Gatekeeper so the "Apple cannot verify this app" warning does not appear, which is worth understanding before you type it: you are telling macOS to skip the signature check on a downloaded application.

brew tap OpenCoworkAI/tap
brew install --cask --no-quarantine open-cowork

On Windows and on macOS Apple Silicon the alternative is a download from the Releases page, where the README lists .exe for Windows and .dmg for macOS. Building from source is documented for contributors. Note that package.json declares Node.js >=22 while the README badge says Node.js 18+, so trust the engines field.

git clone https://github.com/OpenCoworkAI/open-cowork.git
cd open-cowork
npm install
npm run rebuild
npm run dev

The first real configuration step is credentials. The repository ships .env.example with the keys commented out. Uncomment and fill them to point the app at an endpoint.

ANTHROPIC_AUTH_TOKEN=your_api_key_here
ANTHROPIC_BASE_URL=https://openrouter.ai/api
CLAUDE_MODEL=anthropic/claude-sonnet-4.5

The file also documents CLAUDE_CODE_PATH for a custom Claude Code CLI location, with a warning to use forward slashes on Windows rather than backslashes. After that, the README's own next step is the optional but recommended VM: on macOS, brew install lima. A first real use would be pointing the app at a workspace folder and asking it to generate an XLSX or PPTX, which the README demonstrates in its video section.

Where Open Cowork is the wrong tool, and what the README does not say

The clearest limitation is platform coverage. The README and the package description both scope the app to Windows and macOS. There is no Linux installer in the download table and no Linux row in the sandbox table. People searching for open cowork linux will not find an answer here.

The second limitation is the fallback behaviour described above. Calling the sandbox "multi-level" is accurate, but the default level on a machine without WSL2 or Lima is the weakest one, and the README does not document what the app tells the user when it drops to that level, nor whether it warns at all. The README is likewise silent on rollback: there is no documented undo for a file the agent deletes, and the disclaimer at the top of the README explicitly asks users to be cautious when authorizing file modifications or deletions. A sandbox protects the host system from a runaway command; it does not protect the workspace files the agent was pointed at.

The third is model-dependent behaviour. GUI operation is the headline feature, and the README's own recommendation of a specific model for it implies that a weaker or cheaper model will perform worse at the same task. Nothing in the README quantifies that gap.

Finally, maintenance: the last push to the default branch was on 2026-08-03, and the most recent release listed is v3.3.1 from 2026-05-23. That is a recent push but a release cadence measured in months, so treat the project as moving but not fast.

Open Cowork compared with running Claude Code or Eigent directly

The obvious alternative is Claude Code in a terminal. The difference is not capability but surface: Claude Code gives you a shell, and Open Cowork gives you a window with a Trace Panel, drag-and-drop multimodal input, a Skills menu and MCP connectors configured through the UI. If you are already comfortable in a terminal, the wrapper adds a layer you have to keep updated. If you are not, the wrapper is the entire value.

Eigent is the other comparison that comes up in search data. Both are open-source desktop agents, and the README does not contain Eigent's architecture, so the honest difference to draw is the one Open Cowork documents about itself: VM-level command isolation through WSL2 and Lima, plus remote control through Feishu (Lark) and Slack. A team whose workflow already lives in Feishu has a concrete reason to look at this project rather than a generic agent shell. A team that wants the agent to touch a browser or Notion should evaluate the MCP connector path, because that is where the README places the extensibility story.

One more comparison is worth stating plainly. The README's own feature table marks Claude Cowork as lacking remote control and GUI operation. If those two columns are what you need, the open-source version is not merely a free substitute; it is the only one of the three listed that claims the full set.

Licence, upgrade cost and what the MIT terms do not cover

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the permissive end of the spectrum and it means you can fork the Electron shell or ship it internally without a legal review cycle. This is not legal advice; read the LICENSE file in the repository for the operative text.

The licence does not transfer any obligation away from you regarding the models. Open Cowork is a client. Your API keys, your provider's terms of service and your provider's data handling policy apply to whatever the agent sends, and the README's model list (Claude, OpenAI-compatible endpoints, GLM, MiniMax, Kimi) implies you may be routing prompts to several different vendors depending on configuration.

Upgrade cost is the usual Electron problem plus a sandbox problem. The build pipeline downloads a Node runtime, compiles WSL2 and Lima agents, bundles MCP servers and then packages with electron-builder. A user on the Homebrew path gets upgrades through brew upgrade; a user on the installer path has to re-download. The version that matters is the one in package.json, currently 3.3.1, and the CHANGELOG.md at the repository root is where the project records what changed between them.

Editorial conclusion

Adopt Open Cowork if you want a graphical agent workspace on Windows or macOS and you are willing to install WSL2 or Lima so shell commands run inside a VM rather than on the host. Do not adopt it if your team is standardized on Linux, because the repository lists no Linux installer and the sandbox table covers only Windows and macOS. Before trusting it with real files, verify three things: that your chosen model endpoint answers through the ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN variables in .env.example, that the sandbox level shown in the app says Enhanced rather than Basic, and that a test run of a destructive command lands inside the VM. The MIT licence removes the redistribution question, but the disclaimer in the README still puts file modification and deletion risk on you.

Frequently asked questions

Official sources

1. License: MIT
2. OpenCoworkAI/open-cowork on GitHub
3. Project website
4. README
5. Releases