MyAgents: A Tauri Desktop Workbench That Puts Agents, Tasks and Workspaces in One Window

The problem MyAgents targets: chat windows that forget where the work lives

The README states the project's premise directly: many AI products treat conversation as the only form, and that form does not carry long work. Context scatters, tasks get lost, results are hard to review, and the user ends up tidying by hand. MyAgents is positioned against that. Each agent is bound to a real workspace, and the conversation is treated as an entry point rather than the product. The stated goal is that the user spends attention on judgement, taste and acceptance, while context assembly, tool calls, long-running execution and repeated work go to the agent. The audience named in the README is broad: developers, creators, researchers, product managers, educators and domain experts. That breadth is also the first thing to be sceptical about. A tool that claims to serve all of them usually serves the developer-adjacent ones best, and the repository layout supports that reading: the contributor guide asks you to first decide whether your change touches UI, the Rust desktop layer, the Node sidecar, the agent runtime, MCP, the task centre or the plugin bridge. That is a maintainer's mental model, not a beginner's.

Workspace-bound tabs, per-session Sidecars and a Rust proxy in the middle

The architecture visible in the README is a three-layer desktop application. Tauri v2 with Rust is the desktop shell. React 19, TypeScript, Vite and TailwindCSS are the front end. A Node.js v24 sidecar running the Claude Agent SDK does the agent work. Communication runs through a Rust HTTP/SSE proxy: the front end calls Tauri invoke, which proxies to the sidecar. The README states that Sidecars are isolated per session, and that each Chrome-style tab runs its own agent, which is what makes parallel work possible. File capabilities go through Tauri and Rust rather than the Node layer. Two details are worth noting because they constrain what you can build. First, the embedded terminal is xterm.js plus portable-pty bound to the current workspace, so terminal state is scoped to a workspace rather than global. Second, local full-text search uses Tantivy with tantivy-jieba, which is a Chinese-aware tokenizer. That choice fits a project whose README is written Chinese-first, but it means search quality on non-Chinese corpora depends on how the index is configured, and the README does not describe that configuration. The embedded browser is described as a Tauri multi-Webview sub-view, used for previewing links and local HTML.

Tasks, cron and the optional command sensor that decides when to wake the model

The task centre is the part of the product that is least like a chat client. The README describes a two-stage flow: loose thoughts are captured and tagged, then discussed with the agent and turned into executable tasks. Tasks support one-off and periodic execution plus cron expressions, and the task centre tracks status, run counts, execution logs and recovery from exceptions. Chat, AI tools, IM bots and background tasks are said to share the same scheduling capability. The most interesting mechanism is the optional local command sensor. The README describes it as a low-cost check that only wakes the AI when a condition is met. That is a sensible design for periodic tasks, because polling a model on a schedule is wasteful when nothing has changed. The documentation does not specify what conditions the sensor can express, how the check is implemented, or what happens when a check errors. Until that is documented, treat the sensor as a feature to verify against your own trigger pattern rather than a general-purpose event system.

Getting it running: setup scripts, build scripts and the test pools

The README gives concrete commands. On macOS or Linux: git clone https://github.com/hAcKlyc/MyAgents.git, then cd MyAgents, then ./setup.sh and ./start_dev.sh. On Windows: .\setup_windows.ps1 followed by .\build_windows.ps1. The setup script checks native inference build tooling for the current target against a verified cache before it downloads the Node runtime, installs project dependencies or fetches Rust crates. Missing native build tools produce installation and verification instructions; the script does not install them for you. It then caches offline documentation and speech inference resources, and repeated runs reuse the verified cache. The default Mino workspace template is committed at bundled-workspaces/mino/, so building and initialising does not require GitHub SSH access or a template download. Developer requirements are Node.js >=22.0.0 with Node 24 recommended, npm (the repository declares npm@11.13.0), Rust via rustup with the toolchain pinned by rust-toolchain.toml, and CMake 3.28+ plus a platform C/C++ toolchain for a cold build of the native inference resources. macOS additionally needs Git, Python 3.10+ and Apple Clang. Supported development systems are macOS 13+, Windows 10+ and Linux Ubuntu 22.04+ or Debian 12+. End users need macOS 13.0 Ventura or later, on Apple Silicon or Intel, or Windows 10 or later. The command list includes npm run typecheck, npm run lint (ESLint plus dependency-cruiser architecture boundary checks), and a layered test setup: npm run test:classification, test:unit, test:dom, test:integration, npm test to run all four, and npm run test:credentialed for real provider and SDK smoke tests run explicitly and locally. Build scripts are ./build_dev.sh for a debug build with DevTools, ./build_macos.sh for production macOS, and ./build_linux.sh for AppImage and deb.

Where the documented design leaves gaps

The README is honest about one boundary and silent about several others. The external runtime option, which lets Claude Code CLI, OpenAI Codex CLI or Google Gemini CLI drive a session instead of the built-in Claude Agent SDK, is labelled as a lab feature. That label is a warning, not a formality. The model provider list is long but the README defers to the in-app provider page for the actual model list, which means the README cannot be used as a compatibility reference. The Linux section is truncated mid-sentence in the supplied material, so the Linux build requirements beyond the listed distributions cannot be confirmed here. There is no documented headless mode. The architecture is a desktop application with a Rust shell and a Node sidecar, and nothing in the README describes running the task scheduler or the agents on a server without the desktop client. If your workflow needs agents running on a remote machine while you interact from a phone, this is the wrong tool as documented. The same applies if you want a minimal chat client: the build chain pulls in Rust, CMake 3.28+, a pinned toolchain and a Node runtime download, which is a lot of surface area for asking a model questions. Search behaviour on non-Chinese text is another open question, given the Tantivy plus jieba pairing.

How MyAgents differs from a terminal-first agent CLI

The closest comparison in the README's own material is a terminal-first agent CLI such as Claude Code. MyAgents can use Claude Code CLI as a runtime, which makes the distinction sharper rather than softer. A CLI puts the agent in your shell, inherits your environment, and leaves state to files and session transcripts. MyAgents puts the agent inside a Tauri window with a per-session Node sidecar, a workspace file tree, an embedded terminal and browser, a tab model, and a scheduler that persists tasks with run counts and logs. The trade is real in both directions. The CLI is scriptable, composable and cheap to install. MyAgents gives you a persistent task state machine and a UI that keeps file, terminal and browser context next to the conversation. If your work is a sequence of shell pipelines you run once, the CLI wins. If your work is a project you return to across days, with recurring checks and a need to see what ran and what failed, the task centre is the part a CLI does not give you without you building it.

Licence, maintenance and what a fork inherits

MyAgents is licensed AGPL-3.0, and the repository is not archived, with the latest release v0.4.16 dated 2026-09-09 and two releases in the preceding four days. That release cadence suggests active work, but the version numbers also tell you something about stability: the project is at 0.4.x. The AGPL matters for anyone planning to modify and distribute the application or run a modified version as a network service, because the licence carries source-availability obligations in that case. This is not legal advice; read LICENSE and get your own counsel if you intend to ship a derivative. Maintenance cost for a fork is set by the stack rather than by the licence. You inherit a Rust toolchain pinned by rust-toolchain.toml, a Node runtime the setup script downloads, a CMake 3.28+ requirement for cold native inference builds, and a lint setup with dependency-cruiser architecture boundaries that will reject changes crossing layer lines. The release notes for v0.4.14, v0.4.15 and v0.4.16 mention multimodal model updates, file editing stability, a token animation and desktop interaction changes, and a combined Markdown editor with session search. Those are incremental changes, which is what you want to see between patch releases, but they also mean upgrade cost is continuous rather than occasional.

Editorial conclusion

Adopt MyAgents if you want a desktop client where each tab owns a workspace, a separate Node sidecar and a shared scheduler, and if AGPL-3.0 distribution terms are acceptable for how you plan to ship it. Skip it if you need a headless server-side agent runner, or if you want a lightweight chat client rather than a workspace-bound system with Rust and Node build requirements. Before committing, run ./setup.sh on your target machine to confirm the native build toolchain, then run npm test and npm run test:credentialed separately, since the second pool is the only one that touches real provider credentials.

Official sources

1. hAcKlyc/MyAgents on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases