One desk for agents, apps, and memory
holaOS is built around a useful observation: switching AI agents is easy, but rebuilding their working environment is not. Codex may know one set of project instructions, Claude Code another, and a desktop assistant may hold separate integrations and history. holaOS puts those agents inside one Electron workspace, where they can share files, tools, skills, connected apps, and durable memory.
The interface is meant to show live applications beside the agent instead of reducing every result to chat. A browser, Notion page, or custom HolaApp can remain interactive while the agent operates it. The README also advertises Gmail, Slack, GitHub, Linear, Notion, and more than 50 other one-click connections, community MCP servers, document creation, messaging-channel access, and scheduled automation. This is a much wider target than a coding assistant. It is an attempt at an agent-operated workstation.
That scope is the reason to consider holaOS and the main source of risk. Connecting one process to signed-in browsers, local files, SaaS accounts, tools, and schedules concentrates authority. The repository has a responsible security policy covering credential exposure, remote execution, sandbox escape, privilege escalation, authentication bypass, and unsafe local-runtime defaults. A policy document is not a substitute for your own permission review, especially when an installed MCP server can expose all its discovered tools unless a workspace sets an explicit allowlist.
The local memory design has real substance
Shared memory is holaOS's strongest differentiator. The current design stores canonical durable material as human-readable Markdown, organized into workspace interaction trees and global integration trees. Databases and embeddings act as indexes rather than the only copy. If an index disagrees with the Markdown, the files remain authoritative and derived state can be rebuilt.
The documentation also distinguishes durable knowledge from session residue. Stable facts, procedures, repeated blockers, preferences, and references can survive, while one-off logs and transient failures should not. Workspace paths reject absolute paths and parent traversal, and cross-workspace access is blocked. This is a more thoughtful memory boundary than saving every transcript and hoping retrieval finds the right paragraph. Users can inspect what persists, and teams can back up or version the meaningful files.
MCP support is similarly explicit. A workspace YAML file defines servers and optional tool allowlists. The runtime resolves environment placeholders, starts its sidecar, and passes the permitted tool surface to the selected harness. The catch deserves emphasis: omitting an allowlist, or leaving it empty, means all tools discovered from that configured server can be exposed for the run. Security-conscious deployments should treat allowlists as required configuration, not advanced tuning.
Local-first does not mean offline by default
The source is runnable on your machine, and the independent runtime documentation shows how to place workspaces, state databases, and memory under a chosen sandbox root. Operators can bind the API to localhost, package the runtime for Linux, macOS, or Windows, and override model and bridge endpoints. Bring-your-own keys support OpenAI, Anthropic, and compatible services.
The default desktop template still points authentication, backend, control plane, and web HolaApps to holaOS domains. Built-in models necessarily arrive through the product's service. The honest reading is that workspace execution and memory can be local while some account, model, integration, and app paths are hosted unless you replace or disable them. Anyone with an air-gap, data-residency, or vendor-isolation requirement needs a traffic inventory and a documented configuration, not the phrase local-first.
Licensing also changes the adoption decision. This is not ordinary Apache 2.0 despite the familiar base. Internal commercial use is allowed, but offering the source as a hosted third-party service or embedding substantial parts in a sold product requires written authorization or a commercial license. Frontend users may not remove or alter the product logo and copyright notice. Contributors also agree that the producer may adjust the agreement and use contributed code commercially. Those terms may be acceptable for an internal tool, but platform vendors and white-label products should stop and get legal review.
Setup is automated, not small
A curl-to-shell installer can provision Git and Node.js 24, clone the repository, install dependencies, copy the environment template, build the local runtime, and run type checks. It stops before launching Electron unless asked. The manual guide is unusually precise and tells an automation agent when to stop on type-check or GUI failure.
Behind that convenience is a large Bun and Turbo workspace with Electron, native SQLite, image tooling, multiple runtime services, bundled Node and Python runtimes, and platform packaging. The August binary release contains Windows and macOS installers around 450 to 540 MB and a Linux runtime archive around 430 MB. An open issue from August 8 says the Dockerfile references package-lock files that no longer exist after the workspace moved to Bun; an open pull request addresses it. Source users should expect active-build friction even when the desktop installer works.
Young, active, and worth a constrained trial
The repository was created in March 2026 and last pushed on August 12. GitHub showed six open items combining issues and pull requests, with three true open issues. The separate binary repository published several builds from late July through August 9. That combination indicates fast, current development, though not long production history.
For an individual developer frustrated by fragmented agents, holaOS offers a coherent answer and unusually transparent memory mechanics. For an enterprise, its value rises with the number of tools it can unify, but so does the permission and network review. Start with a disposable workspace, explicit MCP allowlists, minimal integrations, and your own provider key. Adopt it more broadly only after you understand which data stays in local Markdown, which requests use hosted services, and whether its license fits what you plan to distribute.