WorkAny: a Tauri desktop agent that runs its runtime in-process
Desktop Agent for Any Task
At a glance
- What is it?
- WorkAny packages a natural language task runner into a Tauri 2 desktop app with a Hono backend and the @codeany/open-agent-sdk, so the agent loop runs inside the application rather than shelling out to a CLI. The trade-off is a three-part build chain and a custom community licence.
- Who is it for?
- Adopt WorkAny if you want a desktop agent whose runtime is embedded in the app and you are willing to build it from source with Node 20, pnpm 9 and Rust 1.70. Do not adopt it if you need a packaged installer with a documented release cadence, or if an Apache 2.0 licence is a hard requirement, because the repository ships a WorkAny Community License with added conditions.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 56 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What WorkAny solves, and who it is actually for
WorkAny is a desktop application that takes a task in natural language and carries it out on your machine. The README lists the outputs it shows off: organized files, a generated website, a document, a data table, slides. That is a broad promise, and it tells you the target user is not a developer wiring an agent into a CI pipeline. It is someone sitting at a desktop who wants a local agent to touch local files, run shell commands and produce artifacts they can preview.
The repository layout makes the boundary clear. src/ is the React 19 frontend, src-api/ is a Hono backend that hosts the agent SDK, and src-tauri/ is the Tauri 2 shell with SQLite. Three languages, three build outputs. Anyone evaluating WorkAny should read that as the real cost of entry: this is not a single binary you download and run. The README points to workany.ai as the website, and the Casks/ directory at the repository root suggests a Homebrew cask path exists, but the README itself documents only the source build.
How the agent loop is wired: in-process SDK, external tools
The distinguishing architectural claim in the README is that the agent runtime is "powered by @codeany/open-agent-sdk" and "runs entirely in-process with no external CLI dependency." That matters because a large share of desktop agent projects spawn a separate agent binary and talk to it over stdio. WorkAny folds the runtime into the Hono API server in src-api/, which the desktop shell then talks to.
Around that runtime sit the capabilities: 30+ built-in tools covering file I/O, shell execution, web search and code editing; a sandbox described as an isolated code execution environment; artifact preview for HTML, React and code files; MCP server integration over stdio, SSE or HTTP; and custom agent skills. Model access is multi-provider, listing OpenRouter, Anthropic, OpenAI and any compatible endpoint. The README's settings screenshot is captioned "Use custom model provider for Agent," which is the mechanism behind that list.
The design keeps the frontend thin. React renders the streaming task output and the artifact previews; the API server owns tool execution and the agent loop; Tauri supplies the window, the filesystem reach and SQLite. The README includes an architecture image but does not describe the message flow in text, so the exact sequencing between frontend, Hono and the SDK is not documented in prose.
Building WorkAny from source: prerequisites and first run
The README's Development section gives the requirements plainly: Node.js >= 20, pnpm >= 9, Rust >= 1.70. All three are needed because the build spans the Vite frontend, the Hono API and the Rust desktop shell.
The quick start is four commands. Install dependencies first, then start the API server, then the app.
pnpm install
pnpm dev:api
pnpm dev:app
pnpm dev:webThe README marks pnpm dev:app as the recommended path and pnpm dev:web as optional, for a browser-only run. In package.json, dev:app is defined as pnpm tauri dev --config src-tauri/tauri.dev.conf.json, and it is preceded by a predev:app hook that runs node scripts/check-rust.js and node scripts/check-api-binary.js. Those two scripts are the gate: if Rust is missing or the API binary has not been built, the app will not start. If pnpm dev:app fails immediately, check those scripts before anything else.
For a full desktop build rather than a dev run, package.json defines tauri:build as pnpm build:api:binary && tauri build, with platform-specific variants such as tauri:build:mac-arm and tauri:build:windows that pass an explicit Rust target. The README does not document what the resulting bundle contains or where it is written.
Where WorkAny is the wrong tool
The first limitation is distribution. The README documents a source build and nothing else. There is no install section for end users, no note on signed or notarized builds, and no statement about auto-update. The Casks/ directory exists in the repository, which implies a Homebrew route, but the README does not describe it. If you need a double-click installer for non-technical colleagues, the documented path does not give you one.
The second is the build chain. Node 20, pnpm 9 and Rust 1.70 are all mandatory, and the dev flow depends on a prebuilt API binary checked by scripts/check-api-binary.js. That is a heavier prerequisite set than a Python CLI agent, and it means contributors need a working Rust toolchain before they can see the UI at all.
The third is licence. The README states the project is under the WorkAny Community License, "based on Apache License 2.0 with additional conditions," copyright ThinkAny, LLC. The additional conditions are not summarized in the README. Any organization that treats Apache 2.0 as an automatic green light should stop and read LICENSE before adopting this.
Finally, the README is thin on failure behaviour. It does not document rollback, how the sandbox is enforced, what happens when a tool call fails, or how provider rate limits surface. Claiming an agent is safe to point at a real working directory requires evidence the README does not supply.
How WorkAny differs from a terminal coding agent
The obvious comparison is a terminal coding agent such as Claude Code or an Aider-style CLI: you run it in a shell, it edits files in a repository, and you review diffs in your editor. WorkAny inverts the presentation. The agent output streams into a React UI, artifacts get a live preview pane, and the session state lives in a Tauri app backed by SQLite rather than in your shell history.
That difference cuts both ways. A terminal agent composes with existing tooling: git, your test runner, your editor. WorkAny's value is in the preview and the non-code artifacts (documents, slides, tables) that a terminal agent does not render. If your work is entirely code in a git repository, the desktop wrapper adds a build chain without adding much. If your work is producing files a person will look at, the preview pane is the reason to pick it.
A second comparison is to hosted browser agents. Those run in someone else's sandbox. WorkAny runs on your desktop with access to your filesystem, which is the point, and also the risk. The README's sandbox claim covers code execution, not the file tools, and it does not explain the boundary.
Maintenance, releases and what the licence means in practice
The last push to the default dev branch was on 2026-07-22. The repository is not archived. Recent releases are v0.1.19 on 2026-03-08, v0.1.18 on 2026-03-05 and v0.1.17 on 2026-03-03, while package.json carries version 0.2.0. That gap between the newest tagged release and the manifest version is worth checking before you pin a dependency, because it suggests the release tags lag the working tree.
The upgrade cost is structural rather than cosmetic. Because the desktop shell is Rust and the API is a separate build target, a version bump can require rebuilding the API binary for each platform you support. The package.json scripts enumerate mac-arm, mac-intel, linux and windows binary builds separately, which means cross-platform release work is four builds, not one.
On licensing: the README describes the WorkAny Community License as Apache 2.0 with additional conditions and names ThinkAny, LLC as the copyright holder. It does not state what those conditions are. This is not legal advice, but the practical step is unambiguous: open LICENSE and read the added conditions before you ship WorkAny inside a product or a company image.
Editorial conclusion
Adopt WorkAny if you want a desktop agent whose runtime is embedded in the app and you are willing to build it from source with Node 20, pnpm 9 and Rust 1.70. Do not adopt it if you need a packaged installer with a documented release cadence, or if an Apache 2.0 licence is a hard requirement, because the repository ships a WorkAny Community License with added conditions. Before committing, read LICENSE in full, confirm which model provider you will point it at, and check whether the dev branch is where you want to track fixes.
Frequently asked questions
What is the WorkAny app?
WorkAny is a desktop AI agent application that executes tasks from natural language input, with real-time code generation, tool execution and workspace management. It is built as a Tauri 2 desktop app with a React frontend, a Hono API backend and the @codeany/open-agent-sdk as the agent runtime.
What do I need installed to run WorkAny from source?
The README lists Node.js >= 20, pnpm >= 9 and Rust >= 1.70 as requirements. You then run pnpm install, pnpm dev:api and pnpm dev:app, with pnpm dev:web available for a browser-only run.
Which model providers does WorkAny support?
The README lists OpenRouter, Anthropic, OpenAI and any compatible API endpoint, and the settings screenshot is captioned for using a custom model provider for the agent.
What licence is WorkAny released under?
The README states the project uses the WorkAny Community License, based on Apache License 2.0 with additional conditions, with copyright held by ThinkAny, LLC. The README does not describe what those additional conditions are.
Community notes