Open Cowork's recommended install switches off Gatekeeper, and its sandbox falls back to the host

The recommended Homebrew command asks you to switch off Gatekeeper

The macOS install is two commands, and the second one carries a flag the readme explains in a note:

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

The note says the `--no-quarantine` flag bypasses macOS Gatekeeper, so you will not see the warning that the app cannot be verified.

That flag does not change anything inside the application. It removes the quarantine attribute macOS places on downloaded files, which is the attribute that causes the operating system to check the binary before running it. Removing it means the check does not happen for this app, on this machine, for as long as the installation stands.

The context is worth stating so the fact is not read as more alarming than it is. The project is MIT licensed, open source, has a `SECURITY.md`, a code of conduct, a changelog and a contributing guide, and publishes both a signed-looking cask path and plain installers. None of that is notarisation. Signing your code is not the same as having Apple verify it, and a distribution that has not been through that process is exactly the case Gatekeeper exists for.

So this is a project decision, stated plainly rather than hidden, that a user is asked to accept. Worth reading the release notes before running it, and worth knowing that the flag is optional.

VM isolation is optional, and the stated fallback is running natively

There is a table of three levels. Basic applies on all platforms and is a path guard, restricting file operations to the workspace folder. Enhanced on Windows uses WSL2, with commands executing in an isolated Linux VM. Enhanced on macOS uses Lima, again with commands executing in an isolated Linux VM.

Then there is the line that decides what your protection actually is: if no VM is available, commands run natively with path-based restrictions.

So the enhanced tier is not a setting. It is detected. WSL2 is auto-detected on Windows if installed. Lima is auto-detected on macOS if installed, with the note that the application will create and manage a VM itself, named internally `claude-sandbox`. If neither is present, there is no prompt, no warning and no refusal; the commands simply run on your machine, constrained only by a path guard.

That sits in tension with the feature list, which claims VM-level isolation where all commands execute in an isolated VM to protect the host system. Both cannot be true for a user who has not installed a virtual machine, and the configuration section is the one describing actual behaviour.

The heading over the setup is telling: optional, recommended. Optional and recommended are not the same, and the fallback is the branch that fires for anyone who skipped the recommendation.

The macOS VM mounts /Users, which is more than the basic tier restricts

The Windows and macOS branches differ in one way that matters more than it looks.

On Windows, when WSL2 is detected, all Bash commands are routed to a Linux VM and the workspace is synced bidirectionally. The scope of what crosses the boundary is the workspace.

On macOS, when Lima is installed, commands run in an Ubuntu VM with `/Users` mounted. That is the user's entire home directory, not the workspace folder.

Set that beside the basic tier's stated guarantee, which is that file operations are restricted to the workspace folder, and the ordering inverts. The tier described as enhanced exposes more of your filesystem than the tier described as basic.

There is a reasonable reading in which this is deliberate. A home directory mount is what makes an agent useful on a desktop, since documents and downloads live outside any one project folder, and a VM boundary around them is arguably better than nothing. But it is a widening of scope relative to what the path guard claims, and the table presents the two tiers as strictly increasing in protection rather than differing in kind.

If the path guard is the control you care about, the question to ask is which tier is active on the machine you are about to point this at, not which one the documentation calls recommended.

Every value in the environment template is commented out, including the required one

The environment example at the repository root is short, and its structure is more informative than its contents.

There are four documented variables. An authentication token, which is marked as required, setting the API authentication token. A base URL, marked optional, with an example value pointing at an OpenRouter endpoint. A model selection, marked optional, with an example naming an Anthropic model through a router-style path. And a path to the Claude Code CLI, marked optional, with a comment that matters on Windows: use forward slashes rather than backslashes.

Every one of those assignments is commented out, including the one labelled required. So copying the file as-is gives you a template with no active configuration in it, and the token you need is not merely empty but commented.

The shape of the names is the other observation. An application whose readme lists Claude, OpenAI-compatible APIs, and Chinese models including GLM, MiniMax and Kimi, and which names OpenRouter and Anthropic as the two key providers, has an environment file expressed entirely in Anthropic vocabulary. That is a deliberate compatibility choice, since an Anthropic-shaped interface with a swapped base URL is the cheapest way to serve many providers through one code path. It also means a user of a non-Anthropic provider is filling in a variable called `ANTHROPIC_AUTH_TOKEN`, which is a small thing to get wrong.

The dev and build scripts prepare different things

The script definitions are where the shape of this codebase shows. A development run is a chain of five steps: a script that downloads a Node build, a TypeScript compile of the WSL agent project, a TypeScript compile of the Lima agent project, a script that bundles the MCP server, and then Vite.

A production build is longer and not a superset. It starts with the same download and the same two agent compiles and the same MCP bundle, then adds a GUI tools preparation step and a Python preparation step that the development script does not have at all, then TypeScript, then the Vite build, then a pre-build check script, and only then the packaging step.

Two observations follow. First, the two sandbox agents are separate TypeScript projects with their own tsconfig files under the sandbox directory, compiled independently, which is what lets the Windows and macOS isolation paths share a protocol rather than a codebase. Second, there are two development variants and only one of them prepares Python, so a developer who needs the Python side has to know to use the other one.

The Node download is its own small oddity. The project requires Node 22 or newer on your machine and pins one in a version file at the root, and the first step of every build is a script that fetches a different Node. That is presumably for the packaged runtime, and it means a build depends on reaching a download at build time.

The packaged entry point is also compiled output, with the main field pointing into a built Electron directory rather than at source.

The comparison table already has an empty cell, and the demo is five bare links

The feature section opens with a comparison of three projects across three capabilities: MCP and skills, remote control, and GUI operation. Claude Cowork is marked as having the first and neither of the other two. OpenClaw has the first two and the third cell is empty rather than marked. Open Cowork has all three.

So the table that establishes the project's differentiation already contains an inconsistency, in the row of the competitor rather than its own. It is a small thing and it is the kind that appears when a table is maintained by hand, which is worth knowing when you read the rest of the table as a claim.

The demo section is five hosted video links under five headings, each one a bare URL. Folder organisation and cleanup, generating a presentation from files, generating spreadsheets, GUI operation, and remote control through Feishu. There is no description of what any of them show, no timestamps, and no transcript, so the demonstration of the capability that the table above claims as unique is a video you have to watch to evaluate.

One small artefact sits in the same section: the GUI operation heading has its emoji attached to the word with no space, where the other four have one.

The model list mixes vendors and routers, and recommends a third vendor for GUI work

Model support is described as Claude, OpenAI-compatible APIs, and Chinese models including GLM, MiniMax and Kimi, configured with OpenRouter, Anthropic or other API keys. The quick start names OpenRouter, Anthropic, and various cost-effective Chinese models as the supported providers.

That is two different taxonomies in one sentence. One axis is model vendors, the other is routing layers, and OpenRouter is a router while Anthropic is a vendor that also happens to expose an Anthropic-shaped endpoint. A user deciding what to put in a base-URL field has to work out which category each name falls into.

Then there is the GUI recommendation, which introduces a third axis entirely. For GUI operation the readme names Gemini-3-Pro as the recommended model for GUI understanding and control. So the most demanding capability is pointed at a different vendor from the two the project names as its key providers.

That is a reasonable engineering position and probably reflects what the computer-use path was tested against. It is also undocumented as reasoning on this page: there is no explanation of why that model is recommended, and no note about whether the same recommendation holds for the other capabilities, where the underlying model of Claude Code is still doing the work.

Editorial conclusion

Open Cowork is worth evaluating if you want a desktop agent with a document-generation Skills system and MCP connectors, and you are willing to decide the isolation question yourself rather than inherit it. Three things to settle first. The install path, because the recommended Homebrew command passes --no-quarantine, which stops macOS Gatekeeper from checking the application at all, and that is a decision about your machine rather than a feature of the project, so read the release notes and the SECURITY.md before applying it. The isolation level, because the feature list says all commands execute in an isolated VM while the configuration section says that when neither WSL2 nor Lima is present they run natively on the host with path restrictions, so the protection you actually get depends on what happens to be installed. And what the VM can see, because the macOS path mounts /Users, which means the enhanced tier exposes your whole home directory while the basic tier's stated guarantee is restriction to the workspace folder. Two smaller notes. Every value in the environment template is commented out, including the one marked required, so configure it by hand. And the development and build scripts have different prerequisite chains, so a dev run and a packaged build do not prepare the same things.

Frequently asked questions

Official sources

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