Project

Tsunami

Network Automation for Windows · Open Source · v0.5.0

A Windows desktop tool that pushes templated Cisco IOS/IOS-XE and HPE Aruba AOS-S/AOS-CX configuration to up to 200 devices over SSH or serial console. It has a GUI for people and a local MCP server for Claude. Claude can read inventory, draft plays, render templates and run read-only checks. It never sees credentials or secret values, and changes to customer devices need approval in the GUI.

What it does

• Plays from a GUI. Pick a play, pick targets, fill in prompts, preview the rendered config per device, then push.
• Three play types on one engine: initial (day-0), push (ad-hoc change), and baseline (a per-customer standard config).
• Layered variables across global, role, customer, site, device, play and prompt levels, with typed, validated prompts and the source of every value shown.
• Safe fleet pushes: every change is diffed against the running config, then pushed with a canary device, batches with a failure limit, pre-change backups, pre and post checks, and automatic rollback.
• Drift reporting: compare running config to a customer baseline without pushing anything.
• SSH or serial console, including day-0 setup over the console. Older switches that only offer SHA-1 SSH algorithms are reached through an automatic fallback.

Built for Windows

• Runs natively on Windows 10 and 11. No WSL, Docker, Linux VM, or separately installed Python.
• Ships as a per-user installer that needs no admin rights.
• Device logins and secrets live only in Windows Credential Manager, encrypted under a Tsunami password. They never appear in YAML, git, logs, the job database, or MCP output.
• The GUI is laid out like VS Code, with a command palette, quick open, tabbed views, and a Problems panel. VS Code stays the editor for the YAML and Jinja workspace, which is a plain git repo.

Claude, with guardrails

The MCP server exposes 18 tools in three tiers. Tier 0 touches only the workspace: reading inventory and plays, validating, rendering with secrets masked, and writing drafts. Tier 1 contacts devices read-only, for check-mode diffs, compliance reports, and allowlisted show commands. Tier 2 requests changes.

• The relay holds no secrets. tsunami-mcp.exe relays each tool call over a local named pipe to the GUI, which runs it only while Tsunami is unlocked.
• One redactor sits on every outbound string, verified by a dedicated secret-leak test suite.
• Claude writes only drafts. Drafts never reach a customer device until a person promotes them, and the policy file lives outside the workspace, so Claude can't edit its own permissions.
• Device output is untrusted. It comes back in a field named untrusted_device_output, and the approval gate covers prompt injection from banners or descriptions.

Approval flow

1. Claude requests a run of an approved play against chosen targets.
2. Tsunami renders every target and runs a check-mode diff. Devices that would change are marked ready; if none would, nobody is asked to approve.
3. The GUI shows an approval card with the play, targets, prompts, and each device's masked render and diff.
4. A person approves or denies. Approval records their Windows username and the time.
5. The job runs through the normal pipeline, with canary, backups, and rollback.
6. Each device is re-rendered at run time. If the play or the render changed since approval, that device fails instead of pushing content nobody approved.

Lab customers are the exception: when the policy allows it, Claude can run plays against them without a click per run, so it can iterate against a CML lab.

Architecture

Tested platforms

Testing and CI

About 2,470 unit and 170 GUI tests. Every push to main runs GitHub Actions on Windows: lint, unit and GUI tests, then a frozen build with self-tests, an MCP smoke test, and the installer. Integration tests run against a CML lab or a real COM port.

Stack: Python 3.12, PySide6, Netmiko, Jinja2 (sandboxed), Pydantic v2, ruamel.yaml, keyring, the MCP Python SDK, PyInstaller, and Inno Setup.