DROOdotFOO/raxol

> Recursively, axol. Forever FOSS.
Write one app. Render it to a terminal, a browser, an SSH session, or an agent.
Your application is a single TEA module (init, update, view) running as an OTP GenServer. Raxol renders that module to four surfaces from one codebase:
The interesting part is the runtime. Your app gets crash isolation per Component, hot code reload without restart, distributed clustering with CRDTs, and an agent surface where LLMs interact with structured Component trees instead of scraping pixels. Those are BEAM properties, from a VM built for systems that can't go down, can't lose state, and hot-swap code while running.
Bubble Tea, Ratatui, and Textual are excellent renderers. A2UI and AG-UI define agent-UI wire formats. Raxol is the runtime that renders all four surfaces from one source module. See Why OTP for the framework comparison, and Why Raxol for how the runtime compares to Python agent stacks like Hermes and Omnigent.
Agents
Raxol is a runtime for agents as much as for humans. Every interactive Component automatically exposes MCP tools (Button gives click, TextInput gives type_into/clear/get_value), and a focus lens filters to roughly 15 relevant tools per interaction. Where A2UI and AG-UI define how agents talk to UIs at the wire level, raxol generates the UI and the agent surface from one Component tree: same source, two projections.
mix mcp.server starts the MCP server on stdio for Claude Code integration, and mix raxol.code is an interactive terminal coding agent (the axol face) with every mutating tool call gated by an ALLOW/ASK/DENY authorization engine. See the Coding Agent.
**Code** is the coding-agent product, in two hands-on surfaces: mix raxol.code is the interactive terminal TUI (the axol face ≡··≡), and mix raxol.p is its headless twin (prompt in on argv, answer to stdout, contract events to stderr) for pipes and CI. Every mutating tool call is gated by an ALLOW/ASK/DENY authorization engine. From a clone, one setup command and one launch:
No API key configured? The TUI opens on a provider wizard instead of failing. /inspect (or mix raxol.inspect from packages/raxol_agent) shows every config source the agent will use in the current directory.
Sessions are durable. Each session journals its events to disk, so --continue and --resume restore the model context and the scrollback together, --replay prints a transcript straight from the journal (--to-offset N stops at an offset), /rewind drops back to an earlier turn, and /share mints a signed 24-hour link to a read-only transcript that follows the session live (needs RAXOL_SHARE_SECRET and a host mounting Raxol.Agent.Code.ShareLive).
The same TUI serves over SSH: mix raxol.code --ssh --ssh-tenants /srv/tenants hosts many users from one daemon, each behind their own public key with their own cwd jail, session store, and spending identity (ssh @your-host -p 2222 is the whole client). Single-tenant (--authorized-keys) and hosted deployment (RAXOL_SSH_CODE=true) are in Coding Agent.
Two unattended surfaces run the same agent. bin/raxol-acp (or mix raxol.acp) serves it over the Agent Client Protocol on stdio, for editors that spawn an agent themselves; Raxol.Agent.Harness.McpTools registers harness_start_session, harness_send_prompt, harness_read_transcript, and harness_list_sessions with the MCP registry, so a session started by an MCP client resumes later in the TUI. The ACP surface runs the full toolset with every sensitive call gated on a session/request_permission round trip, fail-closed on the decision: a client that refuses, times out, or does not implement permissions denies the write and keeps reading. The MCP surface stays read-only: write_file, edit_file, and bash are absent where nobody is there to answer an approval prompt.