What the agent has stored, and clearing it

The agent writes down the system changes it makes so it can undo them later. When an unclean shutdown leaves DNS or routes behind, these commands are how you inspect that record and put the machine back.

Connecting changes things outside the agent: the machine's DNS configuration is repointed, routes are added to the routing table, firewall rules and chains are loaded into the kernel. Every one of those changes is written down first, so that disconnecting can undo it.

That record is the state. It lives in one file, and each entry is named after the thing it can undo. Normally you never touch it: the agent replays the cleanup itself on shutdown, and again when it starts, when the device signs in and when it connects. sxaccess store exists for when that did not happen - the machine lost power mid-session, the service was killed, and the tunnel is gone but its DNS settings are not.

The CLI runs on Linux and macOS, so this page is about those.

What is in there

Which entries exist depends on what the machine actually used. On macOS only dns_state, route_state and routeselector_state occur. On Linux the agent uses one of the two firewall backends, so you normally see one of them.

Name	What it can undo
`dns_state`	The DNS configuration the machine had before the tunnel changed it. Absent when `start` ran with `--disable-dns`, or when the agent runs with `SX_USERSPACE_STACK=true`
`route_state`	Routes added to the operating system routing table
`nftables_state`	Firewall rules loaded through nftables, on Linux
`iptables_state`	Firewall rules, routing rules, IP sets and access entries loaded through iptables, on Linux
`routeselector_state`	Which routed networks you chose with `sxaccess reach`. It has no undo step of its own: it is written whenever the selection is applied and stays after a disconnect, so it is normally listed even on a clean machine

Put a machine back after an unclean shutdown

1
Look before you touch anything
store list only reads. It is safe to run at any time, including while connected, and it is the one command here with no consequences. The entries come in no fixed order.

All of these commands talk to the agent, so it has to be running - start it with sudo sxaccess agent start if it is not. Be aware that starting it replays the cleanup as well, so on a machine that recovered on its own the list holds at most routeselector_state. This page is for when it holds more.
shell
```
$ sxaccess store listStates the agent keeps:- dns_state- route_state- iptables_state- routeselector_state
```
2
Disconnect first
Clearing is refused while the device is connected or connecting, and the message tells you what to do: stop the connection before clearing saved state: run 'sxaccess stop'. Disconnect, but leave the agent running: it is the agent that does the work.
shell
```
sxaccess stop
```
3
Reset the whole record
reset --all runs each entry's undo step: DNS is restored, added routes are withdrawn, firewall rules are torn down. Always reset everything rather than one entry at a time - see the warning below for why.

Do not read the message it prints as a tally. The agent counts the entries still in the record afterwards, so a run that undid everything prints Nothing was undone, and Successfully reset 1 states usually means only routeselector_state is left, which has no undo step. If an undo step fails, the command ends with could not undo the recorded changes: could not reset the saved states: … and keeps that entry for another try. Either way, check the machine itself.
shell
```
sxaccess store reset --all
```
4
Check the machine, not the list
An entry whose undo step ran stops appearing in store list, so the list goes quiet whether or not the underlying change was really reversed. Look at the machine itself.

Nothing should still route through the tunnel interface, including routes to any routed networks you had selected, which sit outside the overlay range. No resolver entry should name the overlay's DNS server.

On Linux, ip route show lists the routes and resolvectl status | head -20 the resolvers. On macOS, use netstat -rn -f inet and scutil --dns | head -20.
5
Connect again
Nothing is lost by resetting. The next connect makes the same changes again and writes a fresh record describing them.
shell
```
sxaccess start
```

Reset everything, never one entry at a time

drop removes an entry without running its undo step. Whatever that entry described is left on the machine - DNS still pointing at the tunnel, routes still in the routing table, firewall rules still loaded - and the record needed to remove them is gone. Undoing it then means doing it by hand.

Naming a single entry is the trap, and it is a trap on both commands. sxaccess store reset dns_state runs the undo step for dns_state and then writes the file again with nothing else in it. route_state and the firewall entry are dropped unannounced, without their undo step ever running. routeselector_state goes with them, so the device also forgets the networks you chose with sxaccess reach. sxaccess store drop dns_state does the same and does not even undo the one you named. Both report success for the entry you asked about and say nothing about the ones they took with it.

So the safe habit is reset --all on a disconnected machine. Reach for a single name, or for drop, only when an undo step is itself failing and blocking you - and expect to fix the rest by hand afterwards.

Commands and arguments

reset and drop both want exactly one name or the --all flag (-a), never both and never neither. A bare word all is read as the name of an entry, not as the flag. reset <name> reports success whether or not the entry was in the file, and accepts only the names of entries that have an undo step - routeselector_state is refused. drop <name> accepts any name in the file, and fails with no stored state named … for one that is not there.

Command	What it does
`sxaccess store list`	Name every stored entry. Read-only, safe while connected
`sxaccess store reset --all`	Run every entry's undo step, then clear the record. An entry whose undo step fails stays, and the command reports the failure; `routeselector_state`, which has no undo step, stays too. Needs the device disconnected
`sxaccess store reset <name>`	Undo that one entry, then write the record again without the others - every other entry is dropped without being undone. Needs the device disconnected
`sxaccess store drop --all`	Drop the whole record without undoing anything. The number it reports counts entries that were already cleared, so it can be higher than what `store list` showed. Needs the device disconnected
`sxaccess store drop <name>`	Drop that entry without undoing it, and the rest of the record with it. Needs the device disconnected

Where the file lives

The default identity keeps its record at /var/lib/sxaccess/state.json on Linux and macOS. Any other identity writes <identity>.state.json into a folder for the user who added it, at /var/lib/sxaccess/<username>/<identity>.state.json; the folder name keeps only the letters, digits, _ and - of the user name. SX_STATE_ROOT moves /var/lib/sxaccess, and SX_DNS_STATE_PATH sets the file path outright, for every identity, so check the agent's environment before concluding that a record is missing.

Either way the record follows the identity, not the organization. Two organizations used under one identity share one record, and reset --all covers both.

Deleting the file by hand is the blunt version of drop --all, with the same consequence: nothing gets undone. If a documented reset procedure tells you to remove it, disconnect and reset first.

On macOS, sudo sxaccess uninstall deletes the record in the same blunt way unless you add --keep-data, and it always looks in /var/lib/sxaccess, whatever SX_STATE_ROOT says. If a cleanup may still be pending, run sxaccess stop and sxaccess store reset --all before you uninstall.

Troubleshooting the clientSymptoms, likely cause, and the command that tells them apart.Read more Move a device between organizationsWhy the stored record follows the identity rather than the organization.Read more Command line referenceEvery command and flag the agent takes.Read more

What the agent has stored, and clearing it

What is in there

Put a machine back after an unclean shutdown

Commands and arguments

Where the file lives

Related