OpenWorker shipped in late July 2026. It is MIT-licensed, runs on your own machine, and takes your API key instead of selling you inference.
The pitch is narrow and worth repeating exactly: it is an agent that hands you finished work, not a chat transcript. A drafted document on disk. A Slack reply with the real numbers in it. A calendar that has actually been rearranged.
There are a lot of desktop agents right now. This post is about what makes this one structurally different, what state it is actually in, and how to get it running.
What it is in one paragraph
OpenWorker is a desktop app: a Tauri shell around a React UI, sitting on top of a local Python agent server. You give it an outcome ("prepare a customer brief from these three files and the Jira tickets"). It decomposes that into steps, reaches into your files, terminal, and connected SaaS apps, and produces an artifact. Before anything consequential happens - sending a message, running a shell command, writing to your calendar - it stops and asks.
The engine is built on aisuite, Ng's provider-agnostic LLM library. That matters more than it sounds like: OpenWorker is explicitly positioned as a reference implementation of what you can build on aisuite, so the codebase doubles as a worked example if you are building your own harness.
The four things that actually distinguish it
1. There is no OpenWorker inference service
You paste a key, or you point it at Ollama and use none at all. The curated list covers OpenAI, Anthropic, Google, plus OpenAI-compatible vendors like DeepSeek, GLM, Kimi, Qwen, MiniMax, Mistral, and Grok, plus open-weight models through Together and Fireworks. Roughly thirty models are marked as verified for tool-calling work; you can point it at any other model string and accept the risk yourself.
The practical consequence: your cost is your provider bill, and swapping models is a dropdown, not a migration.
2. The permission model is typed, not a confirmation dialog
This is the part I would actually read the source for. Most agent projects treat approvals as UI polish. OpenWorker classifies every tool call into one of four risk classes:
| Risk class | Meaning |
|---|---|
read |
No side effects |
write_local |
Mutates the workspace, path-scoped |
exec |
Runs commands |
external |
Side effects that leave your machine |
Five permission modes then decide what happens to each class. discuss and plan are read-only. interactive is the default and asks before writes, commands, and external actions. auto allows everything but stays path-scoped. custom auto-approves a list of tools you name.
Two design choices stand out. First, unattended runs do not raise the autonomy ceiling - they change where the human is reached. Prompts that would have appeared inline get routed to an inbox and the session suspends until you answer. The agent does not quietly gain permissions because you walked away. Second, standing "always allow" rules are restricted to the external class only. Shell commands ask every single time, on purpose.
3. It has an explicit prompt-injection posture
The shipped operator persona instructs the model to treat content coming from tools, logs, web pages, files, and incoming messages as untrusted data, not as instructions. That is written into the persona the app ships with, rather than being left as an exercise for the user. For an agent that reads your Slack and your inbox, this is not optional, and it is good to see it stated rather than assumed.
4. Local-first is close to literal
Conversations, connector tokens, and model keys live in a local secret store. Model calls go straight from your machine to whichever provider you configured. The only cloud component is a small optional broker that handles OAuth handshakes for one-click connectors, and tokens are handed to your machine rather than stored server-side. You can skip sign-in entirely and wire up connectors with manually created credentials.
What it can do out of the box
- Real deliverables - documents, spreadsheets, reports, web pages, written to disk as files you can open.
- 25+ connectors - GitHub, Slack, Jira, Notion, Linear, HubSpot, Outlook, monday.com, Gmail, Google Calendar, and more, plus your terminal and local filesystem. Anything reachable over MCP plugs in too, with per-tool control.
-
Slack as an entry point - mention
@OpenWorkerin a channel, a session opens on your desktop, the work runs with your local tools, and the answer comes back as a thread reply. - Scheduled automations - morning briefs, weekly reports, a standing watch on a channel. Runs land in the app with full transcripts.
Setup
Option A: install the app (five minutes)
- Download from the repo's release links: macOS (Apple Silicon), macOS 12+, signed and notarized, auto-updating. Or Windows 10/11 x64 - note that Windows builds are not code-signed yet, so SmartScreen will warn you.
- Open the app and add a model key, or point it at a running Ollama instance.
- Give it a real task. Not "hello" - something with a file attached and a defined output.
Leave it in interactive mode for the first few sessions. Watching what it asks permission for is the fastest way to build an accurate mental model of what it is doing.
Option B: run from source
Prerequisites: Python 3.10+, Node 20+, and the Rust toolchain via rustup if you want the desktop shell rather than the browser UI.
git clone https://github.com/andrewyng/openworker
cd openworker
# 1. One-time bootstrap - creates the Python venv at .venv
# On Windows, run this from Git Bash or WSL
bash packaging/setup_dev_env.sh
# 2. Start the local agent server
.venv/bin/openworker-server --cwd ~/some/project --port 8765
# Windows: .venv\Scripts\openworker-server.exe
Then in a second terminal:
cd surfaces/gui
npm install
npm run dev # browser UI on the Vite dev port
For the full desktop app instead of the browser UI, replace that last step with npm run tauri dev from surfaces/gui/. The Tauri shell launches the window and supervises the Python server itself, so you can skip step 2 in that case.
The server is FastAPI on uvicorn, bound to 127.0.0.1:8765 by default.
Running the tests:
.venv/bin/pytest # backend
cd surfaces/gui
npm test # GUI unit tests
npm run e2e # hermetic end-to-end
Note the --cwd flag on the server. That is the workspace root the agent's path-scoped file access is anchored to. Point it at a scratch directory for your first runs, not at your home folder.
Where to look in the code
| Directory | Contents |
|---|---|
coworker/ |
Python backend - agent engine, model providers, connectors, MCP client, memory, automations |
surfaces/gui/ |
React UI plus the Tauri shell |
stt/ |
Rust speech-to-text sidecar for voice input |
packaging/ |
macOS DMG and Windows installer builds, auto-update manifest |
docs/ |
Design specs and decision logs |
tests/ |
Backend test suite |
If you are here to learn rather than to use, docs/ and the permission engine in coworker/ are the highest-value reads. The design logs explain choices rather than just documenting APIs.
Is it worth looking into?
Yes, if any of these describe you:
- You want a desktop agent that touches real work systems but you are unwilling to hand a vendor your Slack tokens and your filesystem.
- You are building an agent harness and want a substantial, production-shaped reference for permission gating, connector management, and MCP integration. Roughly 32k lines of Python with 78 backend test modules is a real codebase to learn from, not a demo.
- You have compliance constraints that rule out hosted agents. Local-first plus BYO-key plus MIT is a rare combination.
- You want to run agents against fully local models. The Ollama path needs no key at all.
Hold off if:
- You need stability. This is v0.1.x, self-labeled open beta, with a handful of contributors and a repo that is days old. It auto-updates, which is convenient and also means the thing under you moves.
- You expect a coding agent. It works with your terminal and files, but the framing is knowledge work - briefs, reports, inbox triage, calendar - not writing your service.
The honest summary
The interesting claim here is not "agent that does tasks." Everyone is shipping that. The interesting claim is that the boring infrastructure - who is allowed to do what, where secrets live, what counts as an instruction versus data - has been designed as a typed system rather than bolted on. That is the part worth reading even if you never use the app.
It is early. Expect rough edges, expect the Windows signing situation to resolve, expect the connector list to shift. But if you have been waiting for a credible open, local, model-agnostic option in this category, this is the first one that looks like it was built by people who thought about the failure modes first.
Repo: github.com/andrewyng/openworker
Site: openworker.com
Top comments (0)