Home

aacpanel

A control panel for one machine and the Claude Code sessions on it — from a phone and from a monitor.

Not a dashboard. The panel does not only show containers, load and live sessions: it runs them. It brings containers up and down, opens and closes sessions, writes messages into them, answers the model's questions, sends files and slash commands.

One Go binary in a container, the front end embedded with embed, no npm in the project. Self-hosted under MIT: no account of ours, no plan, no server of ours.

Where to start

You want to	Read
put it on a machine	Install, then First sign-in
open your first session	The map, Settings of the map and Launch parameters
keep a session in the feed rather than a terminal	Sessions on the stream
run codex threads beside claude	Codex sessions
know what every screen shows	Screens on the phone, The desktop
work with an agent from the phone	Answering an agent, Permission modes
give a session the checklist, a role, briefs, calls, observers, alarms and its own restart	The panel's tools, Hooks and scripts
choose what reaches the phone	Alerts and pushes
know where the tokens went	Usage
see what the panel did on the host	The journal
understand how it is built	Architecture
reach it from outside	Network and access
update it	Updating
take it off the machine	Removing the panel
change something in it	Development

What it does

Screen	What is on it
Sessions	live sessions by contour and project — who waits for you, who works, who is quiet — each in the console (tmux) or the feed (claude -p under a holder), moved between the two, and codex threads beside them; the conversation as a feed — messages, thinking, tool calls, letters from other sessions and subagents, attachments — with the timeline of its work; the composer, typed or dictated, with files, a queue and a command after !; the question sheet and the permission dock; background tasks, subagents, workflows, and the observers and alarms a session asked the panel for; the checklist the session keeps and its role in the project; the model, the effort and the mode picked from a list; slash commands; Remote Control; the session terminal; a window on the host desktop; a restart and a close; an archive of closed conversations, with resume
Terminals	the shells of the panel on the host, opened at home or in a project of the map, and every other live tmux session of your user, to attach to or close
Repository	the code of a session's project: the changes of its branch, the files, a file with its diff or with who wrote each line and in which conversation, and notes on lines handed to the session
Briefs	long pieces a session published with questions in them, read and answered at whatever length it takes
Containers	the "stack → containers" tree with processor, memory and size on disk; logs, start and stop, a whole stack up and down
Machine	processor, memory, disks, network, top processes, checks on ports and external services; history rolled up by minute and by hour, charts from half an hour to a month; the versions of claude and codex, with an update of each
Profile map	"contour → group → project": where sessions may be opened, with what parameters, in which claude account; a settings page for each, the command of the next launch, and a journal of changes
Usage	transcripts broken down: what went out over a day, by model, by tool, by account, by project and session; the 5-hour and weekly limits of every account
Alerts	rules with thresholds and degradations, acknowledged from the screen; pushes to devices (Web Push, VAPID), chosen by kind and by source, with a Quiet button in the push itself
Journal	everything the panel did on the host: who, when, from which device, how it ended

Two things the panel deliberately will not do: shut down its own container, and send a push about a session to the device where that session is open right now.

The shape of it

Three processes, and this is the main decision of the project: their sets of rights are opposite, so they have no business being in one process.

Process	Where it lives	What it can do
aacpanel	container, distroless	nothing on the host; docker read-only through socket-proxy
aacpanel-agent	host, system unit	reading only, no graphics and no docker
aacpanel-exec	host, user unit	docker.sock and the graphical session; transcripts closed off explicitly

The service faces the internet — so it must not read the conversation with the model. The collector reads transcripts — so it must not run programs. The executor runs programs — so transcripts are closed to it. The whole of it is in Architecture.

What the machine needs

What	Without it
Linux with systemd	there is nothing to install
docker + compose v2	there is no panel
tmux	no session will open, in the console or in the feed
python3	every screen is empty
claude	there is nothing to show
codex, if you want it	no codex sessions; see Codex sessions
a terminal (konsole, gnome-terminal, alacritty…)	no windows; the normal mode for a machine without graphics

Postgres does not have to be installed — it arrives as a container — and neither does Go: the installer downloads its own into a cache and builds itself and the executor with it. On Debian, Ubuntu and their kin it offers to install docker, compose and tmux with apt as well, and the whole install is one command — see Install:

git clone https://github.com/BeMySlaveDarlin/aacpanel ~/aacpanel && ~/aacpanel/install.sh