holaOS: Letting Claude Code and Codex Share One Brain

Forum topic · ✨步子哥 · 2026-08-13

Summary

holaOS is an open-source, cross-platform desktop workspace that lets multiple AI coding agents—Claude Code, Codex, and its built-in holaOS Agent—operate in the same environment with a single shared memory. Instead of replacing agents, it solves the 'memory silo' problem: when switching between agents, context, preferences, and project history persist in locally stored plain files that users can read and edit directly. Key design decisions include agent neutrality (no lock-in), file-based memory for debuggability and portability, and a dual model strategy combining built-in access to SOTA models with bring-your-own-key support. The platform integrates 100+ tools via MCP (Model Context Protocol), letting any MCP-compatible tool be used by all supported agents. Built with TypeScript and Electron for macOS, Windows, and Linux under a Modified Apache 2.0 license, the project gained 380 stars in a day. The article contrasts holaOS with macro-inc/macro (a team collaboration workspace) and OpenAI's cloud-based Memory, arguing holaOS's approach could become a foundational design pattern for AI workspaces—if its memory format proves portable.

A Confusing Opening

If you saw holaOS's description on GitHub, your first reaction might be "another AI desktop":

> Run any agent — Claude Code, Codex — across your tools (100+ integrations + MCP), apps, browser, and files, with shared memory.

But reading this closely reveals an unusual positioning: it doesn't replace any agent — it lets multiple agents share the same working environment.

This is a completely different path from editors like Cursor or Windsurf that ship with built-in agents.

The Core Problem: Agent "Memory Silos"

If you use Claude Code and Codex side by side, have you run into this?

Claude Code refactors a module and has your entire project structure in context
You switch to Codex to write another feature, and it knows nothing about the refactor
You have to manually tell Codex what Claude Code did, or have it re-read the code

This is the "agent memory silo" problem. Every agent has its own context window, session history, and tool configuration. Switching agents means swapping in an "amnesiac colleague."

holaOS aims to solve exactly this. Its core promise:

> Context, preferences, and project history live in a single shared memory — stored locally, as plain files you can read and edit.

The keywords are shared and locally. Shared means it works across agents; local means it isn't locked inside some cloud service.

Three Design Decisions Worth Examining

1. Agent-Neutral, No Lock-In

holaOS doesn't build its own agent; it runs Claude Code, Codex, and its bundled holaOS Agent side by side. The README is blunt:

> No lock-in — bring the agent you already trust.

This aligns with the principle that "division of labor beats unification" — holaOS provides workspace infrastructure, agents do the reasoning. You won't have to rebuild your workflow just because you switch agents.

2. Memory Is Files, Not a Database

holaOS's shared memory lives in local files you can open and edit directly. This decision is critical:

Debuggable: when an agent misbehaves, you can inspect its memory files to find out why
Migratable: memory isn't locked down when you switch tools
Trustworthy: users have full visibility into "what the AI remembered"

This contrasts with OpenAI's Memory feature — which lives in the cloud, where users only see summaries and can't edit raw data.

3. BYOK Models + Built-In Models

holaOS offers two modes:

Built-in models: one account to use all SOTA models (Kimi K3, GLM 5.2, GPT 5.6, Claude Opus 5, Fable 5), no API key management needed
BYOK: use your own OpenAI/Anthropic keys, running on your own accounts

This dual-track design is pragmatic — zero friction for newcomers, control preserved for power users.

Relationship With MCP

The README mentions "100+ integrations + MCP." MCP (Model Context Protocol) is Anthropic's standardized agent-tool interface protocol. holaOS supporting MCP means:

Any MCP-compatible tool can be called by agents inside holaOS
An MCP server you write can be used simultaneously by Claude Code, Codex, and the holaOS Agent

Back to "division of labor beats unification" — holaOS doesn't reinvent tool protocols; it uses MCP, a de facto emerging standard, to connect existing tools.

A Question Worth Asking

holaOS's positioning is clear, but one question deserves scrutiny: what is the shared memory format?

The README says "stored locally, as plain files you can read and edit," but doesn't specify. If it's custom JSON, cross-tool migration still requires conversion. If it's a standard format (say, Markdown + frontmatter), portability is much stronger.

The answer determines whether holaOS is "a product" or "an ecosystem" — the former locks users into holaOS; the latter could make it the de facto standard for agent workspaces.

Comparison With macro-inc/macro

Trending the same day was macro-inc/macro (+1180 stars), positioned as "unified workspace for teams: email, chat, docs, tasks, agents, calls, and CRM." Both build "unified workspaces," but in different directions:

macro: team collaboration, integrating communications, docs, CRM and other business tools
holaOS: developers, integrating agents, MCP tools, and local files

macro wants to replace Notion + Slack + Salesforce; holaOS wants to replace Cursor + Claude Desktop + various MCP hosts. Different markets, but both point to the same trend: tool fragmentation has reached a point users can no longer tolerate.

Data

Repository: holaboss-ai/holaOS
+380 stars today
Platforms: macOS, Windows, Linux
Tech stack: TypeScript + Electron
License: Modified Apache 2.0
Website: holaos.ai

---

*holaOS's core bet: users no longer want to rebuild their work environment for every agent. If that bet pays off, "agent-neutral + shared memory" may become a foundational design pattern for AI workspaces.*