AIPass
A persistent agent workspace: AI agents that remember across sessions, hand each other work, and never start from zero.
- Source repo
- AIOSAI/AIPass
- Stars
- ★ 312
- Last updated
- 2d ago
- License
- MIT
- Primary language
- Python
- FA score
- 50/100 · Major gaps
At a glance
- How it runs
- Works with
- Portable with changesCodex · Claude Code
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A Claude Code user who wants agents to remember project decisions and last session's work instead of re-explaining context every time.
- Not a fit if
- Users on native Windows who cannot install WSL2
- Users without a paid Claude plan that includes Claude Code who do not want to subscribe
- Teams needing a cloud-hosted, multi-tenant deployment rather than a local single-machine setup
- Source review
- 50/100 · Major gaps
What does this agent do, and when should you use it?
AIPass (AIOSAI/AIPass) is a locally run persistent agent workspace driven by two commands, aipass and drone, installed via pipx. It gives 18 reference agents each a home directory, a passport (.trinity/passport.json), a mailbox (.ai_mail.local/), and durable memory on the same filesystem, with agents dispatching and waking each other through the drone @agent bus. Execution runs Claude Code as an official subprocess on your existing Claude subscription, with optional Codex and OpenCode as second CLIs per task; all memory and mail are local files, and overflowing memory rolls into a locally searchable vector store. Hooks and gates constrain writes — only a project's manager writes git — and drone @seedgo audit enforces a written standard. It targets individual Claude Code, Codex, and OpenCode users who want agents to remember last week's work and hand tasks to each other in repos they already have.
After pipx install aipass, running aipass install clones the repo to ~/AIPass, builds its environment, sets up the 18 agents, and runs a health check. Daily workflow: aipass new my-project --template python creates a new project with a resident manager agent, or aipass init run does guided setup inside an existing directory. You talk to the manager in plain language (e.g. "Add a CSV export to the report command"); it writes a context-carrying work plan with drone @flow create . "task" and dispatches via drone @ai_mail dispatch @agent "Subject" "Body". The owning agent wakes in its own folder with its prompt, .trinity/ memory, refreshed DASHBOARD.local.json, and the task mail; its reply lands in the manager's inbox. drone @spawn create src/my_project/analyst --role "Analyst" --purpose "Reports" adds agents, drone @seedgo audit aipass runs the same standards checks used in CI, drone @daemon install-timer starts the scheduler, and drone @memory roots add <path> declares your own repos as dispatch targets. Memory persists as plain JSON files, rolling into a local vector store with semantic search when full.
- A Claude Code user who wants agents to remember project decisions and last session's work instead of re-explaining context every time.
- Anyone wanting multiple specialized agents (analyst, manager) in one repo that dispatch tasks and hand work to each other.
- Owners of existing codebases who want to onboard an agent team via
aipass init runwithout rebuilding the project. - Users who need agent write permissions constrained: edit gates decide which agent may edit which files, git goes through one door, raw deletes are refused.
- Maintainers automating recurring work — logs, backups, scheduled jobs — by giving each agent its own schedule via
drone @daemon install-timer. - People who want to view and manage their local agent fleet from a phone via the companion BAUD app served from their own machine.
How do you install or deploy this agent?
Prerequisites: Python 3.10+, a Claude plan that includes Claude Code (Pro/Max/Team/Enterprise), Linux or macOS (Windows via WSL2). Install:
pipx install aipass
aipass installThe first line puts aipass and drone on your PATH; the second clones the repo to ~/AIPass (--path to choose), builds the environment, sets up the 18 agents, runs a health check, and ends with the concierge agent greeting you (--no-baud skips the phone-face server). No API keys required: core functionality runs on your existing Claude subscription; keys are only needed for optional integrations like OpenRouter. To work on AIPass itself, install from a clone:
git clone https://github.com/AIOSAI/AIPass.git && cd AIPass && ./aipass installHow do you use this agent?
- Create or adopt a project:
aipass new my-project --template python # New project: scaffold, resident manager agent, first commit
aipass init run # Existing directory: run inside it, guided setup- Run
claudein the manager's directory and state what you want in plain words (e.g. "Add a CSV export to the report command"); it writes a plan and dispatches to the owning agent. The manual equivalent:
drone @flow create . "Add CSV export" # A work plan that carries the context
drone @ai_mail dispatch @agent "Subject" "Body" # Send the task and wake the agent- Grow and check:
drone @spawn create src/my_project/analyst --role "Analyst" --purpose "Reports"
drone @seedgo audit aipass
aipass doctorFor the fleet to dispatch work to a repo you already have, declare it once with drone @memory roots add <path>. You can also talk directly to devpulse (the admin seat) or aipass (concierge/machine upkeep).
What are this agent's strengths and limitations?
- Persistent memory is a concrete design, not a slogan: each agent has a
.trinity/memory directory and passport file, with overflow rolling into a locally semantically searchable vector store. - Collaboration has real mechanics:
ai_mailmailboxes and dispatch,flowplans that carry context, and atriggerevent bus that wakes the agent owning an error. - Clear permission boundaries: edit gates, git through one door (only a project's manager writes), raw deletes refused, provider settings changed only with the owner's consent.
- Everything local: memory and mail are files on your machine, no cloud accounts; the 18 core agents are CI-audited against one written standard.
- Requires a paid Claude plan that includes Claude Code; Codex and OpenCode work as second CLIs, but Claude Code is a mandatory prerequisite.
- Native Windows is unsupported — WSL2 only; macOS passes CI but is not the daily-use platform.
- Install changes files outside the repo: user-level Claude Code settings (deny rules that apply to every project on the machine), shell rc, possibly
pull.rebase, keyring entries, and a systemd service — full removal requires cleaning each item. - A single-maintainer project built by one human and its own agents, with few outside contributions; long-term velocity depends on that project alone.
How does this agent compare with similar options?
The README contrasts AIPass with common multi-agent setups that give each agent its own sandbox or worktree: there, one agent can't see what another just built, and agents vanish when a task ends. AIPass instead makes agents "citizens" sharing one filesystem, with persistent identity, memory, and mailboxes.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| AIPass This agent | 50 · Major gaps | CLIFree + model costs | ★ 312 | 2d ago | Python | Codex · Claude Code |
| Compartment | 76 · Good | CLIFree | ★ 580 | 15d ago | Python | Codex · Claude Code |
| zer0dex Local Memory | 84 · Good | CLIFree | ★ 64 | 16d ago | Python | — |
| Mnemo Cortex | 75 · Good | Self-hosted serviceFree | ★ 159 | 1d ago | Python | Codex · Claude Code · Claude.ai |
How does FollowAgents rate this agent?
Why each dimension lost points
README enumerates every external file install touches (~/.claude/settings.json, shell rc, keyring, systemd units) and describes deny rules, dated backups with receipts.jsonl, and doctor --fix showing a diff before writing, which supports least_privilege/user_confirmation/rollback at 2. However, install by default writes user-level Claude Code settings, sets global git pull.rebase, starts a local host API service, and may sudo to place /usr/local/bin symlinks — broad default external effects, so external_effects is 1. Data-flow transparency: README claims 'everything local' but context is sent to Claude/Codex/OpenCode providers and BAUD is served over a tailnet, so only partial, 2. Sensitive data: keyring and ~/.secrets isolation plus deny rules exist, but SECURITY.md and README disagree on secrets paths (~/.secrets/aipass/ vs keyring migration) and no code evidence is shown, 2. Dependency security: CI uses hash-pinned requirements and pinned action SHAs, but pyproject dependencies are lower-bound only with no lockfile, 2. Source attribution: README cites internal docs and badges but no verifiable third-party sources or data provenance, and publisher is unverified, 1.
CI is comprehensive (lint, multi-version test, standards, coverage, e2e-wheel) and test conftest shows isolation of real mail, trigger bus, and central files, indicating some self-consistency; but README claims 'Stable' while SECURITY.md supports only 2.1.x and pyproject version is 2.8.32 — inconsistent versioning, so self_consistency is 1. Dependency availability: Python range and optional extras are declared and CI covers 3.10–3.13, 2. Failure messages: README mentions aipass doctor and error hints but no concrete error-message design or code evidence, 1.
README states target users (Claude Code/Codex/OpenCode), scenarios (multi-agent collaboration, persistent memory), and platform limits (Linux/macOS, Windows via WSL2 only), audience_and_scenarios 2. Capability boundaries: gates, owner seat, and no-index are described, but the boundary between the 18 built-in agents and user-created agents and the permission model are asserted only in README, 1. Trigger precision: drone @agent commands and hooks are described but concrete trigger conditions and conflict handling are not evidenced, 1. Environment fit: Python 3.10+, optional Node/npm, sudo fallback, macOS without sandbox are documented, 2.
Information architecture is clear with complete README sections and links to per-agent docs, 2. Install notes are exceptionally detailed, listing every external change and cleanup path, 3. Naming stability: version mismatch (SECURITY.md 2.1.x vs pyproject 2.8.32) and multiple '2026' dates that look suspicious relative to the timeline, 1. Examples and FAQ: command examples and a demo script link exist but no standalone FAQ, 2. Known limitations: platform and Windows notes are present, 2. License: MIT with a complete LICENSE file, 3. Versioning/changelog: only a PyPI badge, no CHANGELOG file, 1. Maintenance responsibility: author is 'AIPass' with unverified publisher and no explicit maintainer commitment, 1.
Output usability: README gives commands and expected outcomes but no actual output samples or reproducible end-to-end example, 1. Marginal value: persistent memory and multi-agent collaboration are common selling points without quantified comparison or unique evidence, 1. Cost-benefit: install modifies many system files, starts services, and may use sudo, while benefits are described generically, 1.
claim_traceability: README makes many assertions (e.g., 'audited at 100%', 'stable') without traceable test reports or third-party verification, 1. cross_source_corroboration: only README, CI config, and test files are available; no independent source corroboration, 1. fact_inference_separation: README mixes design intent with facts (e.g., 'everything local' alongside 'CLI sends to its provider') without clear separation, 1.
- Install by default modifies user-level Claude Code settings, global git config, shell rc, keyring, and systemd units, and may use sudo; evaluate in an isolated environment or container first.
- README claims 'everything local' but context is sent to Claude/Codex/OpenCode providers and BAUD is served over a tailnet; assess data boundaries yourself.
- SECURITY.md supports only 2.1.x while pyproject version is 2.8.32 — inconsistent versioning may affect security-update coverage judgment.
- Publisher identity is unverified; maintenance responsibility and update path are unclear.
- Multiple '2026' dates in README do not match the current timeline; treat freshness claims with caution.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
[2026-11-02] — v2.8.34: seedgo is sentry, Beo is Seed, the settings gate asks on a write Changed - sentry (was seedgo): the standards citizen is renamed, whole, because the old name could not be said to a speech recognizer. Package aipass.sentry, address @sentry, directory src/aipass/sentry, every branch's .sentry/ bypass dir and .sentryignore, sentry_json/, the CI audit script .github/scripts/sentry_audit.py and its job sentry-audit, the # sentry: no-test-needed(...) markers and the three checkers that parse them, the SENTRY: label on hook auto-fixes, the passp …View on GitHub ↗ -
Release notes excerpt
[2026-11-01] — v2.8.33: an empty .git is not a repo, dispatch stop from the deck, hook sounds off by default, the Stop gate for the watchdog wire Added - devpulse: a Stop hook (watchdog_wire_gate) refuses to end a devpulse turn while a dispatch it sent is out and no watchdog wire is armed for the session; the refusal is the arm command. …View on GitHub ↗ -
Release notes excerpt
[2026-11-01] — v2.8.32: compass recall for managers only, a hook mute that survives reboots, seedgo finds the tests that pin a file, spawn owner moves, api run with a scoped key Added - seedgo: drone @seedgo tests pinning <path ...> prints every test file that names a path (as one string or as trailing Path parts), one per line, ready for pytest before a commit; .py inputs are skipped. - spawn: drone @spawn owner moves a project's owner seat to another citizen; a mint never invents a registry. …View on GitHub ↗
FAQ
Do I need anything besides my subscription — API keys or extra costs?
Does my code or memory leave my machine?
Will installation change other things on my machine?
git pull.rebase, your system keyring, and (when enabled) a systemd user service. The README lists every touched file; aipass doctor --fix diagnoses and repairs, and every settings write leaves a dated backup and receipt.How do I troubleshoot when something breaks?
aipass doctor names the problem and aipass doctor --fix cures what it can. Each agent keeps its own logs, the prax agent handles monitoring and runaway-log detection, and the backup system provides restorable local snapshots.Can I adopt an existing project, or only create new ones?
aipass new creates a project with a resident manager agent; aipass init run does guided setup inside an existing directory, with its aipass_framework template adding a first agent. Afterwards declare it once with drone @memory roots add <path> so the fleet can dispatch work to it.