A successful build leaves the desktop workflow unverified
holaOS puts agents beside interactive application surfaces. The useful question for an evaluator is whether that shared workspace fits the team's work and can be verified on its machines.
The README describes Claude Code, Codex, and the built-in holaOS agent using the same memory, tools, skills, and apps. It also describes browser surfaces, MCP servers, workflow skills, and OAuth integrations. These are project descriptions, not capabilities demonstrated by our recorded run.
What our recorded run established
Our stored run is dated September 29, 2026, at 03:25:58.219 UTC and targets commit 4684714 (4684714ee133794cdbb86630e42b7d93447fb2e2). The commit date is August 21, 2026. No new execution was performed for this correction.
The recorded configuration was 3 CPUs, 8 GB of memory, and image lab-node:22. The image name does not establish the actual runtime version. The checkout measured 35 MB, 1,962 files, and approximately 504,013 lines of source. Detection recorded five CI workflows and monorepo workspaces. Its negative root-Dockerfile and top-level-tests-directory signals do not establish that the repository lacks Docker files or tests elsewhere.
| Recorded step | Result | Elapsed time |
|---|---|---|
| Dependency installation | Exit 0 | 74 seconds |
| Build | Exit 0 | 79 seconds |
| Test command | Exit 1 | 68 seconds |
The dependency inventory recorded 2,035 packages and 3,425 MB. The Bun v1.4.2 install tail reported 2,020 packages installed in 55.47 seconds. That tool-level message differs from both the inventory count and the full install-step duration of 73,834 milliseconds. The table uses rounded full-step timings consistently.
The build log reported 17 successful tasks out of 17, with none cached. It also emitted chunk-size and ineffective-dynamic-import warnings. Build completion establishes that this command succeeded in this environment; it does not establish desktop usability or workload performance.
Why 21 passing tests is not an overall pass
The parser recorded a Vitest summary of 21 passed and zero failed. The raw tail identifies those 21 as the runtime-client package's tests. It also includes passing summaries for other packages, so 21 is not an exhaustive repository-wide total.
The overall test command exited 1. The task summary named @holaboss/runtime-harness-host#test as failed, while the tail also listed failing-test sections for runtime-state-store and runtime-api-server. API-server entries included the message "Promise resolution is still pending but the event loop has already resolved".
Eight of the 19 test-command tasks were cached, and the task summary reported 15 successful tasks. Task counts are not individual-test counts. The stored summaries have not been reconciled into an exhaustive, unique test total. Neither "all tests passed" nor a repository-wide count of 21 is supported.
The record does not establish whether the unsuccessful command resulted from environment requirements, test assumptions, or application defects. It also does not verify an installed binary, interactive Electron launch, model calls, OAuth connections, or an agent completing a representative workload. No security audit result was recorded.
Follow the desktop setup path separately
The install guide requires Git, Node 24 or newer, and npm. The README's setup handoff specifies Node.js 24.14.1/npm. Its installer is described as provisioning prerequisites, creating apps/desktop/.env, running npm run desktop:install, preparing the runtime with npm run desktop:prepare-runtime:local, and verifying with npm run desktop:typecheck.
The guide treats npm run desktop:dev as a separate, interactive launch step. It says headless environments should stop after desktop verification if they cannot open Electron windows. The development path checks the environment, rebuilds native modules, and ensures a staged runtime exists. The published-runtime alternative is npm run desktop:prepare-runtime.
Our Bun install and source build are not evidence that this entire desktop runbook completed. For a useful trial, follow the documented path on a graphical machine and record launch separately from type checking. Then test one workflow with the model provider and integrations you intend to use.
Local storage is a claim to verify alongside provider routing
The README says workspace files, memory, embeddings, and session history live on local disk. It also offers account-backed models, bring-your-own OpenAI or Anthropic keys, compatible endpoints, and external integrations.
Local storage and external-service use answer different questions. A configured remote provider or SaaS integration needs request data to perform its task. Our run did not measure network traffic, retention, approval enforcement, or which content each connection receives. Treat the README's privacy and permission statements as claims to validate against your intended configuration.
Check the license before distribution
The supplied license is modified Apache 2.0. It explicitly says internal use within a single organization, including multiple workspaces, does not require a commercial license. It restricts providing hosted services to third parties and embedding holaOS in commercially distributed products or services unless authorized in writing, with a commercial license required under the stated conditions.
It also prohibits removing or modifying frontend logo and copyright information; that condition does not apply to uses that do not involve the frontend. Contributors agree that the producer may adjust the agreement and use contributed code commercially. Review these terms before planning a hosted derivative or white-label product.
The supplied release extract identifies holaOS-2026.822.1, released on August 22. That release is separate from our measured source commit and does not establish that we installed or tested its packaged assets. We do not infer current maintenance quality or adoption from that release entry.
How to read the scores
These are editorial assessments of the supplied evidence, not benchmark results. The scale is 1 for substantial documented obstacles, 2 for limited evidence or unresolved evaluation requirements, 3 for a usable documented path with material caveats, 4 for strong documentation or verification within the assessed scope, and 5 for broad corroboration across that scope. Unknown adoption and untested compatibility cannot earn a high score.
Setup receives 3 because dependency installation and build succeeded, but desktop setup and launch remain unverified. Documentation receives 4 for its explicit prerequisites, staged commands, and headless-environment guidance. Community receives 2 because the supplied evidence cannot establish contributor breadth, response times, or adoption. Maturity receives 2 because the overall test command was unsuccessful and no interactive workload was verified; this rates the evidence available for adoption, not a proven product failure.
The next useful check is a documented desktop trial at a pinned revision: record runtime versions, verify launch, reproduce the test-command outcome, and complete one representative task with narrowly scoped permissions.