justinandClaude Opus 5
27799f1154
zerto_recover_file took a dest_dir parameter, built a path from it with no containment check, created that directory, and wrote the recovered bytes there. It also passed the same string to the appliance as initialDownloadPath. On one developer's laptop that reads as "write to my own disk". The moment this server is shared it is an arbitrary write, and a caller-supplied path handed to another system is worse than it looks: a UNC path from a domain-joined appliance is an outbound authentication attempt. The parameter is gone. The destination now comes from config only, so the caller can influence neither where bytes land nor where the ZVM mounts. Returning a path was also useless to a remote caller. A path on this host means nothing on theirs, so the whole recover half of the loop would have quietly stopped working the first time this was hosted. The tool now returns the content: text where it decodes as UTF-8, base64 otherwise, with the byte count and a sha256 so the caller can verify what they got. Files over max_recover_bytes (1 MiB default) are refused and pointed at the whole-VM ladder instead of streamed through a tool result. FLR is for a config file or a dropped directory. Verified live against ZVM 10.9.10: jp-ubuntu returned 158 bytes and ad1 returned 164, both as text with matching content, both sessions unmounted, and dest_dir no longer appears in the advertised tool schema. pytest 51 passed (3 new, including one asserting the parameter set so the caller-supplied destination cannot come back by accident). Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_016yVfC5nvZowoLFnEGWhLGn
zerto-ai-rewind
PoC MCP that makes an agent pin a Zerto tagged checkpoint before it changes a VM, then pull a file back from that tag.
If the loop works, these tools are the delta to add to official ZVM MCP (ZVM.MCP, 10.9). This repo is one MCP process for the demo. It is not a second full ZVM catalog.
What it does
zerto_check_tool— before running anything against a VM:read_only(go),mutating(guard first), orunknown(ask the human whether to checkpoint).zerto_find_protection— VM name, hostname, or vmIdentifier to exactly one VM and every VPG. Zero or two-plus VMs: stop.zerto_create_tagged_checkpoint/zerto_guard_before_mutate— same tag on every protecting VPG, wait until listed. The name records which agent and what it is doing:ai:<agent> | <action> | vm=<vm> | change=<id> | <utc>.zerto_recover_file— FLR after a human setsconfirmed=true. Linux and Windows guest paths. Locally replicated VPGs only: FLR runs at the VPG's recovery site. Reports its own unmount;zerto_list_flr_sessions/zerto_end_flr_sessionfind and reap a mount orphaned by a crashed recovery.- Two catalogs —
mutating_tools(guard first) andread_only_tools(safe). Both cover Linux (ssh,ansible) and Windows (winrm,powershell,smb), and both are illustrative, not exhaustive. A tool in neither is unknown, not safe: ask the human.
Official ZVM MCP already has inventory and failover test. It does not insert tagged checkpoints or run FLR.
Setup
Python 3.12+.
python3 -m venv .venv
source .venv/bin/activate
pip install -e ".[dev]"
cp config.example.json config.json
# edit zerto_url, username, password
Keycloak password-grant, client_id zerto-client on 10.x. Appliance certs are self-signed; verify_tls defaults to false.
stdio MCP (Claude Desktop, VS Code, Cursor, OpenCode):
{
"mcpServers": {
"zerto-rewind": {
"command": "zerto-rewind-mcp",
"env": {
"ZERTO_REWIND_CONFIG": "/absolute/path/to/config.json"
}
}
}
}
Copy skills/zerto-rewind/SKILL.md into the client's skill path.
pytest
Demo
Protected app VM. Agent is about to edit a guest config file.
- Guard: discover VPG set, insert tagged checkpoint, wait.
- Agent writes the bad config.
- Human confirms.
zerto_recover_filefrom that tag.
Git never had the file. RPO is the journal, not last night's backup.
Certified for this PoC
vSphere ZVM 10.x and ZCA on AWS/Azure, same REST paths. HVM is out (separate swagger). Failover Live is not a tool.
Tagged checkpoints do work when the protected site is Azure or AWS. The 9.0 API
reference says they cannot be inserted; that is wrong on 10.9.10, where both were
accepted and the task reached Completed.
What differs is latency and granularity, both set by the protected site:
| protected at | journal gap | tag visible after |
|---|---|---|
| vSphere | 5s | ~4s |
| Azure | 60s | ~34s |
| AWS | 630s | ~128s |
The tagged checkpoint is also stamped about 30s after the insert request, so on a cloud-protected VPG a prompt mutation can land inside the checkpoint meant to precede it. Recover from the newest checkpoint that already existed when the guard ran, not from the tag.
Not this product
Moholo Agent Rewind snapshots the agent's laptop tools. This server uses the Zerto journal as the snapshot store. Do not copy their file blobs.
Upstream
Ask Zerto engineering to add to ZVM.MCP: find-by-unique-VM-with-all-VPGs, tagged checkpoint insert that waits, FLR. Keep VPG settings CRUD where it already is.