# Offline mode

What zn-gate does without network, with an expired or rejected policy, and after an install is revoked. It never runs without a policy.

Source: https://usezn.com/docs/team/offline/

zn-gate applies the organization policy locally, so coding keeps working on a plane or behind a broken proxy. The rule is simple: **a machine never runs without a policy**, and when in doubt it gets stricter, not looser.

| Situation | What zn-gate does |
|---|---|
| No network, cached policy still valid (up to 7 days) | Applies the cached policy. The audit trail stays in `~/.zn/audit.jsonl` and is uploaded when the network is back |
| No network and the cached policy has expired | **Strict mode:** the `deny` rules of the last policy still apply, permissions the organization had opened are withdrawn (the stricter local settings come back), and `zn team status` and the agent hook say so |
| Invalid signature, unknown key or a lower version | Rejects it, keeps the last valid policy and logs `policy:rejected` |
| Install revoked | Stops uploading. Applies the cached policy until it expires, then strict mode. The notice says "removed from org" |
| Clock skew | Up to ±5 minutes of tolerance on the policy's issue and expiry times |
| Gap or replay in the upload | zn resumes from the last record it confirmed. A tampered record is rejected and shows in the dashboard |

## Checking a machine

```bash
zn team status
```

shows the policy version, when it was last checked, whether strict mode is on and how many audit records are waiting to be uploaded. `zn team sync` retries now.

In the dashboard, **Members → Installs** lists each machine with the last time it was seen, so owners and admins can spot installs that are out of date or silent.

## The audit trail is tamper-evident

Each machine chains its audit records with an HMAC (`seq`, `prev`, `mac`). zn uploads them in order and checks the chain, so a missing, reordered or edited record is visible, in the dashboard and in every export.