nest # Attach TUI to running instance
nest -w wren # Attach to named workspace
nest -s background # Attach to specific session
nest init [name] # Create workspace (setup wizard)
nest start # Start kernel foreground (bare metal)
nest start -c config.yaml # Start with explicit config
nest status # Show workspace info
nest list # List known workspacesRunning nest with no subcommand (or just flags) connects the TUI to a running instance. If nothing's running, it tells you how to start it.
Workspace resolution order:
-w <name>flag — look up in registry, then~/.nest/<name>, then as path- Current directory has
config.yaml— use it - Registry has a default workspace — use it
~/.nest/has exactly one workspace — use it- Fail with list of known workspaces
A workspace is a self-contained directory. Default: ~/.nest/<name>/.
~/.nest/wren/
├── config.yaml
├── plugins/
├── cron.d/
├── .usage.jsonl
└── .pi/agent/ ← isolated from ~/.pi/agent/
├── models.json
├── sessions/
└── settings.json
nest init walks through:
- Instance name — workspace path
- Agent working directory — pi's cwd
- Model provider — Anthropic, OpenAI, Google, etc.
- Session — name and config
- Chat platforms — Discord with token + channel mapping
- HTTP server — port and auth token
- Cron — scheduler directory
Workspaces are registered in ~/.nest/workspaces.json.
Each workspace has its own .pi/agent/ for models, sessions, and settings — it never touches ~/.pi/agent/. You can run pi standalone alongside nest without config conflicts.
Nest doesn't manage Docker containers. If nest init generated Docker files, use Docker tools directly:
docker compose up -d # start
docker compose down # stop
docker compose up -d --build # rebuild
docker compose logs -f # logsnest (attach) works the same regardless — it connects via WebSocket to whatever's listening on the configured port.
nest start runs the kernel in the foreground. For background operation, use systemd or a process manager:
cp systemd/nest.service ~/.config/systemd/user/
systemctl --user enable --now nest