# Abu: a desktop agent that plans before it deletes anything > An open-source, local-first desktop assistant with plan mode, per-conversation permission modes, 29 built-in skills that can crystallise your own flows, cron schedules, IM triggers and up to five parallel agents. The codebase is mid-migration, with an Electron shell that is current and Tauri tooling that the scripts call through a file named legacy. **PM-Shawn/Abu-Cowork** — Open-source alternative to Claude Cowork — a local-first AI agent desktop app · multi-model · self-evolving skills · privacy-first · multi-Harness roadmap · DeepSeek Harness integration in progress - Repository: https://github.com/PM-Shawn/Abu-Cowork - Website: https://myabu.cn - Stars: 388 · Forks: 88 - Language: TypeScript - License: NOASSERTION - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/pm-shawn-abu-cowork ## Plan first, then wait for you to confirm Abu is described as a locally-run desktop assistant inspired by Claude Code's Cowork mode: you tell it what you need and it reads files, runs commands, writes documents and builds reports on your own machine. The safety design is specific rather than aspirational. For high-risk steps, named as delete, overwrite, send and install, Plan Mode presents a step-by-step plan and waits for you to click Confirm & run, and only read-only operations proceed while approval is pending. When it needs a decision rather than a permission, it raises an option card above the composer with single or multi-select choices and a free-text Other row. Permission is also per conversation. Three modes are named, Request Approval, Smart Review and Full Autonomy, and both the mode and the model can be switched for one conversation without bleeding into others. That last point is the part that matters in practice: a chat you trusted to browse the web does not inherit that trust, and a later chat that needs write access has to be given it. ## Twenty-nine skills, and an offer to make a thirtieth The skill system is where the self-evolving claim lives. There are 29 built-in skills, and after you complete a multi-step flow the assistant proactively offers to crystallise that flow into a skill. Custom skills and a built-in plugin market sit alongside them, and MCP connectors are described as one-click integrations with services such as Playwright and GitHub. On top of that sit three related surfaces. Expert Agents are a library you summon by name. Projects and Workspaces group work so each project carries its own skills and MCP servers. Personal Memory records your preferences and work habits. There is also a Soul personality system, which decides when the assistant speaks up rather than waiting: three proactivity presets named Quiet, Buddy and Butler, with tone, form of address, reply style and boundaries customised through a SOUL.md file. One caveat about the source material: the visible README cuts off partway through the Core Capabilities list, so the details of individual skills and any remaining capability entries are not written down in what is visible here. ## Five background agents, and a browser that has three trees Parallel execution is capped and stated: up to five background agents working at once, with progress shown in real time. Alongside it, the workspace has a file tree and a code canvas in the side panel, with browse, preview and edit, CodeMirror source editing with auto-save, preview auto-refresh, and version snapshots with rollback. Two smaller mechanisms are worth noting because they change how output arrives. Inline visualisation widgets render charts, HTML and Mermaid inside the chat rather than in a separate preview. And the progress panel is declarative: the model reports its own plan steps and status through a report_plan call, so the plan you see is the one the model is working from. The browser side is not a single component. The tree carries abu-browser-bridge/, abu-browser-shared/ and abu-chrome-extension/ as separate directories, and the browser extension has its own tsconfig and its own place in the typecheck chain, which suggests the extension is developed independently of the desktop shell and consumed by it. There is also a desktop pet with an activity tray, which is filed under Labs, meaning in-progress features that are off by default and opt-in. ## Cron, triggers, and four chat platforms The automation side has two halves. Scheduled Tasks run on cron for unattended work, and Triggers or Watch start a task from outside the conversation: HTTP requests, file changes and messages arriving in an IM channel. The channels are Lark, DingTalk, WeCom and Slack, and interaction is by mentioning Abu in the channel. IM channel configuration is a separate settings screen, and the channels double as a trigger source, which is the combination that makes this useful for a small team rather than a single desk. Model management is similarly explicit. Provider presets cover Volcengine, Bailian and Zhipu access plans, added or edited through one modal, and per-model capabilities such as vision, tools, reasoning and token limits are declared per model rather than assumed. That data is generated: the manifest runs a model-data check as part of both the build and the test pre-step, so a hand-edited capability table fails CI. Usage stats cover requests, tokens, cache hits and usage per model or per skill, and a diagnostic panel self-checks AI services, MCP, skills and network and exports a bundle. ## Electron today, Tauri on the roadmap, one file called legacy The packaging tells you which shell is current. The manifest's main entry is electron/main.cjs, the build is Vite plus a TypeScript project build, and electron-builder.yml carries the packaging configuration. Two documents at the root, ELECTRON-NEAR-TERM-ROADMAP.md and ELECTRON-TRANSITION-RELEASE.md, describe a move to Tauri. The Tauri path exists in the tree, with src-tauri/ and sidecar/ directories. What is telling is the naming: every tauri script in the manifest delegates to scripts/legacy-tauri-command.mjs, for dev, build and their enterprise variants alike. A command shim called legacy, handling both directions, is the sort of marker a project leaves when one path is being retired rather than introduced. So the accurate description is a codebase mid-transition with two shells present, where the documented near-term plan is not the current default. macOS builds are described as signed and notarized, which is a real distribution requirement rather than a convenience, and the full internationalisation is claimed alongside it. ## Five tsconfigs and three test runners The repository is large and the build surface shows it. There are five TypeScript projects, a base tsconfig plus app, node, sidecar and enterprise variants, and the typecheck script chains the base build with a separate sidecar check and a separate browser-extension check, so a broken component in any of the three surfaces fails the same command. An environment variable selects the enterprise variant. ABU_BUILD_TARGET=enterprise appears in both the dev and the build scripts, and a separate enterprise typecheck config exists alongside vitest.enterprise.config.ts and an enterprise-tests/ directory, which is a parallel track rather than a flag. Tests come from three runners. Vitest is the unit suite, node --test covers the website download links and docs plus a batch of infrastructure checks including changed-lines coverage, branch protection, CI workflow and test inventory, and Playwright has two configurations, one for the browser and one for Electron, with WebdriverIO configured alongside. A vitest.quarantine.config.ts and a quarantine concept in the scripts suggest tests can be parked rather than deleted. Committed eval-results/ and test-reports/ directories mean the run artefacts are part of the repository rather than something CI keeps to itself. ## Version 0.50.0, Apache-2.0, and a stated roadmap Release cadence has picked up: v0.41.0 on 2026-08-22, v0.42.0 on 2026-08-26 and v0.50.0 on 2026-09-16, with the manifest version matching the newest tag and the last push to main dated 2026-09-29. The repository is not archived. Licensing is Apache-2.0, declared in the manifest with a LICENSE file at the root. The README also carries full internationalisation, with a Chinese README and Chinese variants of the changelog, the security policy, the disclaimer and the forking guide. The repository description makes one claim that belongs in an evaluation rather than a feature list: a multi-Harness roadmap with DeepSeek Harness integration in progress. Multi-model support is real and visible in the per-model capability declarations and the provider presets, but a harness integration described as in progress is not something to plan around yet. The recent highlights listed for the current release are concrete and worth checking against your own list: the workspace file tree and code canvas with snapshots and rollback, the declarative progress panel, inline visualisation widgets, multi-endpoint provider presets, per-model capabilities, document comment-to-chat, full internationalisation, and signed notarized macOS builds. ## Conclusion Abu fits someone who wants an agent that touches real files and commands on their own machine and is willing to work inside a confirmation gate, since that is the design rather than a setting. It does not fit a team that needs a hosted, multi-user deployment, and the build scripts are specific enough that contributing means reading them first. Before the first task, pick a permission mode deliberately, because it is set per conversation and Full Autonomy is one of the three options. ## FAQ ### What does Abu do that ordinary AI chat does not? It plans and executes: it invokes tools, reads and writes local files, runs commands, and completes tasks end to end on your machine. It also schedules work on cron, triggers tasks from HTTP requests, file changes or IM messages, and runs up to five background agents in parallel. ### How does Abu handle risky operations? Plan Mode presents a step-by-step plan for high-risk steps such as delete, overwrite, send and install, and waits for you to confirm before running, while only read-only operations proceed while approval is pending. Permission is set per conversation across three modes: Request Approval, Smart Review and Full Autonomy. ### What are the self-evolving skills in Abu? There are 29 built-in skills, and after you complete a multi-step flow the assistant offers to crystallise that flow into a skill. Custom skills and a built-in plugin market sit alongside them, and MCP connectors are described as one-click integrations. ### Which messaging platforms can Abu be reached on? Lark, DingTalk, WeCom and Slack, configured in the IM channel settings, where you interact by mentioning Abu in the channel. Messages arriving in those channels can also act as triggers that start a task. ### Which desktop shell does Abu use, Electron or Tauri? Electron is current: the manifest's main entry is electron/main.cjs and packaging uses electron-builder.yml, with signed and notarized macOS builds. Tauri tooling exists in the tree, and two documents describe the transition, while the tauri scripts all delegate to a shim named legacy-tauri-command.mjs. ## Sources - [Issues](https://github.com/PM-Shawn/Abu-Cowork/issues) - [PM-Shawn/Abu-Cowork on GitHub](https://github.com/PM-Shawn/Abu-Cowork) - [Project website](https://myabu.cn) - [README](https://github.com/PM-Shawn/Abu-Cowork/blob/main/README.md) - [Releases](https://github.com/PM-Shawn/Abu-Cowork/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pm-shawn-abu-cowork