Bramble User's Guide

Complete user's guide for Bramble — covers building topologies, running SONiC labs, in-app debugging tools, the 23 hands-on labs, and connecting an AI client over MCP.

← Back to Bramble

Welcome to Bramble!

Version 1.0.4 | macOS 14+ (Sonoma) | Apple Silicon

Bramble is a native macOS app for building and running SONiC (Software for Open Networking in the Cloud) network labs. Design a topology visually, boot it as real virtual switches running on Apple’s Virtualization.framework, and connect over SSH or serial console — no Linux workstation, cloud account, or QEMU required.

Getting Started

Purchasing and Installing

Bramble is sold directly from DendroLabs through Lemon Squeezy — it isn’t on the Mac App Store.

Personal — $59 — individual use, learning, and home labs
Business — $129 — the same app, licensed for commercial use

Both tiers are a one-time purchase; there’s no subscription. After checkout, download the app and drag it into Applications like any other Mac app. Bramble is notarized by Apple, so macOS opens it directly — you won’t see an “unidentified developer” warning.

First Launch

The first time you open Bramble, a setup screen explains that it needs to download and prepare VM images, and that macOS will ask to allow local network access (required for VM-to-VM and VM-to-Mac networking — click Allow when the system prompt appears; see Troubleshooting if you miss it).

Click Install Images. Bramble downloads roughly 1.9 GB of VM images from cdn.dendrolabs.com and expands them on disk — this takes a few minutes depending on your connection.
Watch the progress bar; it shows download and expansion progress with a byte counter.
When setup finishes, click Get Started.

No extra tools, no manual steps. Images and boot files land in the app’s sandbox container at ~/Library/Containers/com.dendrolabs.bramble/Data/images/.

If you already have your own sonic-vs.img, Select Manually… on the same screen lets you point Bramble at it instead of downloading.

Licensing and Activation

Your purchase includes a license key, emailed to you after checkout. Activate it the first time you open Bramble:

Click Enter License… at the bottom of the sidebar.
Paste the license key from your Bramble purchase email.
Click Activate.

If your key isn’t to hand, you aren’t locked out. Bramble runs normally for 30 days while you track it down, and the sidebar shows “Trial — N days left” for the rest of that window. If it runs out before you activate, Bramble drops to read-only: you can still open, build, and view topologies, but Start All is disabled until you enter your key. Your saved labs are never touched.

Moving to a new Mac or reinstalling? Click Deactivate this Mac first (shown once you’re licensed) to free the activation, then activate again on the new machine.

System Requirements

Resource	Minimum	Recommended
Mac	Apple Silicon (M1 or later)	M1 Pro or better
macOS	14.0 (Sonoma)	15.0 or later
RAM	8 GB	16 GB or more
Disk	5 GB (images)	10 GB or more (with overlays)

Intel Macs are not supported. Each SONiC switch uses about 2 GB of RAM while running, and each Linux host about 512 MB — a 2-node lab needs roughly 4 GB, and the full EVPN fabric (4 switches + 3 hosts) needs about 9 GB.

Updates arrive automatically: Bramble checks once a day and offers new versions from Check for Updates… in the Bramble menu. Updates are cryptographically signed and never install without your consent; point releases download as small binary deltas rather than the full app again.

The Interface

Bramble’s window has three main areas:

Sidebar (left) — the device palette, bundled presets, protocol config picker, image status, logging settings, and your trial/license status
Canvas (center) — where you place devices and draw cables; a live link-status legend appears in the top-right corner once a link exists
Terminal Panel (bottom, toggled from the toolbar) — SSH and serial console sessions open here as tabs, one per device

The toolbar across the top holds Start All / Stop All / Clear, bulk console and SSH buttons, containerlab import/export, a status message area, and a health chip showing how many VMs are ready.

The Inspector is a pane on the trailing edge of the window, switched by an icon rail with four tools: Lab Guides, DB Inspector, Service Health, and Packet Capture. Each keeps its own state as you switch between them — see “Inspecting and Debugging” below.

Building a Topology

Placing Devices

The sidebar’s Devices palette offers two device types:

Click SONiC Switch or Linux Host in the palette.
Click anywhere on the canvas to place it. The toolbar shows “Click canvas to place [device]” while you’re in placement mode — click Cancel to back out.
Repeat for as many devices as your topology needs.

Right-click a device and choose Rename… to give it a friendlier name, or Delete Device to remove it (a device with a running VM must be powered off first). You can also select a device and press Backspace to delete it.

Drawing Cables

Cables connect devices port-to-port entirely by right-click:

Right-click the source device and choose a port from the Link [port name] list — ports already in use are grayed out.
Right-click the target device and choose Link to [port name].
The cable appears on the canvas. If the lab is already running, linking two live VMs triggers an automatic rebuild — Bramble stops, recreates with the new network interface attached, and restarts both endpoints, since Apple’s Virtualization.framework can’t hot-add a NIC to a running VM.

Right-click a cable and choose to remove it if you need to re-wire.

SONiC switches expose 5 port slots; slot N maps to interface Ethernet(N-1)*4 (slot 1 = Ethernet0, slot 2 = Ethernet4, and so on). Linux hosts expose slot N as ethN.

Bundled Presets

The sidebar’s Presets list loads four ready-made topologies with one click, replacing whatever’s currently on the canvas:

Preset	Layout	RAM
2-Node	Two SONiC switches, two parallel links (Ethernet0↔Ethernet0, Ethernet4↔Ethernet4) — good for LAG, ECMP, and basic L2/L3 testing	~4 GB
Leaf-Spine 2x2	2 spines, 2 leaves, full mesh — the classic data-center Clos fabric pattern	~8 GB
Triangle	3 switches in a ring — useful for convergence, failover, and loop-prevention (STP or L3 ECMP) testing	~6 GB
EVPN Multi-Hop	1 spine (route reflector) + 3 leaf VTEPs (VXLAN Tunnel Endpoints) + 3 Linux hosts — a full EVPN (Ethernet VPN) fabric	~9 GB

Auto-Layout

Bramble arranges devices by tier — spines on top, leaves in the middle, hosts on the bottom, inferred from each device’s name — whenever a preset loads or the topology is rebuilt. A single-tier topology (like Triangle) arranges as a polygon instead. You’re free to drag any node afterward to reposition it by hand; auto-layout only runs on load, not continuously.

Topology Lock

When an AI client is connected over MCP (Model Context Protocol — see “Connecting an AI Client” below), the canvas locks against structural edits: you can’t place, delete, or relink devices from the GUI while the LLM is driving. An orange banner reads “Topology locked while the LLM is connected. Ask the LLM to make changes.” Dragging a node to reposition it — a cosmetic change only — still works, and the lock lifts the moment the MCP session disconnects.

Saving and Opening Labs

Bramble labs are documents. From the File menu:

New Topology (⌘N) — clears the canvas
Open Lab… (⌘O) — replaces the canvas with a saved .bramble file
Save (⌘S) / Save As… (⇧⌘S) — writes a .bramble JSON file (devices, links, and the selected protocol config — no VM state) to ~/Documents/Bramble/ by default, or wherever you choose

All four are disabled while a lab is running — stop the lab first. Bramble also auto-saves your in-progress topology roughly once a second to a hidden recovery file, so a crash or unexpected quit doesn’t lose your work; it’s restored automatically the next time you launch.

Containerlab Import and Export

Two toolbar buttons (and matching File-menu items) round-trip topologies with containerlab, a Linux-based lab tool:

Export containerlab YAML (up-arrow icon) — writes a *.clab.yml you can hand to a colleague or run with containerlab deploy on Linux; SONiC nodes get the docker-sonic-vs image and a config-load block. Works even before starting the lab.
Import containerlab YAML (down-arrow icon) — reads a .clab.yml and rebuilds it as a Bramble topology, replacing the canvas. Node positions come from auto-layout, since containerlab files carry no canvas coordinates.

Running a Lab

Start All / Stop All

Click Start All in the toolbar (or the Lab menu, ⌘R) to launch a VM for every device on the canvas, wired according to the cables you’ve drawn. Click Stop All (⌘.) to shut everything down. Clear empties the canvas entirely (only available when the lab isn’t running).

Each device gets a fresh copy-on-write (COW) disk overlay backed by the shared read-only base image — the base image itself is never modified, so you can start and stop labs repeatedly without re-downloading anything. Stopping a lab removes the overlays; starting again creates new ones.

Boot takes about 60–90 seconds — SONiC brings up roughly 15 Docker containers internally on every boot. A device’s status dot turns green the moment it’s reachable over SSH.

Per-VM Power Control

While a lab is running, right-click any device for individual control:

Power On — boots a stopped device, or starts a VM for a device you placed after the lab was already running (a hot-add)
Power Off — stops that one device without touching the rest of the lab
Connect SSH — opens an in-app SSH terminal (enabled once the device is SSH-ready)
Connect Console — opens a serial console terminal

Connect-All

Once the lab is running, two toolbar buttons save you from right-clicking every device individually:

The terminal icon opens a console tab for every device at once
The network icon opens an SSH tab for every device at once (disabled until every device is SSH-ready)

Live Status

Bramble reports two independent live signals while a lab runs:

VM status dots on the canvas and the toolbar’s health chip — green means SSH-reachable, based on real reachability checks, not a timer
Link status — the legend box pinned to the canvas’s top-right corner. Click its refresh arrow to re-check every link’s operational state plus, on SONiC switches, BGP (Border Gateway Protocol) neighbor and LLDP (Link Layer Discovery Protocol) adjacency. Links color green (up with adjacency), yellow (up, no adjacency yet), or red (down).

Default Credentials

Once a device is SSH-ready:

SONiC switches: admin / YourPaSsWoRd
Linux hosts: root / YourPaSsWoRd

Multiple terminal sessions appear as tabs in the Terminal Panel.

Inspecting and Debugging

Terminals

Every SSH and console session lives in the Terminal Panel as its own tab, backed by an in-app terminal emulator (not Terminal.app). If a session shows garbled text or overlapping characters — a known quirk of the SONiC VM’s serial console — close and reopen the tab; it’s a display artifact, not a sign anything is actually broken.

The Inspector Pane

The Inspector sits on the trailing edge of the window, switched by an icon rail. Each tool keeps its own state as you move between them:

Tool	What it shows
Lab Guides	The current hands-on lab’s steps, with a “Check my work” button per step and an “Inject Fault” button for break/fix labs — see “Hands-On Labs” below
DB Inspector	SONiC’s Redis-backed internal databases
Service Health	Which SONiC containers are up, crashed, or still starting
Packet Capture	Live `tcpdump` on any interface, as text or a `.pcap` file

DB Inspector

SONiC’s configuration flows through a pipeline of Redis databases: CONFIG_DB (what you told it to do), APPL_DB (what orchagent applied), STATE_DB (what’s actually operational), and ASIC_DB (what actually got pushed to the switch chip). The DB Inspector loads automatically once you pick a device that’s running — no manual “Load” step required. Select a database, optionally narrow by key pattern, and pick a key to see its full contents. Comparing CONFIG_DB against STATE_DB is the fastest way to tell “I typo’d something” from “the config didn’t propagate.”

Service Health

Runs docker ps -a across every SONiC switch in the lab and reports which containers (bgp, teamd, swss, and the rest of SONiC’s roughly 15 internal services) are running versus crashed, exited, or still starting. Click a container for its recent logs. Linux hosts don’t run SONiC’s containers, so they’re skipped.

Packet Capture

Pick a device and its real guest interface name (Ethernet0 for SONiC, eth1 for a Linux host — check with show interfaces status if you’re not sure). Choose:

Text mode — decoded packet lines shown right in the Inspector, good for a quick sanity check
Pcap mode — a real .pcap file, pulled back over SSH and saved to ~/Library/Containers/com.dendrolabs.bramble/Data/Documents/Bramble/Captures/, ready to open in Wireshark

Both modes accept an optional BPF (Berkeley Packet Filter) expression, e.g. udp port 4789 to isolate VXLAN (Virtual Extensible LAN) traffic.

Hands-On Labs

Bramble ships 23 guided labs, opened from the Lab Guides tab in the Inspector. Each one is self-contained: click Load this lab’s topology to auto-load the right preset, work through numbered steps, and click Check my work on any step to run that step’s real verification check over SSH against your live VMs — the same check the lab’s author wrote, not a simulation. A checkmark tracks completed steps as you go.

Lab	Topic	Preset
1	Getting Started with SONiC	2-Node
2	Hostname Configuration & Reboot	2-Node
3	LLDP Neighbor Verification	2-Node
4	Interface Configuration	2-Node
5	Loopback Interface Configuration	2-Node
6	Routed Physical Interface	2-Node
7	VLAN & SVI (Switch Virtual Interface) Configuration	2-Node
8	PortChannel (LAG) Configuration	2-Node
9	BGP Peering Basics	2-Node
10	BGP Underlay Configuration	Leaf-Spine
11	Leaf-Spine BGP Fabric	Leaf-Spine
12	Network Resilience	Triangle
13	ACL Configuration	2-Node
14	Local SPAN	2-Node
15	ERSPAN (Remote SPAN)	Triangle
16	VXLAN VTEP Configuration	Leaf-Spine
17	EVPN/VXLAN Overlay	2-Node (custom leaf1/leaf2)
18	BGP EVPN Overlay (via Spine)	Leaf-Spine
19	Leaf-to-Leaf EVPN (Direct Peering)	Leaf-Spine
20	L3 VNI Inter-Subnet Routing	Leaf-Spine
21	RFC 5549 — IPv4 NLRI with IPv6 Next Hop	2-Node
22	Break/Fix — Link Down, No Connectivity	2-Node
23	Break/Fix — BGP Session Won’t Establish	2-Node

Labs run 15 to 90 minutes and progress from Beginner (1–6) through Intermediate (7–14) to Advanced (15–21). Labs 22 and 23 are break/fix exercises: instead of building up state step by step, you build a small working setup, click Inject Fault, and diagnose a real injected problem (an admin-down interface, a mismatched BGP AS number) using the same show commands a SONiC support engineer would reach for — nobody tells you what’s wrong up front.

Connecting an AI Client (MCP)

Bramble doubles as an MCP (Model Context Protocol) server — the same lab engine the GUI drives, exposed as tools an AI client can call, so you can ask an assistant to “build me a leaf-spine fabric and start it” instead of clicking through it yourself.

How it works

One binary, two modes. Launched normally, Bramble is the GUI app. Launched as Bramble --mcp-stdio, it’s a headless MCP server speaking over stdin/stdout — no window, no daemon, no port. A few things worth knowing before you set it up:

You don’t start a server. You hand the client a path; it spawns Bramble itself when it needs the tools.
Registration is manual and per-client. Installing Bramble doesn’t register it anywhere — every client you want to drive it from needs its own entry.
It runs headless by default. Ask the client to call show_gui to raise the window and watch the lab live; hide_gui puts it back.
Your license still applies. Starting a lab over MCP goes through the same trial/license check as the GUI — an expired trial stops start_lab rather than quietly working anyway.

Find the binary path

Clients need the executable inside the app bundle, not the .app itself:

/Applications/Bramble.app/Contents/MacOS/Bramble

If you keep Bramble somewhere else, find every copy on the machine:

mdfind "kMDItemFSName == 'Bramble.app'"

Append /Contents/MacOS/Bramble to whichever one you actually run.

Claude Code

claude mcp add bramble -s user -- /Applications/Bramble.app/Contents/MacOS/Bramble --mcp-stdio

-s user registers Bramble for every project; leave it off and it only appears in the directory where you ran the command. Confirm with claude mcp list or /mcp inside a session.

opencode

Edit ~/.config/opencode/opencode.json (all projects) or a project’s opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "bramble": {
      "type": "local",
      "command": ["/Applications/Bramble.app/Contents/MacOS/Bramble", "--mcp-stdio"],
      "enabled": true
    }
  }
}

opencode mcp add walks you through the same thing interactively. Confirm with opencode mcp list.

Cursor

Edit ~/.cursor/mcp.json (all projects) or .cursor/mcp.json in a project:

{
  "mcpServers": {
    "bramble": {
      "command": "/Applications/Bramble.app/Contents/MacOS/Bramble",
      "args": ["--mcp-stdio"]
    }
  }
}

Restart Cursor, then check Cursor Settings (⌘⇧J) → Tools & MCP — bramble should be listed and enabled.

OpenAI Codex CLI

codex mcp add bramble -- /Applications/Bramble.app/Contents/MacOS/Bramble --mcp-stdio

This writes to ~/.codex/config.toml:

[mcp_servers.bramble]
command = "/Applications/Bramble.app/Contents/MacOS/Bramble"
args = ["--mcp-stdio"]

Confirm with codex mcp list, or /mcp inside the Codex TUI. The ChatGPT desktop app shares this config file, so a server added here appears there too.

VS Code

Requires VS Code 1.102+ and a GitHub sign-in for Copilot’s agent mode (the free plan is enough). Run MCP: Add Server from the Command Palette, or hand-edit .vscode/mcp.json:

{
  "servers": {
    "bramble": {
      "type": "stdio",
      "command": "/Applications/Bramble.app/Contents/MacOS/Bramble",
      "args": ["--mcp-stdio"]
    }
  }
}

VS Code asks you to trust the server the first time it starts — confirm, then open the Chat view, switch to Agent, and look for bramble under Configure Tools.

Each client uses a different config file and top-level key — a block copied from one tool’s README into another tool’s file is silently ignored, which is the most common reason setup seems to fail.

The 20 tools

Category	Tools
Topology building	`add_device`, `remove_device`, `link_devices`, `load_preset`, `export_topology`
Lab lifecycle	`start_lab`, `stop_lab`, `power_on`, `power_off`, `wait_for_ready`
Observation & debugging	`list_topology`, `exec_command`, `inspect_db`, `service_health`, `capture_packets`, `link_status`
GUI control	`show_gui`, `hide_gui`, `open_console`, `open_ssh`

A few worth knowing up front: wait_for_ready blocks up to a timeout (default 25s, clamped 5–60s) and returns "still_booting" mid-boot — that’s expected, call it again rather than treating one response as a failure. exec_command needs the target device to already have an IP; call wait_for_ready first. Every SSH-driven tool call is mirrored into an LLM Activity tab in the Terminal Panel, so a human watching the GUI sees exactly what the AI client is doing in real time.

First thing to try

Once connected, ask your client:

Using Bramble, start the 2-node SONiC preset, wait until it’s ready, then show me the topology.

A working setup loads the preset, boots both VMs, polls until ready, and reports devices and links back. Add “and show the GUI” to watch it happen live.

AI Tutor Mode

AI Tutor Mode turns an MCP-connected AI client into a lab coach rather than a lab-solver. It’s a prompting pattern, not a separate feature — it uses the same 20 MCP tools described above.

The model:

You (the student) have Bramble open with an MCP client connected. You type every configuration command yourself, directly into the SSH or console tabs.
The AI loads and boots the lab’s topology, then hands control to you and stops talking.
When you say you’re stuck, or ask it to check your work, the AI reads that step’s real verification check from the lab file, runs the exact same check over MCP, and — if it fails — diagnoses the cause using inspect_db, service_health, link_status, and capture_packets before saying anything to you.
It gives one hint at a time, graded by how many times you’ve already failed that step: a general nudge on the first miss, a named concept or command family on the second, and the literal fix only on the third or later. It never types the fix into your terminal for you — you always run the command yourself.

The AI can raise the GUI (show_gui) or open a console tab for you (open_console/open_ssh), but it never drives your keystrokes. To use it, give an MCP-connected AI client a lab file to read and ask it to tutor you through that lab — it reads the lab’s steps and verification checks the same way the in-app “Check my work” button does.

SONiC Quick Reference

Once you’re connected to a SONiC switch, these are the commands you’ll use constantly.

Show Commands

show version                  # SONiC version, platform, uptime
show interfaces status        # Interface list and link state
show ip interface             # IP addresses on interfaces
show ip route                 # Routing table
show ip bgp summary           # BGP neighbor status
show vlan brief               # VLAN membership
show mac                      # MAC address table
show lldp table                # LLDP neighbor discovery

Configuration (config_db)

# Assign an IP to an interface
sudo config interface ip add Ethernet0 10.0.0.1/31

# Enable an interface
sudo config interface startup Ethernet0

# Create a VLAN and add members
sudo config vlan add 100
sudo config vlan member add 100 Ethernet0

# Save configuration (persists across reboots)
sudo config save -y

FRR / BGP Configuration

FRR (Free Range Routing) is SONiC’s routing daemon suite, configured through its own vtysh shell:

# Enter the FRR shell
vtysh

# Inside vtysh:
configure terminal
router bgp 65001
  bgp router-id 10.0.0.1
  no bgp ebgp-requires-policy
  neighbor 10.0.0.2 remote-as 65002
  address-family ipv4 unicast
    network 10.0.0.0/31
  exit-address-family
exit
write memory

Useful Debugging

show logging                  # System logs
show services                 # Running SONiC services
docker ps                     # Running containers (inside SONiC)
sudo tail -f /var/log/syslog  # Live log stream

Tips and Best Practices

Give SONiC the full 60–90 seconds. It boots roughly 15 Docker containers internally on every launch — a red status dot at 30 seconds is normal, not stuck.
Trust the green dot, not the clock. Status is driven by real SSH reachability checks, so a device that’s slow to boot (a loaded Mac, a cold first boot) just takes longer to turn green — it isn’t a fixed timer.
Right-click is the main interaction on the canvas. Placing devices is click-to-place, but nearly everything else — linking ports, power control, SSH, console, rename, delete — lives in the right-click context menu.
Use the DB Inspector to separate “didn’t configure it” from “configured it wrong.” CONFIG_DB shows what you told SONiC to do; STATE_DB shows what’s actually live. A mismatch between them is a fast diagnosis.
Reach for link_status before assuming a config problem. It tells you in one click whether a link is down at the physical layer before you go hunting through BGP or VLAN config for something that isn’t broken there.
Export to containerlab before you need it, not after. If you’ll want to hand a lab to a colleague on Linux or archive it outside Bramble, export it while it still matches what you built — you can do this even before starting the lab.
Let auto-layout do the first pass, then hand-tune. Loading a preset or building a spine/leaf/host topology from scratch already arranges tiers sensibly; drag individual nodes afterward rather than fighting the initial layout.
Save early on anything you’d hate to rebuild. Auto-save protects against a crash, but a named .bramble file in ~/Documents/Bramble/ is easier to find again than a hidden recovery file.
If you’re pairing with an AI client, watch the LLM Activity tab. It mirrors every SSH-driven command the AI runs in real time, so you can follow along without taking your hands off the keyboard.
Start troubleshooting labs from show interfaces status. Between Admin and Oper state, most “no connectivity” symptoms — including both break/fix labs — resolve in the first command you run.

Troubleshooting

“Could not reach image server” on first launch

Bramble fetches a manifest from cdn.dendrolabs.com before downloading any images — check your internet connection and click Retry
If it persists, use Select Manually… to point Bramble at a sonic-vs.img you already have

“Integrity check failed — download may be corrupt”

The download didn’t match its checksum, usually from a flaky connection on a multi-GB file — click Retry to re-download from scratch
If it fails repeatedly on the same network, try a wired connection or a different network

Setup fails on “Expanding SONiC VS image”

The image needs roughly 5 GB of free space to expand — free up disk space and click Retry
The installer re-downloads and re-expands automatically; a half-expanded file is replaced on its own

“SONiC image not found” when starting a lab

First-launch setup never completed — go through Install Images again, or use Select Manually… if you have your own image

macOS asks to allow “local network” access

Click Allow — Bramble’s VMs run on a private virtual network that handles VM-to-VM and VM-to-Mac traffic (DHCP, SSH, IP discovery), and macOS gates this behind the local-network permission
Without it, VMs boot but Bramble can’t discover their IPs or SSH into them — labs stay stuck on red status indicators
If you dismissed the prompt, re-enable it in System Settings → Privacy & Security → Local Network → Bramble, then relaunch

VMs boot but never go green / SSH connection refused

Confirm Local Network permission is granted (above)
Give it more time — a cold boot or a loaded Mac can run past the normal 60–90 second window
Right-click the device → Connect Console to watch the actual boot output; a device stuck before a login prompt is a real boot problem, not a slow-but-normal one
Check the debug log at ~/Library/Containers/com.dendrolabs.bramble/Data/bramble-debug.log

SSH or console session shows garbled text

The serial console works around known terminal-emulation quirks, and occasionally a burst of boot-time output slips past the filters — close and reopen the tab; it’s a display artifact only

A device’s status or IP looks wrong right after linking two running VMs

Expected — Apple’s Virtualization.framework can’t hot-add a network interface to a running VM, so linking two live devices triggers a full rebuild (stop, recreate with the new link, restart)
Re-check wait_for_ready (or just the status dot) on both endpoints a moment later rather than assuming the link is instantly live

MCP tool calls stall on “still booting” or fail with “no IP yet”

wait_for_ready’s timeout is a per-call budget (default 25s), not a total wait — call it again rather than treating one still_booting response as a failure
exec_command needs the device to already have an IP; call wait_for_ready first

Still stuck?

Check the debug log first: ~/Library/Containers/com.dendrolabs.bramble/Data/bramble-debug.log records VM start, disk clone, IP discovery, hostname application, and SSH-readiness events for every run
You can also filter Console.app for “Bramble”