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.16.0 - OS data gets its own directory, and every path follows your Claude Code and Codex config folders. Data moves from inside the Claude Code config folder to ~/.aiteam (AITEAM_DATA_DIR overrides it); an update you start moves it only after seven safety checks pass, and otherwise leaves it in place with a notice. CLAUDE_CONFIG_DIR and CODEX_HOME are respected throughout, and aiteam paths shows what a shell resolves. Codex pricing adds the Ultrafast tier, and codex exec launches from Claude Code are recorded with the tier they requested. Close other Claude Code and Codex sessions before updating; afterwards restart the API and reopen every session; see the changelog.

Full version history: CHANGELOG.md

118 MCP tools · 242 REST endpoints · 24 dashboard pages · 25 agent templates · 42 ecosystem research tools · 30 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 tool persists”, with no background resident process introduced.

Surfaces: MCP memory_add / memory_list / memory_invalidate / memory_search / memory_reconcile_candidates / memory_reconcile_apply.

3. Progressive Tool-Loading Governance (new in v1.9.0)

Choose the MCP surface for each client instead of loading every capability into every session.

• alwaysLoad dynamic rotation: at session start a single SQL recomputes the hot-tool whitelist by 7-day real call frequency (>=2-day span gate against bursty spikes + 20% hysteresis, hard cap <=5), and CC skips ToolSearch for them. Not additive, not hand-tuned; any stats failure silently degrades to all-defer, and every whitelist is logged for audit.
• AITEAM_TOOLSETS group switch: 17 capability-domain toolsets; a startup env var decides which modules register. default core profile = task/team/memory/infra/reports/notices (30 tools, hard cap <=50), with incremental default,ecosystem - fits non-CC clients that cap tool counts.
• AITEAM_READONLY read-only profile: an orthogonal overlay that strips every write tool by explicit allowlist and keeps only read tools — ideal for audit / observer sessions.
• 6 Claude Code templates declare least privilege: meeting-facilitator / debate advocate & critic / technical-writer / project-manager / tech-lead carry disallowedTools entries for destructive OS tools (delete project, delete team, restart API). Claude Code 2.1.281 enforces them for both project- and user-level definitions (verified 2026-09-25); older versions may treat them as declarations only. Codex uses its own native permission controls rather than interpreting CC template fields.

4. Claude Code Workflow / ultracode Observability (v1.7.0)

The OS does not intercept CC’s built-in ultracode/Workflow — it becomes its persistent governance layer. Every Workflow run is automatically tracked into the OS, with no manual team setup:

• Auto-tracking: a hook turns each Workflow run into an OS “team” (workflow-) the moment it starts
• Dashboard /workflows: a live feed of run cards, a phase swimlane timeline, and per-agent telemetry — tokens / duration / status / tool-call counts, advancing live via incremental journal tailing while a run executes
• Calibrated stall detection: the stall threshold was calibrated on 3,378 real agent intervals (p99 = 77.6s, longest healthy silence 173.8s) and set at 5.2× the worst healthy case — it flags late rather than crying wolf
• Project-detail integration: workflow team rows carry an inline run summary (status / agent count / duration / finish time) plus a “view swimlane” deep link; members display semantic phase labels (e.g. audit:sourceA) instead of ids
• Claude Leader file observations: the backend can supplement registered Leaders with session, model and liveness observations from Claude’s local records. Codex identity follows its separate native metadata path.
• MCP tools: workflow_list (browse runs), workflow_get (full archive + per-agent rows), workflow_reconcile (repair from on-disk snapshots after the OS was offline)
• Self-healing ingestion: hook receipt anchors + on-disk snapshot reconciliation + a reaper backstop close offline gaps automatically — finished runs on disk are ingested idempotently; cross-project attribution matches the on-disk path slug against registered projects

5. Ecosystem Research Platform — 42 tools

A project-isolated knowledge base that accumulates research findings over time. Each repo progresses through 4 stages (a progressive funnel, since v1.5.0), with token-efficient triggers and append-only history:

• Stage 0 — Auto shallow-summary on archive: newly-archived repos automatically get a 200-400 char ai-engineer summary (core function / positioning / advantages). 8-class failure handling with self-learning hooks (3+ same-class fails surface through self_learning_pending; the queue exposes recorder/searcher injection points you can wire to your own lesson store)
• Stage 1 — On-demand architecture analysis: user picks research direction (“memory_system”) → batch-dispatch backend-architect agents to read architecture key files
• Stage 2 — Multi-perspective debate: triggers existing debate_start (NOT a built-in debate engine — reuses meeting system)
• Stage 3 — Reference / Integrate marking: mark_as_reference adds tag for future quick recall; start_integration triggers existing task_create for actual implementation
• Active vs Full dual-view: data is append-only forever. Stars-falling repos kept (just is_active=False); stars climbing back auto-promotes + re-queues Stage 0
• Dashboard /ecosystem: list with stage badges + research timeline + project filter dropdown + candidate-filter page (/ecosystem/research) + per-project settings tab — the single largest tool family in the OS

6. Knowledge Layer — Reference Graph + Unified Search (v1.8.0)

Everything the OS records — task memos, reports, tasks — becomes recallable knowledge:

• Reference graph (P1a): a zero-LLM regex extractor mines OS-native ID references (wf_id / commit hash / task uuid / [[memory]]) out of memos and reports into an append-only knowledge_links table — the graph is a derived view, rebuildable from source text at any time
• Unified search (P1b): /api/search fuses three arms via RRF — BM25 full-text (Chinese bigram native), knowledge-graph fanout (an ID query pulls in everything linked to it), and exact ID-prefix / title match
• Global search box in the Dashboard header, plus MCP tools unified_search / link_query / link_trace — recall past work by natural language (“how was the attribution fix done”), a wf_ id, or a commit hash

Why zero-LLM retrieval? ID extraction and search run locally without a model call, and the graph can be rebuilt from source text. Reading retrieved results into an agent’s context still consumes that host’s normal context budget.

7. Task Wall, Reports and Dashboard

Governance ledger and panoramic visualization — everything leaves a trace:

• Task wall: a live board of pending / in-progress / done, event-driven + intelligent Agent matching + deadlock detection
• 8 structured meeting templates (keyword auto-select, built on Six Thinking Hats / DACI / Design Sprint) — every meeting must produce an actionable conclusion; “we discussed but didn’t decide” is not an outcome
• Shared React 19 Dashboard: project task walls, reports, agent activity, events and Analytics sit alongside the Claude-specific Workflow and model-governance views.

8. Work That Can Be Resumed

The task wall gives a running Leader a durable plan:

• Find the next authorized item and record ownership before dispatching native agents.
• Keep blockers and approval requests visible through task memos and briefings.
• Hand off progress and evidence so another session can continue without guessing.
• Turn research findings and review decisions into explicit follow-up tasks.

Continued execution depends on the host session and the automation you enable. Persistent records do not imply an always-running model.

9. Evidence-Based Observations

The OS separates recorded facts from inferred or missing information:

• Host-specific identity: Claude file observations and Codex’s exact native session metadata remain distinct. Codex’s nickname and parent chain determine member identity; role text and ID appearance do not.
• Freshness and ownership: the implementation combines persisted project/session bindings with recent activity, keeping current work separate from historical rows. Event and Analytics project filters follow recorded ownership.
• Reliable tool records: stable Codex call IDs pair starts and completions across retries and API restarts. Later hooks can retry completion metadata within bounded limits; absent trustworthy start/end evidence, duration stays unknown.
• Workflow telemetry: the Claude Workflow view reconciles on-disk journals with persisted observations and exact project-path attribution.

10. Claude Code Model Governance (v1.8.1)

Inspect models observed in Claude Code transcripts and choose Claude Code’s startup default. This setting does not control Codex’s model selection.

• Transcript-based discovery: local CC records supply observed model names, including third-party gateway names, with a 60s cache. This is observation history, not a live account-availability test.
• One-click global default startup model: written to Claude Code’s settings.json (in the config folder, see “Where Data and Configuration Live”) under triple write protection: touches only the model key, keeps a .bak-aiteam backup, writes atomically, refuses corrupted files
• Zero coercion: soft reminders only, never a block — and CC Workflow runs are fully exempt

Surfaces: REST /api/models/{available,default} · MCP model_config_get / model_config_set · the Model Governance card in Dashboard Settings.

11. Team Collaboration

Coordinate native agents and peer Leaders without flattening their identities:

• 25 professional role templates (23 base + 2 debate roles) with a recommendation engine for engineering, testing, research and management. Claude Code installs them as native templates; Codex keeps its own native agent setup.
• Department grouping — Engineering / QA / Research with cross-team coordination
• Channel communication: team: / project: / global channels with @mention support
• Cross-host messaging: sending, reading and acknowledging use shared channels with distinct reader identities. Prompt-time unread hints have been measured on Claude Code and on Codex CLI/Desktop; the Codex hint uses structured additionalContext, not plain hook stdout.
• Explicit waiting: channel_wait holds a call open and identifies initial replay, event-triggered read or final timeout read in delivery_source. It is separate from acknowledgement and from Claude Code’s optional session watcher; it does not wake an idle Codex session after a turn ends.
• Debate mode: 4-round structured debate (Advocate→Critic→Response→Judge) via debate_start / debate_code_review

12. Full Transparency

Trace the observations and records behind the Dashboard:

• Decision Cockpit: event stream + decision timeline + intent inspection — every decision has a traceable record
• Activity Tracking: observed agent status, current work and retained history, with explicit unknown values when evidence is missing
• What-If Analyzer: compare multiple approaches before committing, with path simulation and recommendations

13. Safety & Behavioral Enforcement

OS checks complement each host’s native approvals and isolation controls. Install and review the applicable host hooks rather than assuming one host’s rules protect the other:

• Guardrails L1: 7 dangerous pattern detections + PII warnings + InputGuardrailMiddleware
• Claude Code dispatch checks: CC-specific hook and template rules validate its agent-dispatch fields; they are not Codex’s native agent schema
• Root and home directory deletion: left to Claude Code’s native dangerous-removal protection
• 4-layer defense rule system: 37 rules covering workflow, delegation, session, and safety layers
• Concurrent-edit warnings: hooks flag a file two agents touched in quick succession, read straight from recent edit events (the cooperative file-lock tools were retired in v1.10.3 — the lock file was empty in every real run)
• Agent Watchdog: on-demand POST /api/teams/{id}/watchdog/check plus the background patrol — flags BUSY-timeout agents, long-pending tasks and unblockable dependencies
• Self-patrol: watchdog lease patrol + reaper reconciliation backstop + identity verification before any kill — the OS keeps eyes on itself, not just on your agents
• Completion verification: verify_completion checks task status and memo existence; artifact review and relevant tests still establish whether the requested result is correct
• Ecosystem integration recipes: 4 preset recipes (GitHub / Slack / Linear / Full-stack team) under find_skill(level=2, category="integration")
• find_skill 3-layer progressive discovery: quick recommend → category browse → full detail, reducing tool-call overhead

14. Local-First Infrastructure

The OS does not require its own hosted model service:

• MCP tools, hooks, storage and the Dashboard run locally.
• Graph extraction, BM25 search and reconciliation candidate generation do not call a model.
• Agent reasoning, retrieved context and AI-assisted research use the configured host’s normal subscription or API budget; external integrations may have their own costs.
• Full Codex token and cost attribution is not yet available. Unknown usage is not a measured zero.

More Capabilities (legacy & secondary — still running, queryable on demand)

• Failure analysis (frozen): failure_analysis, diagnose_task_failure and prompt_effectiveness stay callable but are frozen and no longer developed.
• AWARE loop memory · find_skill 3-layer discovery (skills + integration recipes) · Prompt Registry: see the full tool table below. The scheduler and the loop state machine were retired in favour of CC-native Cron* and on-demand tools (CC-is-not-always-on principle); the wake_agent schedule kind survives for the fleet wake subsystem.

---

Shared HTTP MCP

The shared HTTP MCP connection reuses the OS API and supplies each connection’s working directory through a short-lived helper. The complete Codex installer configures on-demand API startup; a manually configured read-only helper still requires an already running compatible API. Reload the host connection after configuration changes. Project isolation is preserved, while automatic Codex session identity remains unknown. Claude’s stdio configuration is unchanged.

Plan Capacity and API-Equivalent Pricing

The window’s Reset calculation start button explicitly replaces its statistics anchor with the latest saved observation. It preserves usage history and monitor settings, does not trigger a capture, and survives API restarts. A later allowance reset starts a new cycle normally.

An independent, versioned OpenAI price catalog supports per-request estimates through aiteam pricing and /api/pricing. It includes verified public rates, exact aliases, cache read/write prices and context/service-tier rules. Supplement a catalog and recompute the same inputs without retaining missing prices as zero. Results include price provenance, a content hash and request coverage; they are not subscription charges. See the pricing guide and price sources.

The independent /usage/accounts Dashboard page shows the native percentage used and estimated plan capacity in USD, labeled Local-sample estimate. Identified responses use their actual model, input, cache read/write and output usage at verified Standard API rates; when native service_tier is recorded, logged Fast/priority tiers use the catalog Fast rate (2× Standard). Long-context bands use each request’s full input, including cache, never the session total. Known dollar contributions are accumulated from the cycle anchor and compared with the same cycle’s allowance change. Account attribution and request-price provenance remain separate from the prediction assumption described below. This is an API-equivalent local workload sample, not a subscription charge, cash balance, complete cross-device ledger or official fixed capacity. No request-log import or billing access is required. Existing Token attribution and Claude configuration remain unchanged. See the account guide.

Prediction starts by default after the local Codex account is verified. Users can choose a 30-second to 30-minute interval or explicitly pause prediction; saved choices survive API restarts. The estimate always compares the earliest observation in the current allowance cycle with the latest one: known API-equivalent dollars divided by the increase in percentage points, multiplied by 100. Only a rollback in the account usage percentage, which confirms that the allowance was reset, moves this anchor; a standalone resets_at timestamp change does not. Missing contributions count as zero for this prediction, while the original records retain their unknown or incomplete state. A 1% increase is enough; Spark usage remains separate. This is not an AI-session heartbeat and never launches a model turn.

Usage recording is independent of prediction. An API-lifetime recorder incrementally saves available native usage events, including missing-model and unknown-provider observations, with persistent file cursors. Pausing prediction or closing the page does not stop recording. Complete lines and cursors are committed together; partial tails and late records can be read later. Existing logs can be backfilled after restart, but deleted, never-recorded history and unobserved quota readings cannot be reconstructed. The recorder stores usage fields, not conversation text or credentials; retaining an event does not automatically attribute it to the current account. See the account usage guide.

Used to Build This Project

AI Team OS manages its own development — and since v1.7.0, it can prove it with its own telemetry:

Claude Code and Codex sessions use the same task records and channels to exchange implementation and review evidence. Their native execution histories stay distinct; the OS provides the common project record.

• Every feature line from v1.7.0 to v1.9.0 — the observability layer, the knowledge layer, model governance, Memory System v2, tool-loading governance — shipped through CC Workflow runs that the OS tracked itself. Open /workflows and replay how the system built its own features, swimlane by swimlane.
• Competitive research across CrewAI, AutoGen, LangGraph, and Devin feeds the roadmap through multi-agent brainstorming meetings — the minutes live in the OS’s own report store.
• It learns from its own incidents, too: every machine-checked invariant in scripts/check_invariants.sh was distilled from a real accident in this repo’s history.

The same task wall, reports and observations used in development are available for your projects.

---

How It Compares

---

Architecture

Claude Code native agents -> CC MCP / hook adapter    \
                                                      > Shared OS API -> SQLite
Codex native agents       -> Codex MCP / hook adapter /       |
                                                             +-> Dashboard

The database holds project-scoped tasks, memory, reports, channels and observations. Each host owns its scripts, registration, trust and native agent controls; sharing the OS backend does not merge those settings.

Five-Layer Technical Architecture

Layer 5: Web Dashboard    — React 19 + TypeScript + Shadcn UI (24 pages)
Layer 4: CLI + REST API   — Typer + FastAPI
Layer 3: Team Orchestrator — LangGraph StateGraph (optional extra — CLI graph execution only)
Layer 2: Memory Manager   — SQLite-backed store + pure-Python BM25 retrieval
Layer 1: Storage          — SQLite (WAL journaling) · PostgreSQL support on the roadmap

Host Adapters

Claude Code’s plugin and Codex’s adapter feed the same OS through separate installation and trust surfaces. The Codex adapter lives in plugin/harness/codex/; its observation entry and matching helper modules must be installed together. The following event map describes the Claude Code adapter only.

Hook System (11 scripts across 16 Lifecycle Events - Claude Code Adapter)

SessionStart     → auto_install.py, session_bootstrap.py, send_event.py
                   - Auto-install deps + inject Leader briefing / core rules / team state
                 → session_bootstrap.py resume-tick (resume/fork only)
                   - A stamp that differs on every start, so Claude Code keeps the notice line
SubagentStart    → inject_subagent_context.py, send_event.py   - Inject sub-Agent OS rules (2-Action etc.)
SubagentStop     → send_event.py                 - Record sub-Agent lifecycle event
PreToolUse       → workflow_reminder.py, send_event.py
                   - Workflow tracking reminders + event forwarding
PostToolUse      → deep_review_link.py, send_event.py
PostToolUseFailure → send_event.py               - Close the activity of a failed or interrupted tool call (status error)
TaskCompleted    → send_event.py                 - Record a CC task completion (observation only)
TaskCreated      → send_event.py                 - Record a CC task creation (observation only)
TeammateIdle     → send_event.py                 - CC's own teammate-idle signal, recorded alongside the OS liveness track (observation only, changes no status)
UserPromptSubmit → context_tracker.py            - Track context usage
                 → channel_unread.py             - Unread channel badge
                 → turn_end_guard.py             - Mark the user as present (user-prompt mode)
SessionEnd       → send_event.py                 - Record session end event
Stop             → send_event.py                 - Record stop event
                 → turn_end_guard.py             - Keep the turn going while work runs with no watcher armed
PermissionDenied → permission_denied_recovery.py - Permission-denied self-recovery
PreCompact       → pre_compact_save.py           - Freeze the OS-side battle state (in-flight agents / open tasks / pending decisions) into a checkpoint
PostCompact      → send_event.py                 - Confirm the compaction actually happened (a triggered compaction can still be cancelled)
WorktreeRemove   → send_event.py                 - An isolated worktree is gone

---

Choose an Installation Path

For Claude Code’s AI-assisted installation, tell Claude Code:

“Read https://github.com/CronusL-1141/AI-company/blob/master/INSTALL.md and follow the instructions to install AI Team OS”

Claude Code can read the install guide and walk through its plugin setup. Codex users should follow the separate manual path below; the Claude installer is not a Codex installer.

---

Important: Install AI Team OS to your system Python, not inside a project virtual environment. If installed in a venv, AI Team OS will only work in that specific project. Run deactivate first if a venv is currently active, then install.

---

Quick Start

Prerequisites

• Python >= 3.11; Python 3.12 is recommended for development and validation
• uv (pip install uv)
• Claude Code or Codex with MCP support; hook setup is host-specific
• Node.js >= 20 (Dashboard frontend, optional)

Option A: Claude Code Plugin Install

Pick one of Option A or Option B, not both. Each installs the same MCP server; running both loads it twice in every session. The source installer detects an enabled plugin and skips global MCP registration unless you pass --force-mcp.

# Install uv (Python package runner, required for MCP server)
pip install uv

# Add marketplace + install plugin
claude plugin marketplace add CronusL-1141/AI-company
claude plugin install ai-team-os

# Restart Claude Code after installation; the first launch configures dependencies

# Update to latest version anytime: refresh the marketplace first
# (plugin update alone reports the installed version as the latest)
claude plugin marketplace update ai-team-os
claude plugin update ai-team-os@ai-team-os

Note: Claude Code’s first launch configures dependencies; duration depends on the local environment. Verify the loaded MCP tools and installed hooks rather than relying on startup time.

Option B: Claude Code Source Install

Pick one of Option A or Option B, not both. If the plugin is already enabled, install.py prints a skip line for global MCP registration; use --force-mcp only when you intend to run two copies.

# Step 1: Clone the repository
git clone https://github.com/CronusL-1141/AI-company.git
cd AI-company

# Step 2: Run the Claude Code installer (MCP + CC hooks + CC templates + API)
python3 install.py

# Step 3: Restart Claude Code — everything activates automatically
# API server starts automatically when MCP loads. No manual startup needed.
# Verify: run /mcp in CC and check that ai-team-os tools are mounted

Dependencies: greenlet (needed by SQLAlchemy async on Apple Silicon) is bundled by default. LangGraph is an optional extra — only the CLI graph-execution path needs it: pip install 'ai-team-os[langgraph]'.

Option C: Codex Adapter Lifecycle

Codex uses the shared OS backend with its own adapter. The on-demand runtime is validated on macOS; it requires POSIX and has not been validated on Windows. Keep the source checkout and system Python available.

1. Clone this repository and install dependencies with your system interpreter: python3 -m pip install -e .. Follow the interpreter’s package-management policy; do not run the Claude installer to configure Codex.

2. Choose the existing local API address, or an available local port for a new service. Install the MCP connection, header helper and complete Hook adapter together:

   python3 scripts/codex_adapter.py install --api-url http://127.0.0.1:8000
   python3 scripts/codex_adapter.py status
   

   Replace 8000 with your chosen port. The installer backs up changed files, preserves unrelated settings and hooks, and rolls back failed writes. It respects CODEX_HOME. Opening a new Codex connection starts the API on demand; closing the terminal does not stop it. No login service or scheduled restart is installed.

3. Reload Codex and review its first-time Hook trust prompts in the CLI/TUI or Desktop Hook settings. MCP connectivity and Hook approval are separate checks.

4. After updating the repository and dependencies, run python3 scripts/codex_adapter.py update, then status. Source updates do not replace code already loaded by a running API. Follow the reported restart requirement: coordinate use of the shared service, stop only the runtime-owned API, then reconnect Codex. Externally managed APIs must be restarted by their owner. Unknown source state is not proof that an update is active.

5. Verify a real MCP tool call and the installed Hook observation in the API and Dashboard. File copies and tool discovery alone do not prove the complete observation chain. Script-body changes normally preserve trust; changed registrations may require approval again.

If you already use a stdio MCP connection and only want to update its Hook adapter, run python3 scripts/codex_adapter.py update --hooks-only. This preserves the MCP configuration byte for byte; switching transports requires a separate explicit migration.

Claude Code settings, startup briefings, templates and execution controls remain separate. This release does not enable HTTP/2 or change an existing Dashboard port.

Verify Installation

# Use the actual running API port; 8000 is the usual default.
curl http://localhost:8000/api/health
# Expected: {"status": "ok"}

To remove only this host integration, preview first and then apply:

python3 scripts/codex_adapter.py uninstall
python3 scripts/codex_adapter.py uninstall --apply

This removes owned Codex adapter files and registrations, and restores MCP fields still matching the installer’s values. User edits and unrelated integrations are preserved. The shared API, database, session history, credentials and Claude installation remain intact.

In either host, run context_resolve for the current project, read a task memo, and check the same project in the Dashboard. For observation changes, compare a real native tool call and its completion with the persisted activity record, then verify a native member’s name, parent team and state. Check the running API, Dashboard assets and installed hook files separately.

Where Data and Configuration Live

AI Team OS keeps three kinds of directory apart:

• The Claude Code installer installs into the config folder of the shell that runs it (CLAUDE_CONFIG_DIR when set). Pass --config-dir PATH to choose another; with several config folders, run it once per folder. On macOS and Linux the hook commands are written as ${CLAUDE_CONFIG_DIR:-$HOME/.claude}/hooks/ai-team-os/..., so a folder that is moved and pointed at again keeps running its own copies.
• One API serves the sessions of every config folder and reads each session’s transcripts and registrations in that session’s own folder.
• The Codex adapter respects CODEX_HOME. The two hosts meet only in the data directory.
• At run time the OS only looks for the data directory; it never creates or moves it. When it cannot be found, the session start says where it looked instead of starting on an empty database.

Existing users. Earlier versions kept the data in ~/.claude/data/ai-team-os, and it keeps working there. An update you start (python3 install.py --update, python3 scripts/update.py or python3 scripts/codex_adapter.py update) moves it to ~/.aiteam only after its safety checks pass: the API is stopped, no other process may have the database open, the write-ahead log is checkpointed, the directory is moved (an atomic rename on the same disk, a checksummed copy across disks) with a link left at the old place, and the restarted API must report the same task count, or the move is rolled back. If any check fails, nothing is moved, the data stays where it was, and a notice says why. --no-migrate-data skips the move. A plugin install never moves data at session start; the notice offers to do it when you ask (tell Claude “migrate OS data”, or run python3 -m aiteam.data_dir_migration --apply). python3 scripts/migrate_data_dir.py previews the same checks, --apply moves and --rollback moves back.

aiteam paths (same as python3 -m aiteam.paths) prints, as JSON, what this shell resolves:

aiteam paths            # data directory and its mode, Claude config folder, main-chain owner, install records, Codex home
aiteam paths --api      # also ask the running API which data directory it uses
aiteam paths --locate   # also look for databases left elsewhere, such as inside a moved config folder

First Words to Your Session

After configuring the selected host, make the shared records part of the working protocol:

“Resolve this project in AI Team OS, read its task wall and relevant memos, and record progress and decisions there. Use your own native agent tools for authorized work.”

Claude Code’s installed /os-help command can introduce its workflow. In Codex, use native tool discovery or your separately configured OS help skill; a Claude slash command is not automatically a Codex command.

Tool Loading Configuration (optional)

The MCP server can expose the full tool inventory or a smaller set for each client. Two environment variables are read at server startup; configuration changes take effect on the next start, not in an already running server.

AITEAM_TOOLSETS - pick which capability-domain groups register:

• unset or all - the full registered inventory (backward compatible)
• default - core groups only (task,team,memory,infra,reports,notices = 30 tools, hard-capped at <=50)
• a comma list of group names, mixable with default for incremental loading, e.g. AITEAM_TOOLSETS=default,ecosystem
• unknown names are warned on stderr and ignored (a config typo never blocks server start)

AITEAM_READONLY=1 - orthogonal overlay that strips every write tool (create/update/delete/apply/send/… plus os_restart_api) after registration, keeping only read tools. Handy for audit/observer sessions.

The 17 groups (default groups marked *):

# Example: lean core + ecosystem, read-only
AITEAM_TOOLSETS=default,ecosystem AITEAM_READONLY=1 python3 -m aiteam.mcp.server

Remove a Host Integration

# Claude Code plugin:
claude plugin uninstall ai-team-os

# The plugin leaves its global hook chain in place. Preview those leftovers:
python3 "${CLAUDE_CONFIG_DIR:-$HOME/.claude}/hooks/ai-team-os/uninstall_main_chain.py"
# Review the entries/files, then use the preview's token and your confirmation:
python3 "${CLAUDE_CONFIG_DIR:-$HOME/.claude}/hooks/ai-team-os/uninstall_main_chain.py" --apply "" --user-quote ""
# A disabled plugin can be re-enabled instead. Source-owned chains are refused.

# Preview the Claude Code source uninstaller before deciding what to remove:
python scripts/uninstall.py --dry-run
python scripts/uninstall.py   # keeps the data directory (aiteam paths shows it); --purge-data deletes it after showing it and asking

For Codex, remove only its own MCP/hook registrations and independently copied adapter files. Before removing shared OS data or passing --purge-data to the source uninstaller, inspect the plan, back up the records and confirm no other host still uses the backend. Removing one host’s integration is not permission to delete the shared database.

Start the Dashboard (optional)

cd dashboard
npm install
npm run dev
# Visit http://localhost:5174

---

Dashboard Screenshots

These screenshots show the v1.15.0 Dashboard running on a seeded demo database (scripts/demo_seed.py): a fictional product team working with Claude Code and Codex sessions. Names, numbers and times are sample data, not measurements from a real project. The captions explain what each view shows.

Command Center

Every active team on one screen, as the hooks recorded it: Claude Code teams, a Codex session whose members keep their native names, and the fan-out agents of a running workflow. The banner and the Pending card show what currently waits on you.

Task Board

The task wall opens with the same digest that session briefings read: open work by horizon, stale and blocked counts, recent activity, the top five and what is stuck. Below it, the short-, mid- and long-term columns list running work by latest activity and the backlog by score.

Unified Search

The search box in the header finds tasks, memos, reports and workflow IDs locally, without a model call.

Pending - Notices

One bilingual ledger holds what OS tells you at session start, on your next message or when a turn ends: waiting decisions, mentions addressed to the Claude or Codex Leader, and a Codex-only hook trust finding snoozed for a day. Blocks and branch switches that were shown on the spot stay below as a read-only record.

Pending - Decisions

Questions that agents raised for you, each with options, a recommendation, tags and urgency. Resolve one with your answer or dismiss it; the count feeds the sidebar badge and the banner.

Project Detail - Leaders and Worktrees

The Leaders working in the project right now, from both hosts: two Claude Code sessions with their context watermarks and a Codex Leader, each with its current task. Below them are the project’s Git worktrees with uncommitted-change and merge status.

Agent Board

Members with fresh working evidence, grouped by the Leader or workflow that dispatched them. Codex members keep their native nicknames, separate from their roles; waiting and historical members are folded away.

Workflows

Every Claude Code Workflow run is recorded automatically with its phases, planned and actual agent counts, tokens, tool calls and duration. Filter the list by project or status.

Workflow Detail - Phase Swim Lane and Per-Agent Telemetry

One Claude Code Workflow run: every phase’s agents on a shared timeline, with the failed contract check in red, and a table of tokens, tool calls, duration and state for each agent.

Plan Usage (Codex)

Estimated plan capacity in API-equivalent dollars for the 5-hour and weekly windows, next to the native percentage used, and the monitor that keeps sampling while the page is closed. These are local-sample estimates at standard API rates, not charges or balances.

Ecosystem Research Platform

The tracked open-source repositories with stars, language and topic tags, each ready to open for research and integration. This page’s interface text is not translated yet, so it appears in Chinese.

---

Waiting, Notifications and Continued Work

These are different operations, not one universal background scheduler:

• Prompt-time notification: an installed unread hook can show a message when the host starts the next prompted turn.
• Explicit waiting: either host can call channel_wait during an active turn. The call returns messages or a timeout and does not automatically acknowledge them.
• Claude Code session watcher: the existing CC-specific watcher can drive a live Claude session when enabled with the appropriate reader identity and permissions.
• Codex after a turn ends: this version does not provide mail-triggered automatic wakeup. Persistent inbox records remain available to a later turn.

Keep authorization and execution separate from notification. A pending task or new message does not grant permission to start unrelated work.

---

Ecosystem Integration Recipes

AI Team OS can coordinate records and handoffs around other MCP servers instead of reimplementing their capabilities. Recipes describe integrations that you configure and authorize in the host where the work runs:

Use find_skill(level=2, category="integration") to discover recipes, or see the full guide: docs/ecosystem-recipes.md

---

Shared OS, Native Hosts

• Shared project services: the same MCP tools, API, database and Dashboard hold tasks, memory, reports, messages and observations.
• Independent adapters: Claude Code and Codex keep their own scripts, registration, trust and native dispatch controls.
• Evidence before inference: bind observed identities and tool calls using native metadata; preserve unknowns instead of guessing from names or timestamps.
• Project-scoped views: task, event and Analytics queries use recorded project ownership; multiple teams can contribute without overwriting one another’s totals.
• Host-specific context delivery: Claude Code’s bootstrap and template hooks are its own integration. Codex can retrieve shared context without inheriting Claude configuration.

---

FAQ

Do I need both Claude Code and Codex?

No. Either can use the shared OS services. Connecting both adds cross-host handoffs; it does not require merging their configuration or credentials.

Does the OS run Codex after I finish a turn?

No. channel_wait is an explicit pending call, and a prompt-time unread hint needs a new turn. This version does not add an idle-session Codex wake mechanism.

Why are a model, duration or usage value unknown?

The OS only displays evidence it can attribute. Missing native metadata stays unknown, tool duration needs trustworthy timing, and full Codex token/cost attribution is unfinished. Historical calls without reliable IDs are not marked complete by guesswork.

Why can new files exist while the Dashboard still shows old behavior?

The running API, built Dashboard, installed adapter files and host hook trust are separate layers. Update compatible pieces together and verify an actual event through the chain; reloading MCP alone does not replace them all.

Will a terminal session tell me about OS updates?

With the updated API and SessionStart hooks installed, Codex and Claude Code can emit a short update command for the user and separate release details for the assistant when a newer public stable Release is available. Dashboard language choices are saved by the API and take precedence. In follow mode, Claude Code uses its language setting, while Codex uses the system language; unsupported languages fall back to English. The same session does not repeat the notice on resume or compact. Release checks are cached for six hours, and network failures do not block startup. Notices do not run Git, install packages or restart services. Update commands depend on the installation method; release links and the complete procedure go to the assistant context. An older installation must first receive these hooks; reloading MCP alone does not install them. Claude Code CLI visibility has been checked separately; Codex CLI and desktop rendering still require native UI acceptance.

---

MCP Tools

---

Agent Template Library

25 professional role templates are shipped in plugin/agents/, with a shared catalog and recommendation tools. Claude Code can install them as native agent definitions, including global copies in the Claude Code config folder’s agents/. Codex can use the role guidance while keeping native dispatch, naming and permissions; CC template frontmatter is not a Codex installation format.

Engineering (13 templates)

Testing (4 templates)

Research & Support (3 templates)

Management (2 templates)

Debate Roles (2 templates)

Utility (1 template)

---

Roadmap

Shipped and Historical Milestones

• [x] Core Task Wall + Watchdog + Review (the loop state machine was retired in v1.10.x; scoring and the wall live on in loop/task_wall_engine.py)
• [x] Failure analysis tools, frozen in 2026-09: still callable, no further development
• [x] Decision Cockpit (Event stream + Timeline + Intent inspection)
• [x] Event-driven Task Wall 2.0 (Real-time push + Intelligent matching)
• [x] Living Team Memory (Knowledge query + Experience sharing)
• [x] What-If Analyzer (Multi-option comparison)
• [x] 8 structured meeting templates with keyword auto-select
• [x] 25 professional Agent templates (23 base + 2 debate roles) with recommendation engine
• [x] 4-layer defense rule system (37 rules) + behavioral enforcement
• [x] Dashboard Command Center (React 19) — 24 pages including the /workflows swimlane, Workflow detail, the Ecosystem suite, /usage token attribution, /usage/accounts plan capacity, and Settings with model governance
• [x] 118 MCP tools across 18 modules
• [x] CC Workflow observability layer (auto-tracking + /workflows dashboard + workflow_list / workflow_get / workflow_reconcile)
• [x] Knowledge layer — zero-LLM reference graph + unified 3-arm RRF search (v1.8.0)
• [x] Claude Code model governance - transcript-based discovery and startup defaults (v1.8.1)
• [x] Machine-checked red-line invariants + one-command preflight (scripts/preflight.sh)
• [x] AWARE loop memory system
• [x] find_skill 3-layer progressive discovery
• [x] task_update API for programmatic task management
• [x] Workflow pipeline orchestration (7 templates + auto phase progression) — fully removed in v1.10.x, superseded by CC Workflow observability (pipeline_stage_history stays readable)
• [x] Automated unit and frontend regression suites maintained in CI
• [x] Prompt Registry (version tracking retired in v1.10.3 — nothing ever called /track, so every version column rendered “-”; effectiveness metrics live on, sourced from real agent activity)
• [x] BM25 as the main memory-retrieval chain (pure-Python Okapi BM25, Chinese bigram, recency-window recall + rerank)
• [x] Event log enhancement (entity_id / entity_type / state_snapshot fields)
• [x] CC Plugin Marketplace submission
• [x] File lock / workspace isolation (acquire/release/check/list + TTL=300s) — retired in v1.10.3; the lock file was empty in every real run, and hook-side edit-conflict warnings replaced it
• [x] Channel communication system (team:/project:/global + @mention)
• [x] Execution pattern memory (success/failure recording + BM25 retrieval) — retired in v1.10.3; the store never held a row, so the injected section was permanently blank
• [x] Guardrails L1 (7 dangerous patterns + PII warnings)
• [x] Alembic database migration system
• [x] Debate mode (4-round structured debate + code review)
• [x] Agent trust scoring system (auto-adjust on task success/failure) — scoring chain retired in v1.10.3 (no caller ever existed); the trust_score column stays and auto_assign still weights it
• [x] Tool tier draft (informational CORE/ADVANCED grouping — groundwork for context budgeting)
• [x] Agent Watchdog patrol (BUSY-timeout / stuck-task detection; the file-based heartbeat was retired in v1.10.x — CC subagents are one-shot and never polled)
• [x] SRE error budget model (GREEN/YELLOW/ORANGE/RED 4-level response) — retired in v1.10.3; its data directory sat empty for its entire lifetime
• [x] Completion verification protocol (anti-hallucination completion check)
• [x] Ecosystem integration recipes (GitHub/Slack/Linear/Full-stack presets, served by find_skill)
• [x] Session bootstrap rule compression (23 → 5 core rules, 60% context reduction)
• [x] Atomic API startup lock (multi-session port conflict prevention)
• [x] Auto port discovery (API finds available port, writes to api_port.txt)
• [x] MCP HTTP Streamable endpoint (/mcp/ on FastAPI)
• [x] PyPI release - stopped at 1.3.4 (2026-04) and deprecated; the wheel ships without plugin/ and config resources, so install via plugin or source instead
• [x] INSTALL.md CC-assisted installation guide

In Progress / Planned

• [ ] Final installed-hook acceptance of the Codex/Dashboard observation chain

• [ ] Full Codex token and cost attribution

• [ ] Multi-tenant isolation

• [ ] Production validation and performance optimization

• [x] Claude Code Plugin Marketplace listing

• [ ] Full integration test suite

• [ ] Documentation site (Docusaurus)

• [ ] Video tutorial series

---

Project Structure

ai-team-os/
├── src/aiteam/
│   ├── api/           - FastAPI REST endpoints (242 routes)
│   ├── mcp/
│   │   ├── server.py  — MCP server entry point
│   │   └── tools/     - 18 tool modules (118 MCP tools)
│   │       ├── agent.py, analytics.py, briefing.py, channels.py,
│   │       ├── ecosystem.py, external_exec.py, infra.py, links.py, meeting.py,
│   │       ├── memory.py, notices.py, project.py, reports.py, task.py,
│   │       ├── task_analysis.py, team.py, watchdog.py, workflows.py
│   │       └── __init__.py  — Toolset registration entry
│   ├── loop/          - Task wall engine + watchdog + frozen failure analysis
│   ├── meeting/       — Meeting system
│   ├── memory/        — Team memory
│   ├── orchestrator/  — Team orchestrator
│   ├── storage/       — Storage layer (SQLite, WAL journaling)
│   ├── templates/     — Agent template base classes
│   ├── hooks/         — CC Hook scripts (16 lifecycle events)
│   └── types.py       — Shared type definitions
├── plugin/
│   ├── agents/        - 25 Claude Code Agent templates (.md)
│   ├── harness/codex/ - Independent Codex adapter, hook manifest and helpers
│   └── .claude-plugin/ - Claude Code plugin manifest
├── dashboard/         — React 19 frontend (24 pages)
├── scripts/           — preflight + machine-checked invariants (incl. README number check)
├── docs/              — Design documents + ecosystem recipes
├── tests/             - Unit, integration and end-to-end checks
├── install.py         - Claude Code source installer
└── pyproject.toml

---

Contributing

Contributions are welcome! We especially appreciate:

• New Agent templates: If you have prompt designs for specialized roles, PRs are welcome
• Meeting template extensions: New structured discussion patterns
• Bug fixes: Open an Issue or submit a PR directly
• Documentation improvements: Found a discrepancy between docs and code? Please correct it

# Set up source dependencies without changing either host's configuration
git clone https://github.com/CronusL-1141/AI-company.git
cd AI-company
python3 -m pip install -e ".[dev]"
npm --prefix dashboard ci

# Local preflight: lint, frontend regression tests, unit tests and invariants
bash scripts/preflight.sh

# CI also checks TypeScript; preflight does not run this command
(cd dashboard && npx --no-install tsc -b --noEmit)

Before submitting a PR, run the full preflight and the separate TypeScript check above. Preflight runs ruff, ESLint, frontend regression tests, the unit test suite and the invariants in scripts/check_invariants.sh; missing lint/frontend dependencies can cause skips, so a successful exit alone does not prove every check ran. Review the output, and do not use --fast for release acceptance.

Release preparation also needs targeted integration/end-to-end checks, Dashboard builds and a complete comparison of dashboard/dist with plugin/dashboard-dist. I3 compares JavaScript filenames only, not every asset’s bytes. Keep both READMEs and both CHANGELOGs in sync, inspect distribution and privacy boundaries, and verify the installed hooks and running API/UI separately. Static manifest/trust checks do not prove the host loaded or executed a hook.

---

License

MIT License — see LICENSE

---