Zulu Assistant – an ops board and agent workforce for your Mac

A local ops board and agent workforce for the Mac that runs your automations. It watches every LaunchAgent, container, cron line and endpoint on the machine. It shows your live Claude Code and Codex sessions next to them. When something breaks, it heals what it safely can and escalates the rest to you.

Website: https://zuluassistant.com

Recorded in demo mode (./install.sh --demo). Every name in it is synthetic. A 38-second cut is in docs/media/demo-short.gif.

- Background jobs fail silently. A LaunchAgent stops loading, a cron line disappears, a container goes unhealthy. You find out days later from the damage.

- Agent sessions are invisible. Six Claude Code sessions across six terminals: which one is waiting on you, which one is about to hit its context limit, which one died on reboot?

- Agents can't coordinate safely. They have no shared task list, no approval gate for risky steps, and no rule for when a human must decide.

The server is a zero-dependency Node 22 process. Collectors run under time bounds every

60s, and a snapshot goes to the browser over SSE. Everything owner-specific (what to

watch, who the agents are, what needs approval) lives in overlay/. More in

docs/ARCHITECTURE.md.

curl -fsSL https://zuluassistant.com/install | bashPrefer GitHub directly? curl -fsSL https://raw.githubusercontent.com/zulu-assistant/zulu-assistant/main/get.sh | bash does the same.

That installs the toolchain (it shows the list and asks once), the board, cmux config, the brain

and the agent workforce, then starts zulu setup: connect GitHub, choose Claude Code or

Codex for Mission Control and for workers, pick what to watch from a scan of your Mac, add alert

channels, create your vault, grant the macOS permissions. Re-run any step later (zulu setup --step engines); the board shows a setup card until you're done.

Just looking? ./install.sh --demo from a clone runs a synthetic board on :3210 with Node 22 only.

Everything the setup does and cannot automate is in docs/INSTALL.md.

tmux is great at keeping panes alive. It has no idea what an agent is doing. cmux exposes agent lifecycle hooks, per-workspace status pills, a notification feed, session restore with Claude auto-resume, and an authenticated socket API. The board and the mesh are built on those. The honest trade-offs, and the cases where tmux is still the better choice, are in docs/WHY-NOT-TMUX.md.

- Read-only by design. The board never writes to anything it watches. It writes

only its own data/, cmux notifications, the heartbeat row, and actions you click (KICKSTART, RESTART, START, DISPATCH, ASK MASTER). Demo mode performs no actions at all.

- Policy, not vibes. POLICY.mdbelongs to you. Anything paid, outward-facing or destructive escalates to you, every time.

- Approvals on the board. Agents can request approval. Only the board's WORK panel can grant it, using a per-install decision token.

- Escalate, never guess. Agents never auto-answer a trust dialog. They deliver messages only into a ready pane. Anything else is queued and reported.

- Network. The board serves localhost and your Tailscale range only. The LAN gets 403.

- Clean by construction. Every file is classified in publish/manifest.json, and a scrub gate plus gitleaks run in CI. See SECURITY.md.

cmux is a separate GPL-licensed application. Install it yourself, unmodified. Zulu Assistant only calls its CLI and socket and does not bundle or link it.

examples/ generic templates, shipped (the board runs on these until you add overlay/)

overlay/ YOUR config, gitignored: ./install.sh init copies examples/ here

config/jobs.mjs what to watch: JOBS, DOCKER_CONTAINERS, ENDPOINTS, CRON, PROCESSES, gauges, SETTINGS

config/agents.json the mesh directory (maintained by the board)

POLICY.md what agents may do without you

MISSION-CONTROL.md the master agent's contract

data/secrets.env SMTP, SMS webhook, heartbeat keys (template: secrets.env.example)

Config is resolved overlay/ → core → examples/. Adding coverage takes one entry in

overlay/config/jobs.mjs. The board watches it on the next poll.

- v0.1: the board, demo mode, Mission Control, Agent Mesh, the brain templates, the installer.

- Next: Homebrew tap and an npxone-liner, a Linux/systemd collector, a pluggable notifier interface (Slack, ntfy), a hosted heartbeat relay so the dead-man's switch needs no database of your own.

- Ideas and votes: Discussions. Good first issues are labelled.

The installer asks once, and only in an interactive terminal: Star zulu-assistant on GitHub? [y/N]. The default is No. If gh is not logged in, it skips the question

silently. Only an explicit y stars, using your own gh login. The board may also show

one toast, the first time it catches something for you, with two buttons:

Star, which just opens this page, and Never ask again. Both answers are kept in

data/star-prompt.json, and neither asks again. No feature ever depends on it. To star

later, run ./install.sh star.

CONTRIBUTING.md · SECURITY.md · CODE_OF_CONDUCT.md · CHANGELOG.md

Commercial setup & support: digitalnethosting