ai-memory/docs/support-matrix.md

Support Matrix

The complete platform and agent matrix, with integration notes. Moved verbatim from the README front page, which keeps a compact view.

MCP-only (documented) means the row has a hand-written MCP recipe that follows the client's own documentation at the version named, and that nobody has yet run the client end to end against ai-memory. These rows are not in the README's compact view, which lists first-party integrations only.

Area	Status	Notes
Linux	Supported	Primary Docker/server target and CI platform. Published Docker images support linux/amd64 and linux/arm64. Native Arch/AUR packages include system and user systemd units.
NixOS	Supported	Flake package (nix build / nix run) plus nixosModules.default (services.ai-memory.enable) with a hardened systemd unit, typed/freeform settings → generated config.toml, and agenix / sops-nix / environmentFile secrets. Web UI opt-in (enableWeb = false by default). settings (including llm_headers) lands in a world-readable Nix store path — keep secrets in age/sops/env. CI: Linux package + module eval on path-filtered PRs; Darwin package and privileged container smoke on schedule / dispatch / nix or full-ci label. See README NixOS section and docs/install.md.
macOS	Supported	Workspace tests run in CI; tagged releases publish native ai-memory-macos-aarch64.tar.gz and ai-memory-macos-x86_64.tar.gz binaries, which include a per-user launchd agent. The native binary is the recommended path on Apple Silicon. A source-built menu bar app (companions/ai-memory-macos) bundles that binary, starts the LaunchAgent, and opens /web and ai-memory status — README quick-start and docs/macos.md Scenario D.
Windows via WSL2	Supported	Use the Linux install path inside WSL2 when the agent runs there.
Native Windows	Experimental	Tagged releases publish ai-memory-windows-x86_64.zip with ai-memory.exe, also installable from the akitaonrails Scoop bucket from 3.4.0 (scoop install ai-memory; updated with scoop update ai-memory, which ai-memory upgrade refuses to replace); Docker Desktop wrapper and source builds are also available. Native ai-memory upgrade is supported for writable x86_64 zip installs (checksum-verified zip + rename-aside self-replace + sibling hooks/ refresh). Local supported profiles default to host-native hook commands; Claude Code may use its Windows exec form, while other agents use native single command strings matching their hook schema. PowerShell/Git Bash scripts are compatibility fallbacks. See docs/windows.md.
Claude Code	Supported	MCP config + lifecycle hooks; native commands enforce capture exclusions. Ten events are wired, PostToolUseFailure included: Claude Code fires it instead of PostToolUse when a tool fails, and the observation records outcome: error with the bounded error text, so failures reach search, consolidation and the handoff's Last failed tool call line. The same hooks, MCP tools and skills also ship as a marketplace plugin (ai-memory 3.0 or later; see install.md). install-mcp --session-aware optionally enables per-session auto-scope isolation through a local stdio bridge; on a token-file install (every fresh init) the session-aware bridge entry is automatic. Optionally captures the assistant's final turn on Stop when installed with --capture-assistant and the server enables capture_assistant (double opt-in, off by default). A prompt starting with reload context receives a compaction recap through UserPromptSubmit additionalContext (see usage.md). After a compaction, SessionStart with source compact injects a post-compaction anchor (the session's first and latest prompts) instead of the startup packet (see usage.md).
Codex	Supported	MCP config + lifecycle hooks; native commands enforce capture exclusions. The same hooks, MCP tools and skills also ship as a marketplace plugin (ai-memory 3.0 or later; see install.md). SessionEnd is wired since Codex CLI 0.145.0 (openai/codex#33895), so finished sessions get an automatic end-of-session summary/handoff; on older Codex the event is inert and ai-memory finalize-session --agent codex is the fallback. Managed runs (ai-memory run codex) recover when Codex's shared daemon reports a stale run id, provided exactly one live run matches the authorized project, checkout, and operator; ambiguous matches fail closed. --no-daemon remains available as an isolation and diagnostic option (see docs/managed-workstreams.md). Optionally captures the assistant's final turn on Stop when installed with --capture-assistant and the server enables capture_assistant (double opt-in, off by default) — Codex's Stop payload carries last_assistant_message, same as Claude Code. A prompt starting with reload context receives a compaction recap as UserPromptSubmit developer context, capped at 6,000 chars (see usage.md). After a compaction, SessionStart with source compact injects a post-compaction anchor as developer context instead of the startup packet (see usage.md).
Command Code	Supported	MCP config (~/.commandcode/mcp.json) + its four stable lifecycle-hook events (~/.commandcode/settings.json); native commands enforce capture exclusions and SessionStart injects handoffs. Stop is only a turn boundary, so use ai-memory finalize-session --agent command-code after the final turn; an interactive session launched with ai-memory run command-code is finalized automatically when it exits if the run can tie the session to itself (see docs/managed-workstreams.md). ai-memory run command-code adds exact v3 native-session resume and visible-event import; experimental unsandboxed Mods remain excluded.
Devin CLI	Supported	MCP config + lifecycle hooks. Hooks use Devin's PostCompaction event, inject handoffs via hookSpecificOutput.additionalContext, and omit subagent events because Devin does not expose them.
OpenCode (V1/V2 auto-detected)	Supported	Host-side generic opencode commands probe the exact executable and select the V1 direct MCP/function-plugin/transcript contracts or V2 nested mcp.servers/{ id, setup } plugin/session_v2 contracts. The result is reused through managed discovery, launch, auto-wire, and transcript import; an automatic run skips OpenCode when probing fails but continues other harness discovery. Container-oriented setup-agent requires `--opencode-dialect v1
Cursor	Supported	MCP config + lifecycle hooks. postToolUseFailure is wired: Cursor fires it instead of postToolUse when a tool fails, times out or is denied, and a failed or timed-out call records outcome: error with Cursor's error_message, so failures reach search, consolidation and the handoff's Last failed tool call line. No post-compaction hook can add context, so re-grounding after a compaction relies on the installed instructions (see usage.md).
Gemini CLI	Supported	MCP config + lifecycle hooks. No post-compaction hook can add context, so re-grounding after a compaction relies on the installed instructions (see usage.md).
Oh My Pi / OMP	Supported	Use --client omp / --agent omp (or oh-my-pi) for native .omp MCP config + TypeScript extension; generated extension enforces capture exclusions.
Pi	Supported	Generated ~/.pi/agent/extensions/ai-memory-pi.ts extension provides lifecycle capture and an HTTP MCP bridge; generated extension enforces capture exclusions.
Crush	Managed-only	ai-memory run crush resumes its project-local session database and supplies portable context through a temporary supported global-context file; no lifecycle-hook installer is provided.
Managed workstreams	Opt-in	ai-memory run provides transparent cross-harness continuity for Claude Code, Codex, OpenCode, Pi, Crush, Kimi Code, Command Code, both incompatible Kiro CLI engines, OMP, Grok Build CLI, Antigravity CLI, and GitHub Copilot CLI. Direct launches remain unchanged. See docs/managed-workstreams.md.
--yolo safety + ai-jail	Linux/macOS; Windows partial	ai-memory run --yolo warns before it disarms an agent's permission prompts and, on Linux/macOS, offers to re-exec the session inside ai-jail when it is usable — installed and with its sandbox backend present (bwrap / sandbox-exec); otherwise it asks nothing and proceeds (--network, forwarding only already-set credential/config env vars). Accepting the offer shows a checklist of ai-jail toggles pre-marked with smart defaults (credentials present on the host, SSH for an SSH origin, worktree metadata in a linked worktree; Docker socket, GPU, display, Pictures, Tailscale unchecked). --jail re-runs inside ai-jail without asking (also without --yolo and non-interactively; it errors when ai-jail is not usable), --jail=github,aws,no-mise is exact (every unnamed checklist row is forced off with --no-X; all/none too; the checklist likewise passes unchecked rows as --no-X, while bare --jail leaves unmarked rows to your ai-jail config), and --no-jail skips the offer. The checklist remembers each checkout's answers outside the repository (Enter keeps them, reset restores the recommendation), f or --jail-map DIR / --jail-rw-map DIR mount extra folders such as a sibling project (ai-jail 2.15; home, /, credential folders and ai-memory's data dir are refused), and the jailed run prints the ai-memory run line that repeats the choices when it quits. Only toggles the installed ai-jail supports are offered; the credential mounts (github, aws, kube, gcloud, docker-config) need ai-jail 2.5.0. A project .ai-jail in the launch directory replaces the checklist and the bare---jail defaults (ai-jail loads it as-is; --jail=… still overrides), and every re-exec passes --no-save-config so ai-jail never writes the run's flags into it. Both prompts are skipped on a non-interactive stdin/stderr and when already detected inside ai-jail. Windows gets the warning but never the ai-jail offer (ai-jail is Linux/macOS-only). Opt-in --true-yolo implies --yolo and, for Claude only, additionally forces bypassPermissions over any settings defaultMode (interchangeable with --yolo for other harnesses); claude_true_yolo applies the same Claude extra to --yolo launches. Claude's own explicit ask rules and command-safety checks still prompt in every mode. See docs/design-yolo-safety-ai-jail.md.
Claude Desktop (Chat)	MCP-only	Uses mcp-remote; the ordinary Chat surface does not run lifecycle hooks. macOS, Windows, and Linux (Anthropic's Debian/Ubuntu beta, ~/.config/Claude/claude_desktop_config.json). Cowork capture is not claimed; see the explicit boundary in mcp-install.md.
Claude Desktop (Code tab)	Supported	Local Code-tab sessions run Claude Code with the user's ~/.claude/settings.json, so the Claude Code hooks capture them as claude-code; a session without a project folder lands in its own scratch-directory project.
OpenClaw	Supported	MCP config + native plugin lifecycle hooks; generated plugin enforces capture exclusions.
Antigravity CLI	Supported	MCP config (serverUrl) + lifecycle hooks (agy alias; per Antigravity's docs the desktop App and the IDE read the same global ~/.gemini/config/hooks.json). SessionStart delivers the handoff as an injectSteps system message that stays in the conversation. PreInvocation with invocationNum = 0 starts each user turn: the native hook records the turn's prompt from the conversation's own transcript, since no Antigravity hook payload carries it, and on builds without SessionStart the first turn's PreInvocation stands in for it, once per conversation. A Stop that finished the turn with nothing left running (terminationReason NO_TOOL_CALL or model_stop, fullyIdle: true) writes a turn checkpoint: the summary page and the conversation's one handoff are refreshed and the conversation stays open; a new session in the project receives that handoff once the conversation has been quiet for 10 minutes. There is still no conversation-end event: ai-memory finalize-session --agent antigravity-cli closes a conversation at once, hands its baton over and queues opt-in SessionEnd consolidation; an interactive session launched with ai-memory run antigravity is finalized automatically when it exits if the run can tie the session to itself (see docs/managed-workstreams.md). ai-memory run antigravity (aliases antigravity-cli, agy) adds managed workstream resume via --conversation; its conversation store is not decoded, so the ledger takes user prompts from agy's history.jsonl (only this conversation's lines typed in this checkout), falling back to that conversation's bounded brain transcript for print mode, and takes assistant and tool steps from hook capture. Tool outputs (run_command, view_file, list_dir, etc.) are resolved directly from .system_generated/steps/<stepIdx>/output.txt during post-tool-use while mutation tools preserve code from arguments (#966). Skills: Antigravity reads workspace skills from .agents/skills and global skills from ~/.gemini/config/skills (App and IDE) and ~/.gemini/antigravity-cli/skills (CLI), not from ~/.agents/skills (Antigravity docs); install-skills --scope global --agent antigravity and setup write the managed skills into both global roots, and uninstall --only skills sweeps them.
Grok Build CLI	Supported	MCP config (install-mcp --client grok → $GROK_HOME/config.toml, default ~/.grok/config.toml) + lifecycle hooks (install-hooks --agent grok → $GROK_HOME/hooks/ai-memory.json, default ~/.grok/hooks/ai-memory.json, Grok-specific hook bundle). Capture works. SessionStart and UserPromptSubmit do not accept the handoff (Grok discards that stdout). install-hooks --agent grok --apply and install-skills --scope global --agent grok also write $GROK_HOME/rules/ai-memory-handoff.md so the first turn calls memory_handoff_list through use_tool with the qualified catalog key ai-memory__memory_handoff_list (Grok reaches MCP tools only through that meta-tool) ahead of any file read, correcting workspace/project from ./.ai-memory.toml only when that list is empty or a scope error; the first PostToolUse then prints hookSpecificOutput.additionalContext with the pending handoff and an opted-in [briefing]. If that rule is absent and no tool runs, recover via MCP memory_handoff_list then memory_handoff_accept with that handoff_id. ai-memory run grok adds managed workstream resume with the context packet delivered natively through --rules. Skills root: .grok/skills / $GROK_HOME/skills (default ~/.grok/skills). A prompt starting with reload context receives a compaction recap on the next PostToolUse additionalContext, not with the prompt (see usage.md). No post-compaction hook can add context, so re-grounding after a compaction relies on the installed instructions (see usage.md).
Swival CLI	MCP-only	install-mcp --client swival --apply merges a native HTTP entry into the project-root .swival/mcp.json, preserving sibling servers. Lifecycle and managed-workstream support are not claimed because Swival's callback contract does not expose a stable session identifier.
Zero	Supported	install-mcp --client zero (native HTTP + bearer in ~/.config/zero/config.json when the token is passed explicitly; a token-file install gets a stdio ai-memory mcp-bridge --no-session-id entry instead) + lifecycle hooks via install-hooks --agent zero --apply (exec-form native commands in ~/.config/zero/hooks.json, JSON payload on stdin, no shell). Capture works incl. specialist (subagent) events; no handoff injection — Zero discards sessionStart stdout, so recover handoffs via MCP memory_handoff_list then memory_handoff_accept with that handoff_id. Zero runs hooks in its sandbox, which by default denies network (loopback too) and writes outside the workspace, so events stay in the hook spool: allow sandbox.network and add the ai-memory data dir to sandbox.additionalWriteRoots in the global ~/.config/zero/config.json (network allow covers every Zero shell command; sessionEnd then delivers in-process within a fixed 10-second budget, since the sandbox kills detached drainers), or run ai-memory hook-drain from a normal shell (see mcp-install.md).
ZCode	Supported	install-mcp --client zcode --apply merges a native HTTP entry (strict schema: type/url/headers only) into the mcp.servers map of ~/.zcode/cli/config.json, preserving sibling servers. It is refused when the bearer lives in a token file (every fresh init), because ZCode keeps only a literal header; add the entry by hand there. ZCode (z.ai, zcode, alias zai). Lifecycle-hook capture via install-hooks --agent zcode --apply: exec-form native commands (type: "process", no shell) merged into the root hooks block of ~/.zcode/cli/config.json around any third-party hooks; native commands enforce capture exclusions. Six documented triggers (SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, PostToolUseFailure, Stop); PostToolUseFailure fires instead of PostToolUse when a tool throws and lands on the same capture channel with the error preserved. PermissionRequest is deliberately not installed — its hook chain races the interactive permission client, so passive capture of that event is unreliable by design. No true session-end — Stop is a per-turn boundary, so run ai-memory finalize-session --agent zcode after the final turn. Unlike Pool and Zero, SessionStart stdout injection works (hookSpecificOutput.additionalContext, verified live against the embedded engine v0.16.5), so the prior session's handoff is delivered automatically. No managed workstream is claimed yet.
Kimi Code	Supported	MCP config (url entry in ~/.kimi-code/mcp.json) + lifecycle hooks ([[hooks]] in ~/.kimi-code/config.toml, 10 events including subagent start/stop and PostToolUseFailure for tool-failure capture); both paths honor $KIMI_CODE_HOME. Handoffs inject via UserPromptSubmit stdout (Kimi Code discards SessionStart hook stdout); ai-memory run kimi adds managed workstream resume. No post-compaction hook can add context, so re-grounding after a compaction relies on the installed instructions (see usage.md).
Kiro CLI	Supported	MCP config uses install-mcp --client kiro-cli (alias kiro) and Kiro's Bedrock-compatible schema flavor. install-hooks --agent kiro-cli merges v2 hooks into existing agent configs; the explicit --agent kiro-cli-v3 target writes the incompatible standalone v3 registration. Both preserve unrelated entries, honor $KIRO_HOME, enforce capture exclusions, and inject pending handoffs at session start. Kiro has no true SessionEnd hook; use ai-memory finalize-session --agent kiro-cli, with --session-id <uuid> for concurrent sessions, unless it is an interactive session launched with ai-memory run kiro, which finalizes it automatically when it exits if the run can tie the session to itself (see docs/managed-workstreams.md). ai-memory run kiro manages v2; add --v3, --mode, or --agent-engine v3 for version-safe v3 resume. No post-compaction hook can add context, so re-grounding after a compaction relies on the installed instructions (see usage.md).
Pool	Hooks-only	Poolside Agent CLI (pool). Lifecycle-hook capture via install-hooks --agent pool (alias poolside): Pool reads project-scoped hooks from the repo-root .poolside/settings.yaml, so ai-memory stages the scripts and prints a ready-to-paste hooks: snippet rather than writing committed project files; native commands enforce capture exclusions. Five Claude-shaped events (SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Stop) and no true session-end — Stop is a turn boundary, so run ai-memory finalize-session --agent pool after the final turn. SessionStart stdout injection is not demonstrated, so capture works but handoff injection does not — recover handoffs via MCP memory_handoff_list then memory_handoff_accept with that handoff_id. No first-party install-mcp client and no managed workstream (ai-memory run pool) are claimed: Pool's native session-store contract is not demonstrated (see docs/managed-harness-contributions.md). Verified against Poolside CLI v1.0.16.
GitHub Copilot CLI	Supported	MCP config (install-mcp --client copilot-cli → $COPILOT_HOME/mcp-config.json, root mcpServers, type: "http") + lifecycle hooks: install-hooks --agent copilot-cli writes $COPILOT_HOME/hooks/ai-memory.json (COPILOT_HOME defaults to ~/.copilot). Configured with PascalCase event names, so Copilot sends the VS Code/Claude-compatible payload (session_id, cwd, tool_name, tool_input, tool_result) and native commands enforce capture exclusions; the same 10 events as Claude Code, PostToolUseFailure included. Entries are flat with no matcher, because Copilot rejects it on SessionStart/Stop/SessionEnd and subagent events. The SessionStart hook delivers the prior session's handoff through Copilot's top-level additionalContext. Routing: Copilot CLI loads AGENTS.md, and install-skills --agent copilot-cli (or install-instructions --skills-agent copilot-cli) writes the managed Agent Skills to .github/skills (project) or $COPILOT_HOME/skills (global); memory_install_self_routing returns the same copilot_cli hints. --scope project is intentionally unsupported: Copilot's repository hook files (.github/hooks/*.json) are versioned and shared with the team and the cloud agent, so they cannot carry this machine's absolute executable and data-dir paths. ai-memory run copilot (alias copilot-cli) adds managed workstream resume: a generated --session-id for a fresh session, --resume=<id> to return, and visible-history import from $COPILOT_HOME/session-state/<uuid>/events.jsonl (see docs/managed-workstreams.md). The bare --client copilot alias of install-mcp keeps meaning VS Code Copilot. No post-compaction hook can add context, so re-grounding after a compaction relies on the installed instructions (see usage.md).
VS Code Copilot	MCP-only	.vscode/mcp.json for Copilot agent mode; no lifecycle hooks (Copilot does not expose them yet).
Zed	MCP-only	Native remote MCP under context_servers in Zed's user settings.json; no lifecycle hooks or managed-workstream support.
Meta Muse Code	Supported	MCP config (install-mcp --client muse, aliases muse-code, musecode) + lifecycle hooks (install-hooks --agent muse), both merged into ${XDG_CONFIG_HOME:-~/.config}/muse/settings.json around your own keys, servers and hooks. The writers add the mandatory "schema_version": 1 when it is absent (without it every muse command fails at startup) and never rewrite an existing value. The MCP entry is a stdio ai-memory mcp-bridge --agent muse that forwards the MUSE_SESSION_ID Muse gives its stdio servers, so Muse is session-aware; it carries "mode": "optional" (Muse's default required aborts the run when a server cannot start) and the install's --data-dir, because Muse starts stdio servers and hooks with a cleared environment. It goes under mcpServers, or under the legacy mcp_servers when the file already uses it; Muse ignores every MCP server when both maps are present, so --apply refuses that file and doctor reports it. Hooks run the native ai-memory hook --event … --agent muse command (no script bundle) with an empty matcher and a 30-second timeout, and native commands enforce capture exclusions over Muse's read_file, write_file, edit_file, apply_patch, search, bash, monitor, web_fetch and memory tools; a relative path resolves lexically against cwd, and Muse's tool_use_id is kept as the call id. Eight events: SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, PostToolUseFailure, PreCompact, Stop, SessionEnd; SubagentStart/SubagentStop are left out because Muse fires them every turn for its built-in reminder observers. The SessionStart hook delivers the prior session's handoff through hookSpecificOutput.additionalContext, and Muse's own SessionEnd closes the session. Verified offline against Muse Code 1.4.7: hook capture, exclusions, MCP session routing and handoff injection, run end to end in an isolated network namespace with a stand-in model provider. Skills need no extra step: Muse reads ~/.agents/skills and AGENTS.md. setup detects Muse by its config or data directory. No managed workstream (ai-memory run muse) and no transcript backfill. See install.md. Muse reports a compact SessionStart source, but its output contract is unpublished, so re-grounding after a compaction relies on the installed instructions (see usage.md).
IBM Bob	Supported	Native Streamable HTTP MCP in ~/.bob/settings/mcp.json plus five lifecycle hooks shared by Bob IDE and Bob Shell in ~/.bob/settings/settings.json. SessionStart injects the prior handoff as plain context, and Claude-shaped tool events enforce capture exclusions. Bob exposes no true SessionEnd, so run ai-memory finalize-session --agent ibm-bob after the final turn. ai-memory run ibm-bob and transcript backfill are not claimed because Bob does not document a stable transcript-store contract. See mcp-install.md.
DeepSeek Harness (DSH)	Hooks + MCP	MCP: install-mcp --client dsh (aliases deepseek-harness, deepseek_harness) prints a Cordis patch fragment (a - insert: item for @deepseek-ai/dsh-mcp-client) to merge into $DSH_HOME/profiles/<profile>/cordis.patch.yml; DSH has no fixed MCP config file, so --apply is refused. Lifecycle hooks: install-hooks --agent dsh stages the hooks/dsh script bundle, generates a Claude Code hooks.json for DSH's official @deepseek-ai/dsh-hooks-claude-code bridge, and prints the bridge patch fragment — again merged by hand into cordis.patch.yml (the generated hooks.json itself is written to the data dir by --apply). The bridge delivers exactly seven Claude Code events (SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Stop, SubagentStart, SubagentStop) — no PreCompact or SessionEnd — and runs SessionStart detached, so DSH sessions are stored as agent=dsh, pending handoffs are recovered via MCP memory_handoff_list then memory_handoff_accept, and finished sessions close with ai-memory finalize-session --agent dsh. No managed workstream.
Cline CLI	Hooks + MCP	install-mcp --client cline --apply merges Cline's required top-level type, url, and optional headers fields into ${CLINE_MCP_SETTINGS_PATH:-~/.cline/data/settings/cline_mcp_settings.json} and explicitly selects Streamable HTTP (a bare URL selects legacy SSE). install-hooks --agent cline --apply writes the nine supported CLI event files to ~/.cline/hooks (or project .cline/hooks with --scope project): task start/resume, prompt, pre/post tool, complete/cancel/error, and shutdown. The generated owner-only files refuse user-owned files and final-component symlinks. Cline starts task hooks detached, so pending handoffs are accepted through MCP; yolo mode disables hooks, and Cline must be restarted after installation. A headless cline -y task seeds its first prompt without firing UserPromptSubmit, and its TaskStart payload carries no task text, so that first prompt is not captured; a prompt Cline does deliver through UserPromptSubmit is. This installs Cline CLI hooks only; the VS Code extension uses a separate ~/Documents/Cline/Hooks convention. No managed workstream. No post-compaction hook can add context, so re-grounding after a compaction relies on the installed instructions (see usage.md).
FreeBuff	MCP-only	install-mcp --client freebuff --apply merges an ai-memory mcp-bridge --no-session-id stdio entry into ~/.agents/mcp.json. FreeBuff discovers that file from the current directory, its parents, or the home directory and already reads AGENTS.md; it has no documented lifecycle-hook or managed-workstream surface. The bridge reaches the configured local or remote server without attempting to start a second server that would contend for the data-dir lock.
Prime Agent	MCP-only	install-mcp --client prime-agent merges an HTTP entry (type: "http" + url) into the mcpServers map of $PRIME_AGENT_CODING_AGENT_DIR/settings.json (default ~/.prime/agent/settings.json), preserving other settings and servers; a project's .prime/agent/settings.json works through --config-file. A token is referenced as "bearerTokenEnvVar": "AI_MEMORY_AUTH_TOKEN", never written: Prime Agent 0.10 counts a user HTTP server as connected and names it in the model's prompt only with that variable set or an OAuth grant. A credential-less entry is still callable through mcp.call_tool("ai-memory", ...) but is not listed. The model reaches MCP tools from its Python REPL (await mcp.call_tool("ai-memory", "memory_query", {...})), and Prime Agent sends no session id or cwd, so pass workspace and project on project-scoped calls. Lifecycle capture and managed workstreams are not claimed: Prime Agent 0.10 removed the TypeScript extensions its 0.9 releases had and has no hook surface. Verified against Prime Agent 0.10.0.
Hermes Agent	Supported	install-hooks --agent hermes (alias hermes-agent) prints a ready-to-paste hooks: block for ~/.hermes/config.yaml; ai-memory never writes that YAML file, which Hermes also gates behind its hook-acceptance prompt (hooks_auto_accept). Each entry runs the native ai-memory hook command in exec form (Hermes splits command with shlex.split and uses no shell) with a 20-second timeout. Six events: pre_tool_call and post_tool_call for tool capture and exclusions (an MCP tool, named mcp__<server>__<tool>, keeps its server and tool name but never its arguments or result); on_session_start to record the start; pre_llm_call for the prompt (text from extra.user_message, never the conversation history); on_session_end as a turn boundary, since Hermes fires it after every turn; and on_session_finalize to end the session on CLI exit, /new or gateway shutdown (after a gateway /new only the ending session is closed). A delegate_task child's lifecycle events are dropped; its tool events are kept. Hermes ignores on_session_start output, so every primary-session pre_llm_call checks for a pending handoff and prints it as {"context": ...}, which Hermes adds to that turn; this includes a resumed native Hermes session. Hermes reports its own process directory as cwd; the hook routes by TERMINAL_CWD (Hermes' terminal.cwd) when it names an existing absolute directory (inside a gateway, only for the default profile, whose terminal.cwd a multiplexing gateway exports; another profile's gateway events route by an .ai-memory.toml in that profile's own Hermes home, ~/.hermes/profiles/<name>, when one is there), and a tool call still moves to the checkout its absolute workdir or path proves. A gateway session that expires idle is never finalized; close it with ai-memory finalize-session --agent hermes. When the community ai-memory-hermes-plugin is installed in $HERMES_HOME/plugins/ai-memory, the block wires only the two tool events, because the plugin already captures prompts, ends sessions and claims the handoff. MCP: install-mcp --client hermes prints an mcp_servers: entry that runs ai-memory mcp-bridge --no-session-id (no token in the file, and --apply is refused). Hermes does not read MCP server instructions, so install the skills with install-skills --scope global --agent hermes (~/.hermes/skills). No managed workstream. Modeled on the Hermes v0.22.2 source; not yet run end to end by the maintainers.
GrizzyBot	Supported	GrizzyBot, a native macOS agent app, ships its own ai-memory bridge: it posts lifecycle events to /hook with agent=grizzybot (alias grizzy-bot) and talks to /mcp directly, so there is nothing for install-hooks or install-mcp to write. Sessions are attributed to grizzybot, and its Claude Code-shaped tool payloads (tool_name/tool_input/tool_use_id) are stored as closed-schema tool families, never tool names or arguments. The bridge is maintained in the GrizzyBot repository; review it before pointing it at a shared server. No managed workstream.
Factory Droid	Supported	MCP config (install-mcp --client droid, alias factory-droid → ~/.factory/mcp.json, root mcpServers, type: "http") + lifecycle hooks (install-hooks --agent droid → ~/.factory/hooks.json) (#1240). The URL is written literally because Droid expands ${VAR} only in headers; a bearer becomes Authorization: Bearer ${AI_MEMORY_AUTH_TOKEN}, so export that variable where droid runs (a token-file install gets the same reference, never the token). Droid sends Claude Code-shaped hook payloads, so each entry runs the native ai-memory hook --event … --agent droid command (no script bundle) and native commands enforce capture exclusions over Droid's Read, Create, Edit, ApplyPatch, LS, Grep, Glob and Execute tools, verified against the Droid 0.240.0 tool schemas; Droid payloads carry no tool-call id. Seven events: SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, PreCompact, Stop, SessionEnd. The SessionStart hook delivers the prior session's handoff through hookSpecificOutput.additionalContext, and Droid's own SessionEnd closes the session, so no finalize-session step is needed. --apply merges around your own entries, and refuses to create hooks.json while ~/.factory/settings.json keeps hooks under its hooks key, because Droid reads those only while hooks.json is absent. The issue reporter ran capture and recall end to end with this hook wiring on Droid 0.239.0; the handoff injection follows Droid's documented contract and has not been run end to end yet. No managed workstream (ai-memory run droid). See install.md. After a compaction, SessionStart with source compact appends a post-compaction anchor to the new session context, following Droid's documented contract (see usage.md).
CodeBuddy Code	Hooks-only	Tencent CodeBuddy Code (codebuddy, alias code-buddy). Lifecycle-hook capture via install-hooks --agent codebuddy --apply: native ai-memory hook commands (no script bundle) merged into the hooks key of ~/.codebuddy/settings.json around sibling settings and third-party hooks. Payloads are Claude Code-shaped (session_id, cwd, tool_name, tool_input, tool_response), so tool observations and capture exclusions use that parser. Seven events: SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, PreCompact, Stop, SessionEnd. SessionStart stdout (hookSpecificOutput.additionalContext) delivers the prior session's handoff; with nothing to deliver, SessionStart and UserPromptSubmit print nothing, because CodeBuddy appends that stdout to the session. An interactive SessionStart may arrive without cwd; the hook then uses the CODEBUDDY_PROJECT_DIR CodeBuddy exports, and when neither names a directory it captures the event but claims no handoff, which stays open for memory_handoff_accept. setup detects CodeBuddy when ~/.codebuddy exists. No install-mcp client, no transcript backfill, no headless codebuddy -p session close and no managed workstream are claimed. Verified against CodeBuddy's hook documentation and the payloads reported on v2.164–v2.167 (#1299); not yet run end to end by the maintainers. See install.md.
Warp	MCP-only (documented)	url + headers entry in ~/.warp/.mcp.json or Settings > Agents > MCP servers; no documented env-var expansion in headers. No install-mcp client and no lifecycle hooks. Documented against Warp v0.2026.10.07.08.29, not yet verified end to end. See install.md.
Kilo Code	MCP-only (documented)	type: "remote" entry under mcp in ~/.config/kilo/kilo.jsonc (shared by the VS Code extension and the CLI), with "oauth": false and the bearer header from {env:AI_MEMORY_AUTH_TOKEN}. No install-mcp client and no lifecycle hooks installed. Documented against Kilo Code 7.8.8, not yet verified end to end. See install.md.
Goose	MCP-only (documented)	type: streamable_http extension (URL key uri) in ~/.config/goose/config.yaml, added with goose configure; no documented env-var expansion in headers. No install-mcp client and no lifecycle hooks installed. Documented against Goose 1.54.0, not yet verified end to end. See install.md.
Qwen Code	Supported	MCP (install-mcp --client qwen-code, aliases qwen, qwencode) plus lifecycle hooks (install-hooks --agent qwen-code) in ~/.qwen/settings.json. Streamable HTTP uses httpUrl (plain url is legacy SSE); a token-file install gets a stdio mcp-bridge entry. Ten Claude-shaped events including PostToolUseFailure and subagent start/stop; native ai-memory hook commands (no script bundle) enforce capture exclusions over Qwen's Gemini-like tools (write_file, read_file, run_shell_command, grep_search, glob). User prompts come only from the provenance-bearing submitted_prompt, not continuation/retry prompt content. SessionStart injects the prior handoff as hookSpecificOutput.additionalContext. Qwen fires a real SessionEnd, so finalize-session is not needed. setup detects ~/.qwen. ai-memory run qwen and transcript backfill are not claimed because Qwen does not document a stable transcript-store contract. See mcp-install.md.
Qoder	Supported	MCP (install-mcp --client qoder) and eight lifecycle hooks (install-hooks --agent qoder) share ~/.qoder/settings.json. MCP always uses the sessionless stdio bridge, so calls use explicit project scope. Claude-shaped prompt/tool events enforce capture exclusions; SessionStart injects a pending handoff as hookSpecificOutput.additionalContext, and missing cwd uses only QODER_PROJECT_DIR. setup, uninstall, and agent backup cover the integration. Qoder must be restarted after hook changes. Managed workstreams and transcript backfill are not claimed. See mcp-install.md.
OpenHuman	MCP-only (documented)	url + headers entry added in the app's mcp.json tab (a view over OpenHuman's server store, not a file on disk); header values are stored write-only. No install-mcp client and no lifecycle hooks installed. Documented against OpenHuman 0.64.15, not yet verified end to end. See install.md.
LLM/auth providers	Supported	Anthropic, OpenAI, OpenAI OAuth/Codex, GitHub Copilot, Gemini, OpenCode (Go and Zen), Cursor Agent CLI (cursor), OpenAI-compatible endpoints, and generic OIDC device auth for native hooks.
Embedding providers	Supported	OpenAI, Voyage, Google Gemini, and keyless OpenAI-compatible endpoints such as Ollama, LM Studio, and vLLM.