Config snapshots and drift
Once a day SZ-MCP reads your controller’s configuration in full and records
which fields changed since the day before. Claude reads those changes with
history.config_changes, any role can, and the config linter checks the same
snapshot. Secrets are never stored, only a digest that changes when the secret
does.
What does a snapshot cover?
Section titled “What does a snapshot cover?”| Kind | Objects | Key |
|---|---|---|
zone | Every zone | zone:… |
wlan | Every WLAN in each zone | wlan:<zone>:<id> |
apgroup | Every AP group in each zone | apgroup:… |
system | Four settings: Syslog server, SNMP agent, System time (NTP), Scheduled backup | config:system/syslog, config:system/snmpAgent, config:system/systemTime, config:system/scheduleBackup |
switchconfig | Each ICX switch’s newest successful SwitchM backup, split into config sections | switch:<MAC> |
The first snapshot is a silent baseline: it records the configuration and reports no changes. A zone the controller refuses to read (SmartZone’s Staging Zone) is skipped.
When is a snapshot taken?
Section titled “When is a snapshot taken?”After the hourly inventory sync, once the last snapshot is 23 hours old. So snapshots start after your organisation’s first inventory sync, and stop while the hourly sync is switched off, failing, or paused after a login failure.
To take one now, ask Claude: history.snapshot_config() needs the engineer
role or above. A viewer or operator gets write_blocked: “Your role (viewer)
can read snapshots but not take one; an engineer or admin can.” It reads about 3
calls per zone plus one per WLAN and AP group, and stops before the code-mode
time limit. Kinds it did not finish are left as they were.
How do I see what changed?
Section titled “How do I see what changed?”Ask Claude, for example “what changed in the Guest WLAN this week?” It uses
history.config_changes:
| Argument | Default | What it does |
|---|---|---|
sinceMinutes | 7 days (at most 180 days) | How far back |
since, until | — | An exact window, in epoch milliseconds |
kind | All | zone, wlan, apgroup, system or switchconfig |
entity | — | One object, or anything under it: a zone gives its WLANs and AP groups |
limit | 100 (at most 1,000) | Changes returned |
Each change is added, removed or changed, with the fields that changed and
their before and after values.
at is when the snapshot saw the change, so it happened some time since the
snapshot before. To find out who made it, Claude reads the
audit log.
history.config({ key }) returns one object as of the last snapshot. With no
key, it returns the snapshot’s status: when it was taken and how many objects of
each kind it holds. An unknown key returns “No config object key in the last
snapshot.”
How are passwords and other secrets stored?
Section titled “How are passwords and other secrets stored?”As a digest, never as the value. A field whose name looks like a secret
(a passphrase, a secret, an SNMP community and similar) is replaced with
digest: and 16 hexadecimal characters before it is stored. The digest is keyed
to your organisation, so nothing recoverable is kept. When a secret is rotated,
its digest changes, so the change still shows up.
How does switch drift work?
Section titled “How does switch drift work?”A switch’s config changes when SwitchM takes a new backup of it, not the
moment the switch changes. Each switch’s newest successful backup is split
into sections, one per top-level line with its indented sub-commands. A change
is reported by section path (sections.<top-level line>) and ver. A switch
whose newest backup is already in the snapshot costs no further reads.
To capture a switch’s current config sooner, take a backup first: see Switch config backup and restore.
How long are changes kept?
Section titled “How long are changes kept?”180 days, at most 50,000 changes, oldest deleted first.