Built to be driven.
Venom is an agent-friendly OS that lives in the terminal. These are the ideas every repo in the family is built on, from the shared Zig modules up to the bundle.
We orchestrate. We don't reinvent.
Venom does not ship an agent runtime or a harness. It runs the agents you already use (Claude Code, Codex, opencode, any ACP agent) through their official channels, and gives each one a room of its own: a pane, a git worktree, a scoped set of rights.
The hard part of working with agents is not the model. It is keeping many of them in view, isolated from each other, and one keystroke away from your decision.
What you type, an agent can call.
Every binary follows the same contract, so an agent that learns one learns them all. A human at the keyboard and an agent over MCP drive the same thing with the same verbs.
- One binary
- The daemon and its CLI are one binary: serve runs the daemon, and every other verb is a client of it.
$ venomx serve - Verbs
- Every action is a verb. A keybinding is just a key bound to a verb.
$ venomx split --json - One schema
- One verb schema generates the CLI, the MCP server, the docs and the shell completions.
$ venomx mcp - Structured
- --json on every command, with stable exit codes.
$ venomx list --json - Observable
- An NDJSON event stream for every state change.
$ venomx events --json - Teachable
- skill prints the instructions an agent needs, and installs them into Claude Code, Codex and opencode.
$ venomx skill install - Self-diagnosing
- doctor checks the setup and prints each fix as a command you can run.
$ venomx doctor - Config as verbs
- Config is a ZON file, changed through verbs, never edited by hand by an agent.
$ venomx config set …
A daemon at the core.
Each product is a long-running daemon with clients around it. That is what lets an agent keep working after you close the terminal, and lets you attach later to see what it did.
The daemon owns the state.
PTYs, sessions, windows and panes live in a long-running daemon. Clients attach and detach; a crash or a closed terminal loses nothing.
Headless first.
Every component works with no TUI attached. The TUI is one client among many, next to the CLI, the MCP server and your scripts.
The server is authoritative.
venomx sends raw PTY bytes to every client instead of screen diffs. Each client keeps its own viewport, scrolling and selection; the daemon keeps the truth.
Supervised, not fragile.
A supervisor restarts what crashes, with backoff. venom-os up supervises the whole family the same way.
Trust is handed out, not assumed.
Every caller is identified, by the PID on the other end of the socket or by a token, and gets scoped rights: read, write, respond, admin. venom starts every caller read-only. venomx trusts your own processes until you turn isolation on.
When an agent wants to do something that needs a person, the request lands in one inbox. You approve, deny or take over the pane.
Each piece stands alone.
The family is many small repos, not one big one. Use one piece on its own, or combine them. Under all of them sit the shared foundations: venom-std and venom-term.
- venomx
- A tmux replacement that agents can drive
- venom
- Headless or TUI orchestration of Claude Code, Codex and others
- venomx + venom-desk
- A TUI desktop
- venom + venomx + venom-desk
- Agents in panes, one approval inbox, an overview of every agent
- everything + venom-os
- The agentic TUI OS
What we leave out.
Small surfaces are easier for agents to learn and for people to trust. So some things are left out on purpose.
Zig 0.17
Every repo is Zig, pinned to one release line and upgraded on purpose.
TUI first
Everything runs in a terminal, locally or over SSH. No desktop GUI apps yet.
No plugins in v1
No embedded scripting, no JIT, no dynamic plugins. You extend Venom through verbs, events and hooks that run executables.
Official channels only
Models and agents are reached through their official CLIs and APIs. Venom never spoofs a vendor client.