LZLZL/AI toolchain/Access · Risk
FREEMedium · Practice B · Accessaccounts

How accounts die, and
what to back up first

2026-08-21 · The backup list is the part to act on today

This whole stack has one single point of failure: an account. Lose it and everything local still exists but cannot say a word. Causes, backups, and legitimate rerouting — the backup list is the only part that needs action today.

In this pagecommon causes at the terms level, a backup list, legitimate rerouting. Not in this pageevading detection, multi-accounting, working around risk controls. The reason is in §5 and it is not boilerplate.

1Three common causes

Lower your expectations first: most account problems are not "caught doing something bad". They are three lines drawn closer than people picture.

KindTypicalWhy it catches people
Shared accessHanding account access to someone else, or reselling itNearly every terms document forbids sharing and resale — but "sharing with a colleague" feels ordinary
Automation beyond the licenceHigh-frequency unattended calls beyond what that plan permitsSubscription plans and API plans often permit different things — people assume a subscription covers automation
Payment and identityFailed charges, regional restrictions, duplicate signups from one identityThe unluckiest kind: not behaviour, just automated billing and compliance decisions
No specific clauses quoted here

Every vendor words it differently and all of them revise. Copying clauses into this page means they start going stale immediately, and a reader following stale terms is worse off than one following none.

Read the terms of the service you actually use, looking for three words: share, automated, resell. Those three roughly bound whether your usage sits inside the licence.

2Do this today: the backup list

Losing an account is survivable. Losing six months of accumulated state alongside it is not. These live separately from the account, and most people have never backed them up:

Back upWhereCost of losing it
ConfigEach tool's config directory (~/.claude/, ~/.codex/, ~/.hermes/…)Permission rules and provider setup, rebuilt from scratch
Project memoryCLAUDE.md / AGENTS.md in each repoUsually in git — the one category that is safe by default
Custom commands / skillsTool user directoryHurts more the longer you have run; rarely version-controlled
Tool wiring (MCP etc.)Server list in configReconnecting means re-reading a lot of docs
Session historyThe tool's local session store"How did I solve this last time" — gone
Key inventoryList what exists and where to reissue. Never the valuesKnowing which credentials to re-obtain
How, in one line

Fold those config directories into whatever backup you already run — time machine, sync folder, private repo — excluding the file that holds secrets. Most tools deliberately keep keys in a separate .env-style file precisely so the rest is safe to copy.

Confirm which file that is before you back anything up. The Hermes page gives a concrete case: settings in config.yaml, keys in .env, split on purpose.

3Afterwards: what a legitimate switch looks like

"Rerouting" has exactly one honest meaning: moving to a provider you legitimately have access to. Not a new identity at the same one.

The good news is that it is technically cheap, because these clients speak a protocol, not a vendor — switching is an endpoint and a key. That is all of the next page.

ChangeCost
Endpoint + keyOne config edit
Model nameOne config edit, but re-learn the feel — models answer the same prompt differently
Protocol differencesThis is the real cost. Some endpoints support only one request shape and something breaks. Page 7 §4

4Better posture: prepare before it happens

DoWhy
Keep the endpoint a config value, never hard-codedSwitching becomes one line, not a search across a codebase
Keep one alternate path you could switch to nowYou do not need to use it. You need to have switched to it once and seen it work
Actually switch, occasionallyAn unrehearsed fallback is not a fallback. Old ops truism, still true here
Do not hang critical work on a single accountSee page 21 — plan for a long-running service going dark

5Why there is no "how not to get caught" here

Plainly: not a moral pose. Two pieces of arithmetic.

One. That content has negative expected value for the reader. Evasion techniques have a half-life measured in weeks; a web page gets read for years. Following a stale evasion guide is more dangerous than doing nothing.

Two. The very next page covers relay endpoints — a completely legitimate engineering technique, and a different thing entirely from wearing a new mask. If this page taught the latter, the next page gets read as the same category. That trade is far too expensive.

Cause categories Generalised from clause types that appear across vendors' terms (sharing/resale, automation licensing, payment and identity compliance). No individual vendor's clause is quoted — terms differ and change. Read the ones that apply to you.
Backup list Derived from the config layouts of the tools in this thread; config and secrets are usually in separate files (e.g. Hermes uses ~/.hermes/config.yaml and ~/.hermes/.env, checked 2026-08-21). Confirm which file holds secrets in your own tools first.
Explicitly absent Any method for evading detection, running multiple accounts, or bypassing risk controls.
Not in this page Which accounts or providers I use, or where my backups live.

RelatedRead next

B · Access
What a relay API actually is
B · Access
Four clients, four places to put the endpoint
B · Access
Where the tokens actually go
D · Cloud
Key isolation, monitoring, backups, knowing when to switch it off
An educational and engineering record — not a review or endorsement of any third-party product. Commands, config keys, prices and terms are per each vendor's official docs; this page states when it was checked and all of them can change without notice — verify before you copy anything. Self-hosting is your own responsibility: keys, accounts and data are on you.