AI-company

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-<wf_id>) 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

Dimension	AI Team OS	CrewAI	AutoGen	LangGraph	Devin
Category	Shared OS for native coding agents	Standalone Framework	Standalone Framework	Workflow Engine	Standalone AI Engineer
Integration	MCP + independent Claude Code/Codex adapters	Independent Python	Independent Python	Independent Python	SaaS Product
Memory System	Shared direction memory + task memos + BM25 retrieval	Short-term context	Short-term context	Checkpoint state	In-session
Tool-Loading Governance	alwaysLoad rotation + group switch + read-only profile + template least-privilege	None	None	None	None
Autonomous Operation	Durable task coordination; execution depends on the host	Task-by-task	Task-by-task	Workflow-driven	Limited
Meeting System	8 structured templates with auto-select	None	Limited	None	None
Decision Transparency	Decision Cockpit + Timeline	None	Limited	Limited	Black box
Workflow Observability	Swimlane timeline + per-agent telemetry + offline reconcile over CC Workflow	None	None	Graph state only	None
State Source	Host-native metadata + persisted observations and journals	Agent self-report	Agent self-report	In-process state	Black box
Rule System	4-layer defense (37 rules) + behavioral enforcement	Limited	Limited	None	Limited
Agent Templates	25 Claude Code templates + shared role recommendations	Built-in roles	Built-in roles	None	None
Dashboard	React 19 visualization	Commercial tier	None	None	Yes
Open Source	MIT	Apache 2.0	MIT	MIT	No
Native Coding Hosts	Claude Code and Codex, with distinct integration paths	No	No	No	No
Extra Cost	Local OS; host and integration usage costs still apply	API costs	API costs	API costs	$500+/mo

---

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.

…