tamux tamux daemon-first runtime

Agentic Terminal Runtime

Daemon-first AI environment

A terminal multiplexer where the daemon owns all state. Sessions, goals, and memory persist beyond any client connection.

Get started Architecture
Daemon-firstState lives in the daemon, not the UI.
Goal runnersDurable autonomy for multi-step work.
Governed executionApprovals and provenance built in.

What it is

tamux is a shared execution environment where the daemon owns terminal sessions, agent threads, task queue state, goal-run state, approvals, memory, and telemetry. Electron, the TUI, the CLI, MCP clients, and chat gateways all reconnect to the same durable runtime.

Mental model: an autonomous operating environment with terminal surfaces, not a disposable prompt window.

Capabilities

Daemon as source of truth

The daemon owns sessions, threads, tasks, approvals, goal runs, transcripts, memory, and operational state. Clients are views into that state.

Durable goal runners

Goal runs accept long-running objectives, create plans, dispatch child tasks, survive disconnects, and record reflections and reusable skills.

PTY and workspace control

Manages panes, surfaces, terminals, command history, transcripts, and terminal-native execution while keeping agent actions visible.

Layered memory

Identity, durable facts, operator profile, structured runtime state, recall, skills, and provenance-backed memory.

Governed autonomy

Risk is evaluated structurally. Approvals are scope-bound and can go stale. Risky actions are critiqued before execution.

Runtime plugin system

Plugins add components, commands, YAML views, assistant tools, and executors for domain-specific workflows.

Multiple operator surfaces

Electron for desktop, TUI for SSH, CLI for automation, MCP for external agents, gateways for chat platforms.

Self-orchestrating runtime

The daemon delegates, checkpoints, detects stuck states, recovers, learns from traces, and escalates when blocked.

Note: The daemon/runtime is the most complete layer today. Public clients expose goal, approval, and inspection workflows.

Architecture

Operator
|
+--> Electron / React UI
+--> TUI
+--> CLI
+--> MCP clients
+--> Slack / Discord / Telegram via gateway
         |
         v
    tamux daemon
         |
         +--> PTY session management
         +--> Agent runtime
         +--> Task queue
         +--> Goal runners
         +--> Approval flow
         +--> Persistence + telemetry

The fundamental boundary: once the daemon is running, the rest of the platform becomes interchangeable surfaces over the same long-lived state.

Next steps

Operator guides

Installation, first-run flow, daily habits, and scenario-based workflows.

Technical deep dive

Daemon ownership, task queue, self-orchestration layers, and component breakdowns.

Goal runners

How durable autonomy works, when to use it, and how it fits Mission Control.

Memory and security

Layered memory, provenance, critique, approvals, and governance semantics.

Plugins

How tamux is extended through runtime-installed or in-tree plugins.

Reference

Paths, providers, build/run commands, packaging, notifications, and publishing.

Who it's for

  • Developers who want long-running AI work to survive closing the UI.
  • Operators who need a visible, governed control plane rather than invisible automation.
  • Teams exploring multi-agent workflows, plugins, background tasks, and domain-specific mission layers.
  • People who want terminal-native workspaces but do not want to give up modern orchestration and memory.

Hosting

This docs site is plain HTML, CSS, and JavaScript. No mandatory docs generator. No build step. Open index.html locally, serve the folder with a static HTTP server, or publish through GitHub Pages.

Recommended: keep the site in github-docs/ during authoring, then publish through Pages.