# ClawWork: a desktop client that turns agent sessions into durable tasks > ClawWork is an Electron and React desktop client for the OpenClaw agent runtime, structured around tasks rather than chat threads, with isolated parallel sessions, artifacts written into a local Git repository, scheduled runs and a three-panel interface. It suits someone running several agents at once, and the detail to understand first is that the model is local-first, with SQLite and Git holding the state instead of a messaging service. **clawwork-ai/ClawWork** — Client for OpenClaw — Connect ClawWork to your own OpenClaw and unlock 10x multi-session productivity. - Repository: https://github.com/clawwork-ai/ClawWork - Website: https://clawwork-ai.github.io/ClawWork/ - Stars: 533 · Forks: 72 - Language: TypeScript - License: Apache-2.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/clawwork-ai-clawwork ## The argument for an operator layer ClawWork describes itself as the local-first workspace for the Agent OS era, and it is a desktop client for OpenClaw. The reasoning behind it is stated plainly in the Why section. Agents are multiplying, and the bottleneck is no longer capability, it is the operator surface. That is the claim worth examining, because it is a claim about the interface rather than about the model. As agent runtimes proliferate, users end up juggling sessions across chat windows, web UIs and terminals, each with its own context and no shared memory. The analogy the project draws is that IDEs became the operator layer for code and terminals for Unix, and the Agent OS needs a workspace layer in the same way. So the argument is not that agents got worse or that OpenClaw is insufficient. It is that a human supervising several agents at once needs somewhere to see them all, and a chat window is the wrong shape for that. The specific diagnosis is about what happens when you use chat for long-running agent work. Once you have multiple sessions, long-running jobs, approval stops, generated files, recurring automation and different gateways, chat history turns into mud. Status vanishes, files vanish, context vanishes. That is a precise list, and each item on it is a way chat fails. Status vanishes because a chat thread has no notion of what a task is currently doing. Files vanish because generated output lands in a message and is then buried. Context vanishes because there is no shared memory between sessions, so a second agent cannot know what the first one found. ClawWork's answer is to make every task a durable workspace with its own session, artifacts, controls and history, laid out in a three-panel UI with tasks on the left, active work in the centre, and artifacts and context on the right. The project is Apache 2.0 licensed, the primary language is TypeScript, the default branch is main, and the last push was on 2026-08-24. The releases are v0.0.16 from 2026-05-16, v0.0.15 from 2026-05-10 and a v0.0.15-beta.4 pre-release from 2026-04-28, so the version is still in the zero range and the release cadence is regular. One practical note before going further: the README carries a warning about an official repository, saying a copycat repository and a website have been found without proper attribution. The canonical project is clawwork-ai/clawwork and the site is clawwork-ai.github.io/ClawWork, and the README also links the PWA at cpwa.pages.dev separately. ## How it compares to a messaging channel The README includes a table comparing ClawWork with Feishu, DingTalk and Slack, and it is the sharpest statement of the product's position. On layout, the messaging channels give you a single chat thread while ClawWork gives a three-column arrangement of task list, conversation and progress panel. On multi-task, a messaging channel handles one conversation at a time, while ClawWork runs parallel tasks in isolated sessions. On tool calls, they are hidden or text-only in a messaging channel, whereas ClawWork offers real-time visualisation with expandable details. This one matters more than it first appears, because an agent's tool calls are the observable evidence of what it did, and a chat transcript renders them as a wall of text or hides them entirely. On artifacts, they are lost in chat history in a messaging channel, while ClawWork auto-saves them to a local Git repository where they are searchable. Searchability is the operative word. A Git repository of generated files is something you can grep, diff and browse, and a folder of attachments in a chat client is not. On progress, a messaging channel has no structured tracking, while ClawWork has a step-by-step progress panel. On data ownership, a messaging channel puts your data on third-party servers, while ClawWork is 100 percent local with SQLite and Git. That last row is the one that matters most for anyone whose agent work touches confidential material, and it follows from the architecture rather than being a policy choice. The README is careful about where the product is today and where it is going. It is building that layer, starting as the best-in-class client for OpenClaw and extensible toward a multi-runtime future. So the OpenClaw focus is a starting point, not a commitment, but the multi-runtime support is future tense and should be treated as such when you evaluate it. The framing of the comparison is also a positioning choice worth noting. The alternatives named are workplace messaging platforms rather than other agent clients, which sets the benchmark as the thing people use when they want an agent to talk to them at work, where the friction of a dedicated tool has to be justified. ## Quick start and the task-first workflow The quick start is five steps, and the first one tells you what this is a client for. Start an OpenClaw Gateway. Open ClawWork and add a gateway in Settings, authenticating with a token, a password or a pairing code, with the default local endpoint at `ws://127.0.0.1:18789`. Create a task, pick a gateway and an agent, and describe the work. Chat, sending messages, attaching images, using `@` files for context or using `/` commands. Then follow the task as it runs, inspect tool activity and keep the output files. The default endpoint being a local WebSocket address tells you the normal deployment, and the three authentication methods tell you the range. A token or a password is what you would use against your own gateway, and a pairing code is what you would use against a remote one you are granting access to. The feature list under the task-first heading is where the detail sits. Parallel tasks with isolated OpenClaw sessions, and archived tasks can be reopened later. Per-gateway session catalogs, so the sessions belonging to one gateway are listed together. Session controls that matter, namely stop, reset, compact, delete and sync. That list of controls is worth pausing on, because each one implies a specific failure it prevents. Stop is for a runaway task. Reset is for a session that has gone into a state you want to start over from. Compact is for a context window that has filled with work you no longer need but want to keep. Delete and sync are for cleaning up and for reconciling with the gateway. The scheduling feature is the other substantial one. You can set tasks on a schedule with `cron`, `every` or `at` expressions, pick from presets or write your own, check the run history, and trigger manually at any time. The distinction between the three expression types is the useful part. Cron is the traditional fixed schedule. `every` is an interval. `at` is a single moment. An agent that runs every fifteen minutes and an agent that runs at 3am on Sundays are different kinds of automation, and having all three in one vocabulary means you do not have to convert one into another. Checking run history matters because a scheduled task that silently stops running is the failure mode people hit first. And exporting any session as Markdown to keep a clean record outside the app is a small feature that makes the whole thing auditable, since a Markdown transcript is something you can read, diff and keep indefinitely. ## Teams, and the coordinator pattern ClawWork Teams package multiple agents into a single deployable unit, with roles, personalities, skills and workflow included. A coordinator agent breaks down the task and delegates to worker agents, each running in its own sub-session, and you see the full orchestration in real time. The progression is stated as a single line: skill, then agent, then team. The team structure on disk is plain files in a directory, and that plainness is the point: ``` teams/clawwork-dev/ ├── TEAM.md # team metadata and workflow └── agents/ ├── manager/ # coordinator — orchestrates the team │ ├── IDENTITY.md # role and prompt │ ├── SOUL.md # personality and style │ └── skills.json # skill dependencies ├── architect/ # worker — designs solutions ├── frontend-dev/ # worker — builds UI ├── core-dev/ # worker — builds core logic └── ... ``` So a team is a directory of agent directories. Each agent has an identity file holding its role and prompt, a soul file holding its personality and style, and a skills file listing what it depends on. The team itself has a metadata and workflow file at the top. The split into IDENTITY and SOUL is the unusual part and it is worth understanding. The identity is what the agent is for, and the soul is how it behaves. Separating them means you can swap the behavioural style without rewriting the prompt that does the work, or run the same worker with a different personality, which is the kind of separation that becomes useful when you have several workers that all need the same competence but should not all sound the same. Having roles like architect, frontend-dev and core-dev as separate directories, each running in its own sub-session, is what makes the orchestration visible. The coordinator delegates, and each delegate gets its own session, so the tree of work is legible rather than a single thread of an agent talking to itself. There are three ways to get a team. TeamsHub is a Git-native registry for browsing and installing community-contributed teams. You can create one manually in a step-by-step wizard that defines agents, identities and skills. Or there is an AI Builder, where you describe what you need and an LLM designs the team structure, the roles and the prompts for you. Once a team is installed you pick it when creating a task, and the coordinator takes over from there. ## How it is distributed and how it is built There are three ways to get the application, and they cover different levels of commitment. Homebrew on macOS: ```bash brew tap clawwork-ai/clawwork brew install --cask clawwork ``` Prebuilt macOS, Windows and Linux builds are on the releases page, and the app updates itself, with new versions downloading in the background and installing when you quit. And there is a PWA at cpwa.pages.dev that requires no install, works in any modern browser on desktop and mobile, and is installable to your home screen. The PWA is the interesting one. A browser-based version of an agent client has to talk to the same gateway over a WebSocket, which it can since the endpoint is a URL, and the fact that the local default is a loopback address means a PWA on your phone cannot reach it without the gateway being exposed. So the PWA is for people whose gateway is remote, and the desktop app is for people whose gateway is on the same machine. The repository layout shows a pnpm monorepo. There is `packages/` for the shared code, with the scripts referring to `@clawwork/shared`, `@clawwork/core`, `@clawwork/desktop`, `@clawwork/pwa`, `@clawwork/website` and `@clawwork/keynote`. The `website/` directory is the project site, `keynote/` is a presentation, `e2e/` holds end-to-end tests, `docs/` the documentation, and `scripts/` the build and check tooling. The scripts in the package manifest are worth reading, because the check names describe the project's own invariants. There is `check:architecture`, `check:ci-bot-security`, `check:renderer-copy` and `check:ui-contract`. Each of those is a custom script rather than a lint rule, which means the project has architectural rules it wants enforced by a build step. A UI contract check in particular suggests that the desktop app, the PWA and the website share a set of components and that the check keeps them consistent. The typecheck script runs tsc separately in each workspace in dependency order, shared then core then pwa then desktop then website, and there is a separate typecheck:tests for the test configurations. The lint script is `eslint . --max-warnings 0`, so a warning is a failure. The repo also has husky for git hooks, knip for unused exports, renovate for dependency updates, and separate README files in Japanese, Korean, Simplified Chinese and Traditional Chinese. There are files at the root named AGENTS.md, CLAUDE.md, DESIGN.md, DEVELOPMENT.md and CONTRIBUTING.md, along with an OWNERS file and a CHANGELOG, which is a repository set up for a team rather than for a single author. ## Conclusion Adopt ClawWork if you are running OpenClaw and your work has outgrown a single chat window, since the task-first structure and the searchable artifact repository are the whole point of it. Do not adopt it if you only run the occasional agent task, because the extra structure is only worth its cost at volume, and check first which runtime you connect to, because today it is an OpenClaw client with the multi-runtime support still aspirational. ## FAQ ### What is ClawWork? It is an Electron and React desktop client for OpenClaw, an agent runtime, structured around tasks rather than chat threads. It provides parallel tasks with isolated sessions, artifacts auto-saved to a local Git repository where they are searchable, scheduled runs, session controls and a three-panel layout of task list, conversation and progress panel. The licence is Apache-2.0. ### How do I install ClawWork? With Homebrew on macOS using `brew tap clawwork-ai/clawwork` then `brew install --cask clawwork`, or by downloading a prebuilt macOS, Windows or Linux build from the releases page, where the app also updates itself. There is also a browser PWA at cpwa.pages.dev that needs no installation and works on desktop and mobile. ### How do I connect ClawWork to an OpenClaw gateway? Start an OpenClaw Gateway, then open ClawWork and add it in Settings, authenticating with a token, a password or a pairing code. The default local endpoint is ws://127.0.0.1:18789, after which you create a task, pick a gateway and agent and describe the work. ### What are ClawWork Teams? They package multiple agents into a single deployable unit with roles, personalities, skills and workflow. A coordinator agent breaks the task down and delegates to worker agents, each in its own sub-session, with the orchestration visible in real time. Teams are directories of agent directories, each with IDENTITY.md, SOUL.md and skills.json, and they can be installed from TeamsHub, built by hand in a wizard, or designed by an LLM through the AI Builder. ### How does ClawWork handle scheduled and recurring agent work? Tasks can be scheduled with cron, every or at expressions, chosen from presets or written by hand. You can check the run history and trigger a run manually at any time, and any session can be exported as Markdown to keep a record outside the app. ### Is ClawWork still being developed? The repository is not archived and the last push was on 2026-08-24. The releases are v0.0.16 from 2026-05-16, v0.0.15 from 2026-05-10 and v0.0.15-beta.4 from 2026-04-28, so the version is still in the zero range, and the project describes its current scope as the best-in-class client for OpenClaw with a multi-runtime future still to come. ## Sources - [clawwork-ai/ClawWork on GitHub](https://github.com/clawwork-ai/ClawWork) - [License: Apache-2.0](https://github.com/clawwork-ai/ClawWork/blob/main/LICENSE) - [Project website](https://clawwork-ai.github.io/ClawWork/) - [README](https://github.com/clawwork-ai/ClawWork/blob/main/README.md) - [Releases](https://github.com/clawwork-ai/ClawWork/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/clawwork-ai-clawwork