taracodlabs/aiden: an autonomous work engine that drives your own machine
Aiden — Autonomous AI agent that operates your computer with prompts: browser control, terminal execution, workflows, tools, recovery systems, and persistent memory. Built solo. AGPL-3.0.
At a glance
- What is it?
- Aiden is a local-first TypeScript agent that plans, acts and recovers across files, terminal and browser. Here is what the repository actually documents, what it leaves out, and who should install it.
- Who is it for?
- Adopt Aiden if you want an agent that runs against your own filesystem and shell on Windows, WSL or Linux and you are comfortable with an AGPL-3.0 runtime plus a separately licensed skills directory. Do not adopt it if you need a documented macOS desktop build (the README lists macOS in API mode only), if you are unwilling to run an agent with shell and browser reach, or if you need published rollback instructions, which the README does not provide.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 18 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 October 1, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The gap Aiden targets: agents that stop at the chat window
Most assistant tooling answers questions. Aiden is built around the opposite premise: you hand it a goal and it works across files, terminal, browser, supported applications, APIs, repositories and connected services, in the words of the README's own summary. The package description on npm calls it a "Local-first autonomous work engine for Windows, WSL, and Linux with multiple providers and offline Ollama support."
The intended user is someone who already lives in a terminal on Windows or Linux and wants an agent that touches the real machine rather than a sandboxed chat. The repository topics include windows, local-first and personal-ai, which lines up with the supported platform list in the README header: Windows, Linux, WSL, and macOS in API mode. That last qualifier matters. macOS is not listed as a full desktop target the way Windows 11 is.
The project is built by one author, Shiva Deore, and the README carries a "Built solo" badge. That shapes everything downstream: release cadence, documentation depth and the parts of the surface that have no written explanation.
How Aiden works: a Node runtime, SQLite memory, Playwright and MCP
The runtime is a TypeScript and JavaScript codebase targeting Node 20 or 22, bundled with esbuild, shipped as ESM. The published package is aiden-runtime, and its bin entries map both aiden and aiden-runtime to bin/aiden-bootstrap.cjs, so the bootstrap file is the single entry point regardless of which command name you type.
Persistence is SQLite through better-sqlite3 11.x, with FTS5 called out in the README badges, which is the full-text search extension. That is the persistent memory layer. Browser control is Playwright driving headless Chromium. The badges also name the Model Context Protocol at version 1.0, and the repository root contains mcp-config-example.json, so external MCP servers are part of the tool surface rather than an afterthought.
Several mechanisms are named in the badge row and expanded nowhere in the README excerpt: TCE, described there as error recovery, tiered guardrails, sub-agent fanout, opt-in daemon mode, and SSE streaming. The README's tagline for the project is "Autonomous Work Engine: plans, acts, recovers, and proves the result," which maps the recovery and verification claims onto that list. Treat the badge row as a feature index, not documentation. If recovery behaviour is the reason you are evaluating Aiden, ARCHITECTURE.md in the repository root is where to look next, because the README does not explain what TCE does when a step fails.
The repository layout is unusually wide for a solo project: separate directories for cli, core, memory, providers, integrations, security, platform, plugins, capabilities, coordination, evals and a dashboard-next front end, plus an electron directory and a cloudflare-worker directory. That spread tells you the project has grown by accretion rather than around a single narrow core.
Installing aiden-runtime and running a first prompt
The README's install section is titled "Try it in 60 seconds," and the package is distributed on npm under the name aiden-runtime. The engines field restricts Node to >=20 <21 or >=22 <23, so check your version before anything else.
node --version
npm install -g aiden-runtimeAfter the global install, the bin mapping means the aiden command resolves to the bootstrap script. The package also ships scripts/postinstall.js and an install.ps1 at the repository root, so Windows users have a PowerShell path in addition to npm.
Configuration is environment-based. The repository includes .env.example, which instructs you to copy it to .env and fill in what you need. The file states that Aiden works fully offline with only Ollama configured and that all cloud provider keys are optional fallbacks, which is the clearest statement of the local-first claim in the repository.
cp .env.example .envTwo defaults are worth reading before you start the runtime. The API server port is MY_SERVER_PORT with a default of 4200, and the bind address defaults to 127.0.0.1, localhost only. The example file says to set it to 0.0.0.0 only if you need remote or LAN access, for example on a headless server or WSL2. If you do open it up, the same file notes that AIDEN_CORS_ORIGIN must be set to * to allow any origin.
MY_SERVER_PORT=4200
AIDEN_HOST=127.0.0.1
DEVOS_HEADLESS=falseDEVOS_HEADLESS controls whether browser automation runs without a visible window, and DEVOS_AUTO_APPROVE set to true skips all confirmation prompts for CI or automation. Turning that second flag on removes the human check between the agent and your machine, so it belongs in a disposable environment rather than on a workstation you care about. For a first run, leave both at their defaults and watch the browser window.
Where Aiden is the wrong tool, and what the README does not say
An agent with shell execution and browser control is a large trust surface. The .env.example is explicit that DEVOS_AUTO_APPROVE skips all confirmation prompts, and the README does not describe a permission model beyond the tiered guardrails badge. SECURITY.md exists in the repository root, but nothing in the README excerpt explains what the guardrail tiers actually gate. Before pointing Aiden at a machine with credentials on it, read that file.
Platform support is narrower than the badge wall suggests. The header lists Windows, Linux, WSL and macOS in API mode. If you want a native macOS desktop experience, the README does not describe one. The electron directory exists in the layout, but the README does not document an Electron build as a supported install path.
Upgrades are another gap. The published files include bin/aiden-updater.cjs and scripts/uninstall.ps1, so an update mechanism and a Windows uninstall script ship with the package. What the README does not document is rollback: there is no described way to return to a previous version after aiden-updater runs. RELEASE-NOTES files for v4.5.0, v4.17.0, v4.19.0, v4.19.1, v4.21.0, v4.21.1 and v4.21.2 sit in the repository root, so the changelog history is there to read, but pinning and reverting are on you.
Finally, the licensing is split. The runtime is AGPL-3.0-only per package.json, but the repository also carries LICENSE-SKILLS.md and RELICENSING.md. The package files list excludes skills/installed, skills/learned/pending and skills/learned/approved from the npm tarball, which suggests the skills tree has its own terms and its own distribution story. If you plan to redistribute Aiden or build a service on top of it, read both files rather than assuming the AGPL covers everything in the tree.
How Aiden differs from editor-embedded agents and plain shell scripts
The closest comparison is an editor-embedded agent. Those live inside one application's context: they see the open project, the buffer and the integrated terminal, and they stop at that boundary. Aiden's stated scope is the machine, not the editor. Browser automation through Playwright, MCP servers, and connected channels such as Discord, Slack, Telegram, email and webhooks are outside what an editor agent normally reaches. That is the actual difference in approach: Aiden is a daemon-and-CLI runtime that treats the operating system as the workspace.
The trade-off is containment. An editor agent inherits the editor's file scope and its review UI. Aiden's blast radius is whatever your user account can touch, which is why the confirmation prompts and the guardrail tiers carry more weight here than they do in an IDE plugin.
The second comparison is a shell script or a cron job. Those are deterministic: the same input produces the same actions. Aiden plans with a language model and recovers from failures, which the README frames as a feature. It also means the action sequence is not reproducible in the way a script is, and the README does not describe a dry-run mode for previewing a plan before it executes. If your task is a fixed sequence of steps, a script is cheaper and more predictable. Aiden earns its place when the steps are not known in advance.
Release cadence, upgrade cost and the AGPL question
Version 4.21.0 was released on 2026-08-24, three days after v4.20.0 on 2026-08-21, with v4.19.1 on 2026-08-06 before that. The last push to main was on 2026-08-24. The repository is not archived. A release cadence that produces patch and minor versions within days of each other means upgrade cost is real: you should expect to re-read release notes rather than assume a quiet upgrade. The repository root holds release notes for v4.21.0, v4.21.1 and v4.21.2, and package.json is already at 4.21.2, so the published version has moved past the last tagged release listed in the repository.
On licensing, the runtime package declares AGPL-3.0-only. AGPL-3.0 carries network-copyleft obligations, which matters if you expose Aiden or a modified version of it as a service to other people. The presence of RELICENSING.md in the repository root indicates the project has changed licence terms at least once, and LICENSE-SKILLS.md indicates the skills directory is governed separately. This is not legal advice. If you are embedding Aiden in a product, read RELICENSING.md, LICENSE-SKILLS.md and LICENSE together and get your own counsel.
Maintenance is one author's output. The README says "Built solo." That is not a criticism of the code; it is a fact about bus factor, response time on issues, and how quickly a security report in SECURITY.md gets handled. Plan accordingly.
Editorial conclusion
Adopt Aiden if you want an agent that runs against your own filesystem and shell on Windows, WSL or Linux and you are comfortable with an AGPL-3.0 runtime plus a separately licensed skills directory. Do not adopt it if you need a documented macOS desktop build (the README lists macOS in API mode only), if you are unwilling to run an agent with shell and browser reach, or if you need published rollback instructions, which the README does not provide. Before installing, read RELICENSING.md and LICENSE-SKILLS.md, and check that your Node version satisfies the engines field of aiden-runtime, which accepts >=20 <21 or >=22 <23.
Frequently asked questions
What is taracodlabs/aiden?
It is a local-first autonomous work engine distributed on npm as aiden-runtime. The README describes it as an agent that plans, acts, recovers and proves the result while working across files, terminal, browser, APIs and connected services.
How do you install Aiden?
The package is published to npm as aiden-runtime, and the README's install section points at a 60-second setup. The engines field requires Node >=20 <21 or >=22 <23, and the bin entries map both aiden and aiden-runtime to bin/aiden-bootstrap.cjs.
Which operating systems does Aiden support?
The README header lists Windows, Linux, WSL and macOS in API mode. Windows 11 is named explicitly in the platform badges, and the repository ships install.ps1 and scripts/uninstall.ps1 for the Windows path.
Does Aiden work without a cloud model provider?
Yes. The .env.example states that Aiden works fully offline with only Ollama configured and that all cloud provider keys are optional fallbacks. The README badge row also lists Groq, Anthropic, OpenAI and Gemini alongside Ollama as supported providers.
What licence does Aiden use?
package.json declares AGPL-3.0-only for the aiden-runtime package. The repository also contains RELICENSING.md and LICENSE-SKILLS.md, and the npm files list excludes the installed and learned skills directories, so the skills tree is governed separately from the runtime.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/taracodlabs-aiden)