English | 中文

AI Team OS

Shared context, accountable work, native agents.

AI Team OS is a shared operating layer for Claude Code and Codex. Keep tasks, project memory, reports and team messages in one place, and follow work across sessions in one Dashboard. Each host keeps its native agent tools; the OS provides the durable record that makes their work understandable and reusable.

🤝 Codex is supported. Use Codex or Claude Code on its own, or connect both to the same OS task wall, project memory, reports, channels and Dashboard. Codex uses its own MCP and hook configuration; native agent tools, host settings and hook trust remain separate. See the installation and capability sections below for the per-host setup and boundaries.

⚡ v1.15.0 - One notice channel, sturdier hooks. Things OS needs you to know or do now come from one bilingual ledger, shown at session start, on your next message or when a turn ends, and each host hears only about its own install. Failed hook deliveries are counted and resent by later hooks, text meant for other agents is checked when it is written, and one shared digest leads the task wall. Codex users need to update the adapter once by hand; see the changelog.

Full version history: CHANGELOG.md

116 MCP tools · 232 REST endpoints · 24 dashboard pages · 25 agent templates · 42 ecosystem research tools · 25 machine-checked invariants

---

A session can end without taking the team's context with it. Tasks, memos, decisions and reports remain available to the next authorized session, whether it runs in Claude Code or Codex.

---

What Carries Across Sessions

Parallel agents are useful only when you can tell who owns the work, what actually happened and where to resume. AI Team OS keeps those answers outside any single chat:

• Tasks and handoffs: ownership, progress memos, blockers and completion records stay on the project task wall.
• Project memory and reports: retrieve earlier decisions and evidence instead of rebuilding context from scratch.
• Team communication: send and read project-scoped messages across hosts, with explicit reader identities and acknowledgements.
• Operational visibility: inspect Leaders, members, tool activity and project-level totals in one Dashboard.

The OS records and exposes the work. Your chosen host runs the agents, and you decide what they are authorized to do.

---

How It Works

You set the scope. Each root session has its own Leader. A Claude Leader and a Codex Leader can contribute to the same project without pretending to be the same process or sharing host configuration.

1. Resolve the project and read its task wall, relevant memos and memory.
2. Let the session's Leader coordinate authorized work using its host's native agent tools. Members belong to their parent team; Codex's native nicknames stay distinct from roles and task names.
3. Record progress, decisions and reports through the shared MCP tools. Other sessions can pick them up through the same project records and channels.
4. Inspect the Dashboard to compare recorded work with current activity. The observation updates label the host, show only fresh working evidence in current views and fold waiting or historical records away without deleting them.

Claude Code's installed hooks can supply startup briefings and direction-layer context automatically. Codex can read the same records through MCP, with its own adapter handling supported observations. The OS does not replace either host's scheduler, permissions or agent lifecycle.

---

Core Capabilities

1. Cross-Session Coordination

Shared project records and channels connect sessions while execution stays native to each host:

• One Leader per root session: the implementation combines registered sessions with Claude file observations and labels Claude Leader and Codex Leader explicitly. Native Codex children join the parent team instead of becoming extra Leaders.
• Current work and history: fresh busy evidence drives the current roster; waiting, closed and stale records remain available as history. Unknown source or model information stays unknown.
• Project and worktree visibility: inspect current tasks, observed context and uncommitted work before handing off or continuing a session.
• Cross-host messages: use channel_send, channel_read and channel_wait for explicit communication. A pending wait can return new messages; it does not restart an ended Codex turn.
• Claude Code extensions: the existing fleet path can resume a Claude session for one turn, and installed CC hooks support compaction checkpoints, session-registry observations and background-job visibility. These execution and injection paths are not Codex features.

2. Memory System v2 - Shared Direction and Task History

Keep team preferences and task evidence available across sessions, without relying on a single chat's remaining context.

• Direction layer (user preferences / corrections / design intent, 4 kinds): stored with per-bucket character quotas (global 1200 + 1500 per project + user 300 = 3000 chars, <=400 chars per entry), replacement via supersedes and auditable invalidation rather than deletion. Writes are scanned for invisible characters, instruction-override patterns and credential shapes. Claude Code's SessionStart and SubagentStart hooks inject this context; Codex retrieves the shared records through its configured tools.
• Episodic layer (task_memos ledger): task-level execution memos promoted to a dedicated table (row IDs / invalidation axis / quality score / scope_path), recalled on demand via pure-Python BM25 Chinese retrieval; 123 legacy memos backfilled with zero loss.
• On-demand reconcile (memory_reconcile): zero-LLM BM25 candidate clustering, then merge / invalidate / score / distill on agent confirmation — "the agent computes, the