holaOS: a local-first agentic workspace that runs Claude Code, Codex, or its own agent over shared memory

The problem holaboss-ai/holaOS is aimed at

Most agent products arrive as a finished surface: one chat box, one set of tools, one vendor's model. The README frames holaOS as the opposite. It describes handing you the parts and letting you assemble the workspace, with the claim that everything runs locally so customizing it does not mean sending your work to someone else's cloud.

The target user is a team that already has systems in place and does not want to move them. The README lists Gmail, Notion, Slack, GitHub, Linear and 50+ others as one-click OAuth integrations, and names Slack, Feishu, DingTalk and WeChat as the chat tools whose threads hold work context that never reaches a document. The pitch is that the agent reads the conversation directly instead of your summary of it.

That framing is narrower than it sounds. This is not a tool for someone who wants an agent in a terminal and nothing else. The value only appears once you connect something: an integration, a chat tool, an MCP server, or an app pointed at a URL. A fresh install with nothing connected is a shell.

How the workspace actually fits together

The repository layout tells you more than the marketing copy. There are apps/, packages/, runtime/, shared/ and patches/ directories at the top level, with turbo.json driving the build and bun.lock pinning dependencies. The desktop application is Electron, the runtime is TypeScript, and the package.json declares node >=24 and [email protected] as the package manager. The desktop package is named holaboss-local in the build scripts, which matches the local-first claim: the workspace is a desktop binary, not a hosted service.

The memory claim needs reading carefully. The README says one memory serves every agent, and that Claude Code, Codex and the built-in holaOS agent share the same memory, tools, skills and apps. The mechanism it describes is shared state per workspace rather than per agent, so switching the driving agent does not reset context. There are two scripts in package.json, memory:cleanup and memory:eval, which implies memory is a persisted artifact you can inspect and clear rather than something opaque held by a provider.

HolaApps are the other structural idea. The README describes them as real interactive surfaces opening beside the agent, not a transcript, and says context stays in sync both ways: whatever you click or type in the app becomes context the agent already has. The repository ships a patches/ directory, which is what you would expect from a project that wraps third-party web surfaces inside its own Electron shell. That directory is also a maintenance signal: patched upstream code has to be re-patched when upstream moves.

Installing holaOS and getting to a first real use

The README's Quick Start is a source build. It does not present a signed installer download, so treat this as a developer install. You need Node 24 or newer and Bun 1.3.6, both stated in package.json, and the platform badges list macOS on Apple Silicon and Intel, Windows, and Linux.

Clone the repository and install dependencies with Bun. The desktop:install script is just bun install, so running it directly is the same thing:

bun install

Before the desktop app will start, the app SDK has to be built. The desktop:prepare script runs the build for the @holaboss/app-sdk workspace package, which is what HolaApps are built against:

bun run desktop:prepare

Now start the desktop application in development mode. This filters to the holaboss-local package and runs its dev script:

bun run desktop:dev

An Electron window should open on the workspace. From there the README describes browsing the in-workspace marketplace to install an app, or connecting an integration through one-click OAuth. There is also a desktop:dev:isolated script that runs scripts/desktop-dev-isolated.mjs, which is worth knowing about if you want a development instance that does not share state with your normal one.

If you only want the documentation site locally, that is a separate npm path: npm --prefix apps/docs run dev. The docs scripts use npm rather than Bun, so do not assume one package manager covers both.

Where holaOS stops being the right tool

The licence is the first thing to resolve. The repository's licence field is NOASSERTION, meaning GitHub could not classify it, and the README badge says Modified Apache 2.0. A modified Apache licence is not Apache 2.0. If your organization has an allowlist of approved licences, this will not match it until someone reads LICENSE and decides. That is a legal question, not one this article can settle.

Second, the release story is thin. There is a release tagged holaOS Latest from 2026-08-06, and the repository's last push was 2026-08-21. That is a source repository with a single visible release tag, not a project with a documented version cadence. RELEASING.md exists, so there is a process, but the README does not document an upgrade path for an installed workspace, and it does not document rollback. If you need a product with a changelog you can pin to, this is not that yet.

Third, local-first cuts both ways. The README states your data never leaves your machines. That is a privacy property, and it is also an operations property: there is no server deployment described, no team sync described, and no way for a colleague to open your workspace from their machine. The chat tool integrations read Slack, Feishu, DingTalk and WeChat, which means the agent's reach is bounded by what those APIs expose and by the per-tool, per-scope approvals the README mentions. If your team's context lives in a system with no integration and no MCP server, holaOS has nothing to read.

Fourth, the model list in the README names Kimi K3, GLM 5.2, GPT 5.6, Claude Opus 5 and Fable 5 as built-in. Model names and availability change faster than repository documentation. Treat that list as a description of intent, and check the workspace itself for what is actually selectable. BYOK for OpenAI, Anthropic, or any OpenAI- or Anthropic-compatible endpoint is the escape hatch, and those calls run on your account and your rates.

holaOS against a plain coding agent CLI

The obvious alternative is what a lot of engineers already run: Claude Code or Codex on their own, in a terminal, against a repository. The difference is not the agent, because holaOS runs those same agents. The difference is what surrounds them.

A standalone CLI agent sees a working directory and whatever tools you wire into it per session. holaOS puts the agent next to live app surfaces and gives every agent in the workspace the same integrations, skills and memory. If your work is editing files in a repository, the CLI is simpler and has fewer moving parts: no Electron shell, no app SDK build step, no patches directory to maintain. If your work is driving Notion, reading a Slack thread, and acting on Gmail in the same task, the standalone CLI has no surface for any of that, and you would be building the glue yourself.

The honest comparison is that holaOS is a workspace product with an agent inside it, and the CLIs are agents you place wherever you want. Choosing holaOS means accepting a desktop application, a marketplace, and a build from source in exchange for the app-adjacent surfaces and shared memory.

Maintenance, upgrades and the licence question

The last push to the repository was on 2026-08-21, and it is not archived. That is recent enough that the project is moving, but the README does not describe a supported upgrade path for an existing workspace, and the repository does not show a versioned release train beyond the single holaOS Latest tag from 2026-08-06. If you build from main, you are tracking main.

The practical maintenance costs are visible in the file list. Bun 1.3.6 is pinned through packageManager, Node 24 or newer is required, and the build runs through Turborepo. The patches/ directory means third-party code is being modified in place; those patches have to be revisited when the upstream packages change. The memory scripts, memory:cleanup and memory:eval, suggest memory growth is a real concern the maintainers built tooling for, which is a point in the project's favour and also a hint that you should run cleanup rather than let it accumulate.

On licence: the repository reports NOASSERTION and the README badge says Modified Apache 2.0. Apache 2.0 includes an explicit patent grant and requires attribution and notice retention; a modified version can change any of that. Read LICENSE in full before shipping anything built on this, and if your organization distributes software, get the modification reviewed rather than assuming Apache terms apply.

Editorial conclusion

Adopt holaboss-ai/holaOS if you want an agent that works inside the apps and chat tools you already run, and you are willing to build from source with Bun and Node 24 on macOS, Windows or Linux. Do not adopt it if you need a stable published release line, a documented server deployment, or a licence you can classify without reading the LICENSE file, because the repository is marked NOASSERTION and the README describes a Modified Apache 2.0 badge instead. Verify first: open LICENSE and read what the modification actually changes, then run bun install and bun run desktop:dev on a throwaway machine before any real data touches the workspace.

Frequently asked questions

Official sources

1. holaboss-ai/holaOS on GitHub
2. Issues
3. Project website
4. README
5. Releases