magents is a shared session bus for coding agents, consisting of an MCP server and a small CLI. The problem it addresses is that when users run multiple coding agents at the same time, context often gets trapped in another window and must be manually restated or pasted. magents directly reads the conversation records that each agent has already saved to disk, providing a unified API so that agents can continue each other's work, send messages to each other, or start independent sessions.
Main capabilities
- Handoff without opening a new thread: after handling a branch in one agent (such as Claude), switch to another agent (such as Grok), which can read the former's live session and continue without pasting context.
- Sending messages on someone else's behalf: when an agent encounters an obstacle that is the responsibility of another agent, it can directly inject a message into that active thread and continue, which is suitable for scenarios where the sender already has the failed query, files, and constraints.
- Starting independent work: when a task can proceed independently, a new headless persistent session can be started, providing the full prompt, using an isolated working directory when files may conflict, and requiring a reply through magents. The started agent retains its host's native approval policy, and starting it does not add any approval bypass.
Usage Installation: supports Homebrew (macOS / Linux), APT (Debian / Ubuntu), or downloading the corresponding platform binary from Releases (magents-x86_64-unknown-linux-musl, magents-aarch64-unknown-linux-musl, magents-aarch64-apple-darwin, magents-x86_64-apple-darwin). Host plugins: the plugin package includes the magents skill and an MCP entry that runs magents mcp. The CLI must be installed first (brew install abnegate/tap/magents), then load the corresponding folder under plugins/. Gemini CLI can install the extension directly from the repository; AGY CLI installs the plugin from plugins/agy. Registering MCP: magents install --all registers the stdio MCP server with every installed host, skipping hosts for which the required binary is unavailable, including Grok, Claude Code, Codex, Cursor, OpenCode, Gemini CLI, GitHub Copilot CLI, AGY CLI. It also writes the magents and learn skills under the supported host skill directories; /learn reads all local agent sessions, not limited to Grok. Manual configuration: Grok and Codex can point to the binary themselves; Cline can add configuration to cline_mcp_settings.json in MCP Servers → Configure MCP Servers. The tools appear after restarting the agent session or refreshing /mcps. Reference prefixes: supports prefixes such as claude:, grok:, codex:, cursor:, opencode:, gemini:, agy:, copilot:, etc. Adding --output json to any command provides stable machine-readable output. Running magents with no arguments and under piped stdin starts the MCP server. magents spawn reads the full task from stdin by default (supports --prompt-file), and the prompt text is not passed as a process argument.
Session Communication Mechanisms list_sessions / read_transcript / search_transcripts / search_memories are used for handoff; create_memory can write first-party memory to another toolchain (Claude, Codex, or Grok). The write path is chosen according to where the work should happen: spawn_session is used for a new, headless, persistent, independent session, and success only means the launch was accepted (accepted: true, status: "starting"), not that the task is complete; send_message is used for an existing session, always records mailbox mail, and injects a live user turn when the host supports it; handoff compresses the current session into an existing active session so that it continues the same work.
Delivery Routing send_message always appends to the mailbox, then preferentially uses the native live path, otherwise starts a supervised headless resume. The supervised route passes the user turn via stdin and does not expose transcript text, tokens, or raw host output in the response. spawn never adds approval bypasses (such as --dangerously-skip-permissions, --yolo, --full-auto, etc.).
Session Discovery Sources Claude's ~/.claude and ~/.claude-* (as well as Desktop Claude / Claude-* session directories), Grok's ~/.grok/active_sessions.json, Codex's sqlite + rollout JSONL, Cursor's agent-transcripts, OpenCode's SQLite (opencode.db and channel databases, v1 session and v2 session_v2 / session_message tables), Gemini journals, AGY CLI's conversations / brain plus Antigravity desktop conversation_summaries, Copilot's session-state. Claude sessions include a profile field when they come from a named home (e.g., work corresponds to ~/.claude-work), and resume and live injection use that home's CLAUDE_CONFIG_DIR.
Use Cases and Limitations Suitable for developers who use multiple coding agents at the same time, need to hand off context across sessions, send messages to a specified active session, or start independent persistent tasks. Limitations include: requires macOS or Linux (Claude UDS injection is Unix-only); spawn success only means the launch was accepted; no approval bypasses are added; specific information such as charges, prices, and platform support scope is not yet provided.
