Glossary
AgentMux has its own vocabulary. This page is the authoritative source — when two pages use a term differently, this one wins.
agent operating environment — How AgentMux positions itself: more than a workspace, it’s an environment where agents are first-class residents with stable identity, memory, a streaming parser, lifecycle management, and access to the Agent App API. An agent running inside AgentMux can open panes, rename tabs, discover peers, and send messages — not just process text.
Agent App API — The typed RPC surface an agent uses to call back into the AgentMux workspace — spawn panes, set titles, render dashboards, update status. See /internals/agent-app-api.
AppImage — The Linux distribution format for AgentMux. A single self-contained executable (.AppImage) that bundles the app, the Chromium runtime, and all shared libraries. Run directly: chmod +x AgentMux_amd64.AppImage && ./AgentMux_amd64.AppImage. On first launch it extracts itself to ~/.local/share/agentmux/extracted/<version>/ for faster subsequent starts. See Installation.
agent pane — A pane that runs an AI agent session. Streams the agent’s tool calls, reasoning, and file diffs into a structured view. See Pane types.
block — An immutable persisted unit of pane state. A block is the smallest thing the reducer writes. Terminal output, code block, diff, chat message — each is one or more blocks. Layered structure with reducer-driven mutations. See The reducer stack.
browser pane — A pane of type browser — an embedded CefBrowserView (a child Chromium browser, not an iframe). Each browser pane runs in its own renderer process; opening more browser panes adds more renderer processes. See Browser pane and Pane types.
CEF — Chromium Embedded Framework. The host process embeds Chromium via CEF to render the SolidJS frontend; this replaces the platform WebView and gives AgentMux a consistent Chromium 148 runtime on Windows, macOS, and Linux. See Architecture overview.
channel — A named on-disk data-dir scope that groups AgentMux builds for shared agent definitions and settings. Key channels: stable (installed + released portables), local-<branch> (locally built portables), dev-<branch>-<clone> (dev-mode builds). Agent definitions and settings.json persist within a channel across version upgrades; runtime databases (SQLite, CEF cache, IPC artifacts) are scoped per (channel, version). See Multi-instance & dev mode.
host — The CEF process (agentmux-cef). One per instance. Owns the OS windows, the browser panes, the JS bridge, and IPC fan-out to every renderer. Spawned by the launcher; spawns the Chromium subprocesses. (The sidecar is also spawned by the launcher, which owns its lifecycle — see Architecture overview.)
Identity bundle — A named credential set bound to an agent at launch. Decouples who an agent acts as (GitHub PAT, AWS profile, API keys) from what an agent does (the Memory bundle). The same Memory can run as multiple identities — work, personal, demo — without restart. See Identity bundles.
instance — One AgentMux process tree, rooted at one launcher, with its own sidecar, host, renderer(s), and process-isolation container (Job Object on Windows / process group on Linux + macOS). Each launch of agentmux-launcher creates a new instance. Multiple instances run side-by-side. The “other AgentMux instances on LAN” entries shown in the status bar each correspond to a separate instance. See Multi-instance & dev mode.
Note: “instance” is not one process — a baseline single-window dev session has 4 processes (launcher + sidecar + host + 1 renderer), plus shared GPU/utility Chromium subprocesses, plus more renderers as windows and browser panes are opened.
Note: instances and data dirs don’t always map 1:1. The data dir is keyed by channel, not by instance. Two portables on the same channel launched from different folders are two distinct instances (two process trees, two process-isolation containers) that share the same on-disk SQLite database — see Multi-instance & dev mode for the per-instance vs per-channel split.
jekt — Verb. Inject a message directly into a target agent’s terminal stdin. Synchronous, immediate processing. Counterpart to message. Use the SendMessage MCP tool (Agent App API) or POST /agentmux/reactive/inject to jekt an agent.
launcher — The 325 KB shim process (agentmux-launcher) that boots AgentMux. Spawns the host and sidecar, holds the IPC auth-key, tracks window reality. See Architecture overview.
Memory bundle — An agent personality + capability stack: provider, model, instructions, MCP servers, skills, environment. Reusable across launches. Memory is what an agent does; Identity is who it does it as. See Memory bundles.
message — Verb. Deliver a message to the recipient’s mailbox; the recipient reads it when they’re ready. Asynchronous counterpart to jekt. Use the SendMessage MCP tool (Agent App API) with the target agent’s name.
MuxBus — The cross-process, cross-machine interagent messaging substrate, in three tiers: Host (in-process reactive handler, same AgentMux instance), LAN (mDNS peer-to-peer forwarding, same network, v0.46+), and WAN (opt-in cloud relay you operate). Two delivery models: jekt and message. Powers the DiscoverAgents and SendMessage Agent App API tools. See Interagent Communication and Reactive event bus. (Formerly called agentbus.)
MCP — Model Context Protocol. A JSON-RPC protocol that AI agents use to talk to external tools and data sources. Agents subscribe to MCP servers; MCP servers expose tools, resources, and prompts.
OAC — Origin Access Control. The AWS CloudFront mechanism that restricts S3-bucket access to a specific distribution. Used by the docs and landing infrastructure; not a runtime AgentMux concept.
pane — A UI slot in the workspace layout. Panes have types: terminal, agent, code editor, browser, swarm, subagent, system metrics, code preview. The user composes a workspace by mounting panes in a grid. The browser type is a special case — see browser pane.
process — An OS process. Avoid in user-facing copy — one instance has 4+ processes (launcher, sidecar, host, renderers, plus Chromium GPU/utility subprocesses), so “this AgentMux process” is ambiguous. Reserve “process” for internal docs that genuinely discuss the process tree.
process group — The Linux + macOS equivalent of a Windows Job Object for AgentMux’s process-isolation needs. The launcher places the host and sidecar in a process group. On Linux, PR_SET_PDEATHSIG ensures child processes terminate when the launcher exits — this prevents orphaned agentmux-cef or agentmux-srv processes if the launcher crashes. On macOS, crashed-parent children are reparented to launchd rather than killed; the process group provides isolation but not automatic orphan cleanup.
reducer stack — AgentMux’s layered state model. Each layer (launcher / host / sidecar / frontend slice) owns a slice of state, with dispatch ordered top-to-bottom. The single canonical place to look for “why did X change?” See The reducer stack.
Armory (formerly “Trust Center”) — The app-wide credential + primitive hub. Six tabs: Accounts (OAuth logins and API keys for every provider), Identities (named credential sets — Identity bundles), Brain (native per-agent memory notes), Bundles (reusable agent definitions — Memory bundles, formerly “Presets”), MCP Servers, and Skills. Open from the hamburger menu (≡) → Armory. See Armory.
renderer — A Chromium renderer process (agentmux-cef --type=renderer). Runs the SolidJS frontend JS for one browser context. Not a singleton — every OS window gets its own renderer, and every browser pane inside a window adds another. Multiple renderers per instance is the normal case.
sidecar — The Rust app-domain server process (agentmux-srv). Owns workspaces, tabs, blocks, layouts, agents, identity. Persists to SQLite. Bound to 127.0.0.1 only. See Architecture overview.
Unix domain socket — The IPC mechanism the launcher uses on Linux and macOS to communicate with the host. The socket lives at $XDG_RUNTIME_DIR/agentmux/<hash>.sock (primary) or /tmp/agentmux-<uid>/<hash>.sock (fallback when $XDG_RUNTIME_DIR is unset), where <hash> is derived from (data_dir + version) — the same isolation key as the Windows named pipe. The counterpart Windows primitive is a named pipe (\\.\pipe\agentmux-<hash>). Both carry the same wire protocol (the reducer command set defined in agentmux-common/src/ipc). See Platform support → Linux.
streaming buffer — In the agent pane virtualization model: the trailing ~50 message rows that are always mounted in normal flow and not recycled. Eliminates measurement lag during token streams. See Agent pane virtualization.
subagent — An agent spawned by another agent. Claude Code’s sub-agent feature is the canonical example. AgentMux’s Subagent Watcher tracks these and gives each one its own focused activity-stream pane. See Subagent Watcher.
swarm — The multi-agent orchestration view. Shows every active and completed subagent across your workspace, with event counts, models, and last-activity timestamps.
window — An OS window owned by an instance’s host. One instance can have many windows. Each window has a backend windowId (UUID), a launcher label ("main", "window-pool-...", internal/IPC), and a window rank. Renamable via the bottom-right window-list popover (open it via the version chip → double-click a row, or press F2).
window rank — A window’s 1-based position within its instance, shown after the version in the status bar as (2), (3), etc. when more than one window is open. Cosmetic only — the underlying identity of a window is the windowId, not the rank.
WRR (Window Reality Reconciliation) — The launcher’s loop that reconciles desired window state (what AgentMux wants) against actual OS state (what the OS says). Defends against state drift when external tools or the user move/resize/close windows. See Window Reality Reconciliation.
If a term is used somewhere in the docs and isn’t here, that’s a gap — please file an issue or PR.