indelible-mcp 5.8.7 → 5.8.9

package/AI_OPERATORS_HANDBOOK.md

@@ -4,7 +4,7 @@
 it well — how to hold goals honestly, and how to leave proof on chain that survives you.
 
 **© 2026 Indelible Federation.** Written and verified by Indelible's QA process · **2026-08-16** · built
-against `indelible-mcp@5.7.6`, re-verified claim-by-claim against `indelible-mcp@5.7.7` (see Rev 4), **audited claim-by-claim again against `indelible-mcp@5.8.3`** on 2026-08-18, and **re-verified claim-by-claim on 2026-08-25** against the then-unreleased build (Rev 5 — every checkable behavior held; that build was never published, so no release carries the number it was staged under), then **re-measured against this bundle on 2026-09-10** (Rev 6 — all five machine-to-machine `drift` verbs, `arm`/`serve`/`calibrate`/`heal`/`note`, are in this bundle; Part 12 names `arm` and `serve` in its ships-today table, and none of the five is documented in detail here).
+against `indelible-mcp@5.7.6`, re-verified claim-by-claim against `indelible-mcp@5.7.7` (see Rev 4), **audited claim-by-claim again against `indelible-mcp@5.8.3`** on 2026-08-18, and **re-verified claim-by-claim on 2026-08-25** against the then-unreleased build (Rev 5 — every checkable behavior held; that build was never published, so no release carries the number it was staged under), then **re-measured against this bundle on 2026-09-10** (Rev 6 — all five machine-to-machine `drift` verbs, `arm`/`serve`/`calibrate`/`heal`/`note`, are in this bundle; Part 12 names `arm` and `serve` in its ships-today table, and none of the five is documented in detail here), then **re-measured against `indelible-mcp@5.8.8` on 2026-09-26** (Rev 7 — the wallet-file race is closed at one chokepoint, `wallet_unlock_journal` is served, project restores are confined to their output folder, `tools/list` answers 36 on a fresh home against 5.8.7's 35, and the two held rows in 12.1 are still absent from the list; see 10.1 for the two refusals an assistant now has to know), then **re-measured against `indelible-mcp@5.8.9` on 2026-09-26** (Rev 8 — the "no usable wallet" refusal is now derived from the wallet file's state and never says "run setup" over an emptied file; `wallet --store-pin` exists for a key whose PIN is not on the machine; the wallet file keeps its own backup, `config.json.bak.1`; `--help` lists `wallet`; 36 tools, none added; see 10.1).
 Every rule here comes from something that actually happened on a real box, not from reading the docs.
 
 **Rev 2 — peer-reviewed.** Draft 1 (`5c3f10c3…` on chain) was sent over the Drift Wire to an independent
@@ -48,7 +48,7 @@ by adversarial review, not by re-reading my own work. That is the method working
 
 **Rev 6 — the machine-to-machine system added, by a different seat, and the version line drawn honestly.** Part 12 is new: the wire two machines talk over, the standing grant that gives them one memory, the four disciplines each learned from a specific failure, and the seat model that made the review of this product work. It was written by the **builder seat**, not by the QA machine that wrote everything above it, and it has not yet been through the adversarial pass the rest of this document survived; treat its claims accordingly until that review lands.
 
-**The version line is the part to read carefully, and measuring it turned up a third generation nobody had named.** The wire, the named seats, `drift arm` and `drift serve` are in THIS bundle. The three pieces that make two machines share one memory need to be told apart, because they are **not in the same state** and an earlier revision of this paragraph got all three wrong at once. Re-measured 2026-09-10 against this bundle, by counting them in `src/index.js` rather than recalling them: the **standing grant** (`pair_machine`) and the **catch-up read** (`catch_up`) ARE in this bundle, but they are **HELD** — deliberately filtered out of `tools/list`, so they are present in the bytes but **not advertised** — nothing on the customer surface tells an operator they exist, though a caller that already knows the name still reaches the handler (the filter is on the listing, not the dispatch). A **shared save returning its messages rather than only its title** IS here and IS callable. So one of the three works for you today and two are shipped-but-closed; none of them "exists only in the build tree", which is what this paragraph used to say. ⚠️ That correction matters more than the fact: the old wording under-sold a capability that actually shipped, in the one document that tells you not to trust unverified claims. This package is **5.8.5**; run `npm view indelible-mcp version` yourself rather than trusting this sentence, because it is the one line here that goes stale on every release. Once this publishes, two of those artifacts collapse into one and a reader has two left to keep straight — what this package carries, and what the machines actually run. A handbook that sold the third as available would be doing the exact thing Rev 4 was corrected for, pointed the other way. Run the command and read the refusal before you promise any of it to a person.
+**The version line is the part to read carefully, and measuring it turned up a third generation nobody had named.** The wire, the named seats, `drift arm` and `drift serve` are in THIS bundle. The three pieces that make two machines share one memory need to be told apart, because they are **not in the same state** and an earlier revision of this paragraph got all three wrong at once. Re-measured 2026-09-10 against this bundle, by counting them in `src/index.js` rather than recalling them: the **standing grant** (`pair_machine`) and the **catch-up read** (`catch_up`) ARE in this bundle, but they are **HELD** — deliberately filtered out of `tools/list`, so they are present in the bytes but **not advertised** — nothing on the customer surface tells an operator they exist, though a caller that already knows the name still reaches the handler (the filter is on the listing, not the dispatch). A **shared save returning its messages rather than only its title** IS here and IS callable. So one of the three works for you today and two are shipped-but-closed; none of them "exists only in the build tree", which is what this paragraph used to say. ⚠️ That correction matters more than the fact: the old wording under-sold a capability that actually shipped, in the one document that tells you not to trust unverified claims. This package is **5.8.9** (the held rows were re-checked against the 5.8.8 bundle's `tools/list` on 2026-09-26 and are still held; 5.8.9 adds no tool); run `npm view indelible-mcp version` yourself rather than trusting this sentence, because it is the one line here that goes stale on every release. Once this publishes, two of those artifacts collapse into one and a reader has two left to keep straight — what this package carries, and what the machines actually run. A handbook that sold the third as available would be doing the exact thing Rev 4 was corrected for, pointed the other way. Run the command and read the refusal before you promise any of it to a person.
 
 ---
 
@@ -803,6 +803,12 @@ already running is still the old code, so the strongbox tools will not appear un
 restarted. If someone says they just updated and you cannot see `strongbox_status`, that is the reason:
 tell them to quit and reopen their assistant. Do not tell them the feature is missing.
 
+**The save journal lock, and the door added in 5.8.8.** Every broadcast on a machine goes through one save journal, and a process that dies while holding its lock leaves every later save on that machine waiting; the refusal reads *"a previous Indelible process stopped while holding the save journal lock, so saves on this computer are paused for safety"*. That is a safety stop, not a bug: two writers on one wallet is the double-spend class this product has paid for before. The door is `wallet_unlock_journal` (or, at a terminal, `indelible-mcp wallet --unlock-journal`). It clears the lock only after proving the process that held it is gone; if a save is genuinely in progress it says so and clears nothing, and with no lock held it says "Nothing to clear". Call it when the customer reports that refusal, tell them what it found, and do not retry the save until it reports the lock cleared.
+
+**The wallet file is written all-or-nothing from 5.8.8, and two refusals are new.** Before this release a read of `~/.indelible/config.json` that landed mid-write could come back empty and be written back over the wallet key; the path is closed (temp file swapped into place; on Windows and Linux one lock across every Indelible process on the machine; on macOS the atomic write and the refusals without the lock, so concurrent processes there are still the operator's problem to avoid). `CONFIG_UNREADABLE` means the file exists and could not be read or parsed, and **nothing was changed**: if it is the wallet file, the customer restores it from their backup, and you never let a save, a setup or a settings change rewrite it first. `CONFIG_BUSY` means another program holds it open (Windows); close that program and retry. Neither is permission to run setup again; setup on a machine that already has a wallet refuses ("Wallet already configured" up front, and `WALLET_ALREADY_CONFIGURED` from inside the lock if a key appears while it is running) and that refusal is the protection.
+
+**From 5.8.9 the "no usable wallet" refusal says which of four things is true, and you act on the code, never on the old hedge.** Every save and load used to answer "Wallet not configured or PIN incorrect. Run setup_wallet first." whatever had happened; two customers followed that sentence toward setting up over an emptied wallet file; setup only ever imports a key, so the danger there is a DIFFERENT key, which leaves every old save locked to the one that is gone. The result now carries a `code`: `WALLET_NO_CONFIG` (no file at all: setup is right only for a machine that never had a wallet; a machine that did restores instead), `WALLET_MISSING_FROM_CONFIG` (the file is there and the key is gone from it, the wiped shape: **never a new key**; copy `~/.indelible/config.json.bak.1` over it when the message names that copy, else the customer's own backup, which also brings back the saved-session history; with no backup, the SAME account's key from indelible.one Settings → Private Key brought back in through setup, which imports it), `WALLET_PIN_UNAVAILABLE` (the key is there, the PIN is not on this machine: the moved-machine shape; `indelible-mcp wallet --store-pin` at a terminal, or `INDELIBLE_PIN` in the environment) `WALLET_KEY_DAMAGED` (the key field is present but not in the form the software writes, so the PIN was never judged: restore, never a new key) and `WALLET_PIN_INCORRECT` (a PIN was found and did not open the key, which means a wrong PIN OR damaged key data; a failed decryption cannot tell those apart, and the sentence says so). The same sentence comes back from `indelible-mcp status`, which now exits 1 when it cannot find a wallet. The wallet file also keeps its own copies from 5.8.9 (`config.json.bak.1`, `.bak.2`, taken under the same lock before a keyed write when the key changed or the newest copy is an hour old); they hold whatever the file holds, the encrypted key or, on an old-style config, a plaintext one, in the same folder with that folder's default permissions, so treat them with the same care as the file and never paste their contents anywhere.
+
 Auto-save is your seatbelt. The daily MD is your actually-arriving-somewhere.
 
 ## 10.2 Bank at milestones, not at the end
@@ -993,7 +999,7 @@ This is the first thing to establish, because the rest is useless if you tell a
 | **`pair_machine`** — the standing grant, so every save shares itself automatically | **held for 6.0.0.** Deliberately not on the customer surface yet |
 | **`catch_up`** — read everything a machine has shared since last time, in order | **held for 6.0.0** |
 
-Measured against this bundle on 2026-09-10, not recalled.
+Measured against this bundle on 2026-09-10, not recalled; re-checked on the 5.8.8 bundle on 2026-09-26 (36 tools listed on a fresh home, the two held rows still absent, `wallet_unlock_journal` present); 5.8.9 adds no tool and removes none (the bundle certifies at 36).
 
 The `load_shared` row moved. In 5.8.3 that tool decrypted a share and handed back a summary of up to 2000 characters, never the message content, and it reported `message_count` as the **whole conversation's** total — so a 19-message share was announced to the receiving machine as 34,558 messages. This bundle returns the messages, discloses `shared_unit` so you can see that what was granted is one save rather than a conversation, splits the count into the shared unit's own and `conversation_message_count` beside it, and stamps `from_verified` so a caller stops inferring trust from the word `ok`.
 

package/CLI_HANDBOOK.md

@@ -2,7 +2,7 @@
 
 ## The Command Card — the everyday commands in plain words
 
-*(Not exhaustive — 5.8.5 adds the machine-to-machine `drift` verbs; `agents`, `keys`, and `semantic-fetch` shipped in earlier releases. Run `indelible-mcp --help` any time to see the full, current roster.)*
+*(Not exhaustive — 5.8.9 adds `wallet --store-pin` and the wallet file's own backup; 5.8.8 added `wallet --unlock-journal`; 5.8.5 added the machine-to-machine `drift` verbs; `agents`, `keys`, and `semantic-fetch` shipped in earlier releases. Run `indelible-mcp --help` any time to see the roster; from 5.8.9 the `wallet` verb is listed there.)*
 
 You don't have to memorize any of this. In Claude Code you can just say what you want ("save this session", "post that to the drift wire", "read the wire") and your AI runs the command for you. This card is for when you want to type it yourself — one line each, no jargon.
 
@@ -10,6 +10,9 @@ You don't have to memorize any of this. In Claude Code you can just say what you
 |---|---|
 | `indelible-mcp status` | Shows your wallet address, your API key presence, and (from 5.8.5) whether your installed version is behind the latest. It does NOT tell you whether saves are reaching the chain — for that, verify a save's txid in the Chain Browser at indelible.one/explorer. |
 | `indelible-mcp save --summary "note"` | Saves your newest session transcript to the blockchain, forever. Works from 5.8.5 — older releases refused with "Transcript not found". |
+| `indelible-mcp wallet` | Shows whether anything on this computer is holding your wallet's coins or its save journal lock right now. "The wallet is idle" means neither. |
+| `indelible-mcp wallet --unlock-journal` | Clears a save journal lock left behind by an Indelible process that died, and only after proving that process is gone (5.8.8). Safe to run any time: with nothing to clear it says "Nothing to clear". Your assistant can do the same through the `wallet_unlock_journal` tool. |
+| `indelible-mcp wallet --store-pin` | Puts this wallet's PIN back into your computer's keychain (5.8.9). You type the PIN once at a prompt that shows nothing while you type (the prompt line itself stays visible); it is checked against your key before anything is stored, and a wrong PIN stores nothing. This is the fix when saves say `WALLET_PIN_UNAVAILABLE`, which is what happens after you move Indelible to a new computer or user account: the key came along in `config.json`, the PIN did not. |
 | `indelible-mcp load` | Pulls your recent saved memory back down. |
 | `indelible-mcp map` | Draws a 3D map of everything you've ever worked on. |
 | `indelible-mcp drift read` | Shows the conversation between your AIs. |
@@ -25,7 +28,7 @@ You don't have to memorize any of this. In Claude Code you can just say what you
 | `indelible-mcp vault load-file <txid>` | Gets it back, anywhere, forever. |
 | `indelible-mcp diary chat "hello"` | Talks to your diary companion. |
 
-Three things worth knowing, once: **you hold your key** (it lives in `~/.indelible/config.json` on your machine — back that file up) · **reading is always free; saving to the blockchain is a Pro feature** (the Bitcoin fee itself is fractions of a cent) · **your stop button beats everything** (pause works even with no wallet at all).
+Three things worth knowing, once: **you hold your key** (it lives in `~/.indelible/config.json` on your machine — back that file up; from 5.8.9 the software also keeps two copies beside it, `config.json.bak.1` and `.bak.2`, and names them when the key is missing) · **reading is always free; saving to the blockchain is a Pro feature** (the Bitcoin fee itself is fractions of a cent) · **your stop button beats everything** (pause works even with no wallet at all).
 
 ## Honest Receipts + the Wallet (5.7.0)
 
@@ -214,6 +217,9 @@ save --summary "note"        Save with custom summary
 load                         Load context from blockchain (default: 5 sessions)
 load --sessions=10           Load N sessions
 status                       Show wallet address, API key, last session
+wallet                       Show what is holding your coins or the save journal lock (idle = nothing)
+wallet --unlock-journal      Clear a save journal lock whose holder is proven gone (5.8.8+)
+wallet --store-pin           Put this wallet's PIN back in the OS keychain; nothing shows while you type, checked first (5.8.9+)
 ```
 
 ### Code Vault
@@ -359,6 +365,16 @@ This creates a standalone `indelible.exe` — no Node.js required on the target
 | `txn-mempool-conflict` | Spending already-spent UTXO | UTXO chaining should prevent this — check code |
 | `<provider> rate limit exceeded` | Too many diary chat calls (the message names the provider: Groq, xAI Grok, or OpenAI) | Wait a moment and retry |
 | `Diary AI needs a companion model` | No companion key connected on this box (the keyless free Groq companion lives at indelible.one, not in the CLI) | Use the free companion at indelible.one, or upgrade here with `diary connect --key=...` using an xAI (`xai-...`) or OpenAI (`sk-...`) key — Groq (`gsk_`) keys are refused since Groq is already the free default |
+| `saves on this computer are paused for safety` (the save journal lock) | An Indelible process stopped while holding the save journal lock, so every save on this machine waits rather than risk two writers on one wallet (5.8.8) | Run `indelible-mcp wallet --unlock-journal`, or ask your assistant to use `wallet_unlock_journal`. It clears the lock only after proving the process that held it is gone; if a save is genuinely in progress it says so and clears nothing |
+| `CONFIG_UNREADABLE` | `~/.indelible/config.json` exists but could not be read or parsed. Nothing was changed (5.8.8; before this release a failed read could be written back as an empty file over your key) | If it is your wallet file, restore it from your backup, or from `config.json.bak.1` beside it (5.8.9 keeps that copy; the message names it when it holds your key). Do not let anything rewrite the file first, and do not set the machine up with a new key. If you have no backup, contact support at indeliblebsv@gmail.com before touching the file |
+| `WALLET_MISSING_FROM_CONFIG` | Your wallet file is there but the wallet is gone from it: `~/.indelible/config.json` holds no key (5.8.9; before this release the message here was "Wallet not configured or PIN incorrect. Run setup_wallet first.", which sent people the wrong way) | Do NOT set this machine up with a new key: your saves stay locked to the old one. Copy `config.json.bak.1` over `config.json` if the message names it, or restore the file from your own backup; either brings back your key AND your saved-session history. With no backup, sign in at indelible.one with the SAME account, copy your key from Settings → Private Key, and bring it back in with `indelible-mcp` (it imports that key; it never makes one). Then restart whatever runs Indelible |
+| `WALLET_NO_CONFIG` | There is no `~/.indelible/config.json` on this machine at all (5.8.9) | If this machine never had an Indelible wallet, run `indelible-mcp` and set up. If it did have one, do not set it up with a new key: restore the file from your backup, or bring the SAME account's key back from indelible.one Settings → Private Key through `indelible-mcp` |
+| `WALLET_PIN_UNAVAILABLE` | Your key is in the file but its PIN is not on this machine: nothing in the keychain for this wallet and no `INDELIBLE_PIN` (5.8.9). This is what happens after Indelible is moved to a new computer or user account, or when a Linux keyring is locked | Run `indelible-mcp wallet --store-pin` in a terminal and type the PIN once. Or set `INDELIBLE_PIN` in the environment of the program that runs Indelible. Setup would refuse ("Wallet already configured"), and that refusal is right |
+| `WALLET_PIN_INCORRECT` | The key is in place and the PIN this program has (keychain or `INDELIBLE_PIN`) did not open it: either the PIN is wrong, or the encrypted key data in the file is damaged, and a failed decryption cannot tell those apart (5.8.9; before this release the same words covered a wiped file too) | If you know the PIN is right, restore the file from your backup or from `config.json.bak.1`. If you may have the wrong PIN stored, store the right one with `indelible-mcp wallet --store-pin`. Never a new key |
+| `WALLET_KEY_DAMAGED` | The key field in `~/.indelible/config.json` is there but not in the form Indelible writes (a part missing, empty, or the wrong type), so no PIN could open it and the PIN was not judged at all (5.8.9) | Do not set the machine up with a new key. Restore the file from `config.json.bak.1` when the message names it, or from your own backup, or bring the SAME account's key back from indelible.one Settings → Private Key through `indelible-mcp` |
+| `CONFIG_BUSY` | `~/.indelible/config.json` is open in another program that does not share it (Windows). Nothing was changed | Close the other program (an editor, a sync client) and retry |
+| `CONFIG_WOULD_DROP_KEY` | A settings write would have removed the wallet key from a file that holds one, and was refused. Nothing was written | Nothing to do; the refusal is the protection. If it repeats, contact support at indeliblebsv@gmail.com |
+| `RESTORE_PATH_ESCAPES` (in a project restore's error list) | A saved project contains a path that would land outside the folder you asked the restore to use (an absolute path, a `..` climb, or a link out). That file is not written (5.8.8) | Restore into an empty folder you chose; the files that fit inside it restore, the ones that would escape are listed in the result's errors and skipped |
 
 ---
 
@@ -381,6 +397,12 @@ This creates a standalone `indelible.exe` — no Node.js required on the target
 | `last_tx_id` | *(auto)* Last committed tx |
 | `diary` | `{ apiKey, provider, model, name }` — companion config (xAI `xai-...` or OpenAI `sk-...` key; Groq is the keyless free default) |
 
+**How this file is written (5.8.8).** Every write is all-or-nothing: a temp file is written and fsynced, then swapped into place, so a crash mid-write leaves the old file intact. On Windows and Linux every Indelible process on the machine takes one lock before it reads, changes and writes this file, so two saves can no longer interleave. A write that cannot read the file refuses (`CONFIG_UNREADABLE`, `CONFIG_BUSY`) instead of treating an unreadable file as an empty one, which is how a wallet key could be lost before this release. On macOS the all-or-nothing write and the refusals apply, but concurrent Indelible processes are not yet serialized there; run one at a time. None of this replaces a backup of the file.
+
+**How this file is backed up (5.8.9).** Before a write over a file that holds a key, the software copies the file as it is to `~/.indelible/config.json.bak.1`, moving the previous copy to `.bak.2`. It does this when no copy with a key exists yet, when the key in the file differs from the copy's, or when the newest copy is more than an hour old; it never makes a copy from a file that has no key in it (that is the emptied shape, and copying it would overwrite the good copy). The copies hold exactly what `config.json` holds: your key encrypted under your PIN, or, on an old-style config that still keeps a plaintext `wif`, that plaintext key copied as it is. They sit in the same folder with that folder's default permissions (on Windows, the folder's inherited permissions, which need not match a permission you set on `config.json` by hand), so treat the folder as you treat the file. A copy that cannot be made is reported on the error output and never stops the write; a copy left half-written by a crash is removed by the next write. To restore: copy `config.json.bak.1` over `config.json` and restart whatever runs Indelible; you may lose a little bookkeeping (the next save may re-send messages the copy did not know about), never your key.
+
+**The PIN, and moving Indelible to a new computer (5.8.9).** Your PIN is not in this file. It lives in your computer's keychain (Windows Credential Manager, macOS Keychain, the Linux keyring) under your wallet address, or in the `INDELIBLE_PIN` environment variable of the program that runs Indelible. So if you copy `config.json` to a new computer or a new user account, the key comes along and the PIN does not: every save answers `WALLET_PIN_UNAVAILABLE`, and setup refuses because the wallet is already there. The fix is `indelible-mcp wallet --store-pin` on the new machine, typed once at a prompt that shows nothing while you type, or `INDELIBLE_PIN` in the environment. One more thing about a second computer: run Indelible on **one** of them at a time with the same wallet. Two machines saving from one wallet pick the same coins and fight over them, and saves fail on both. Pairing two machines properly, each with its own wallet, is the machine-to-machine work; until it ships, stop Indelible on the old computer when you start it on the new one.
+
 ---
 
 ## Wallet

package/CUSTOMER_AGENT_HANDBOOK.md

@@ -19,7 +19,7 @@ Your day-one roster is small and real: two guards, one companion, and one memory
 
 That is the whole list **for this package**. Your agent crew is a different thing and it lives in the web app: sign in at indelible.one, open the Sanctuary, and birth sixteen agents derived from your own wallet. They are yours today, not a preview. Section 7 walks through it, and section 8 is honest about the two parts that are still unfinished.
 
-### The 32 tools you can call today
+### The 36 tools you can call today
 
 Grouped by what they cost:
 
@@ -33,6 +33,8 @@ Grouped by what they cost:
 - **Starter recipes (free):** `list_agent_recipes` — eight ready-made blueprints you can hire instead of writing one from a blank page: a copy chief, a researcher, a deal reviewer, a code critic, a devil's advocate, a marshal, a ledger clerk, a negotiator. Birth any of them with `birth_custom_agent` and `recipe: '<id>'`. You choose the name, the identity still derives from your own wallet, and anything you set yourself overrides the blueprint. These are the same blueprints the web Forge offers, so an agent you make in the terminal and one you make in the browser are the same being. (Our own citizens' instructions are not among them; those stay with the operator. What travels is a recipe, never a key.)
 - **Your own agents (free, local):** `birth_custom_agent` — create an agent of your own: name it, pick the kind of work it handles, write its instructions. Its identity derives from your wallet, so it is recoverable from that wallet forever and is never random. · `run_custom_agent` — run one and get back advice signed with that agent's own key, so anyone can verify which agent said it. · `convene_chamber` — put three of your agents in a room to decide something: one proposes, one argues against, a third rules, and each signs its own position. · `transmute_agents` — blend two of your agents into a third. Keys never mix; only the written instructions combine.
 - **Sharing:** `share_session` (send one of your saved sessions to another address — Pro, it is a real on-chain write) · `load_shared` (read what someone shared with you — free)
+- **Strongbox (free, local):** `strongbox_status` looks at what your own machine is holding · `strongbox_consent` records your yes · `strongbox_clean` acts, and refuses unless your yes was recorded first (section 2 explains what "safe to remove" means)
+- **Wallet (free, local):** `wallet_unlock_journal` — clears a save journal lock left behind by an Indelible process that died, and only after proving that process is gone. If a save ever says saves on this computer are paused for safety, this is the tool your assistant uses; nothing else is touched, and with nothing to clear it says so
 - **Everything else:** `x402_fetch` (pays real sats to paid endpoints, capped at 10,000 sats per request unless you raise it), `report_bug`
 
 One important nuance on "free": free means no subscription. On-chain writes still cost miner fees, paid in sats from your own wallet. Each save costs less than a cent. Diary and Duo saves are not Pro-gated; they only need a few sats in the wallet.
@@ -71,6 +73,10 @@ removed.) This is what each one does and why it is there.
 
 ⚠️ **Just updated? Restart your assistant before you ask.** Quit and reopen whatever app you run Indelible in — Claude Desktop, Claude Code, Cursor, or any other MCP client. It reads the list of things it can do once, when it starts, so if you updated while it was running it is still holding the old list and will tell you the cleanup does not exist. Restart, then ask again.
 
+**Your wallet file is safer from 5.8.8, and still worth backing up.** The file that holds your key, `~/.indelible/config.json`, used to be rewritten in place on every settings save, so two saves landing at the wrong moment could leave it empty. Now every write of it is all-or-nothing, on Windows and Linux every Indelible process on your machine takes a lock before writing it, and a write that cannot read the file stops and says so (`CONFIG_UNREADABLE`, `CONFIG_BUSY`) rather than writing an empty file over your key. On a Mac the all-or-nothing write is there but two Indelible processes at the same instant are not yet held apart, so run one at a time. If you ever see `CONFIG_UNREADABLE` on that file, restore it from your backup before anything else touches it. Keep the backup; no software makes a lost key recoverable.
+
+**From 5.8.9 the file keeps its own copies, and the message tells you the truth.** Before a write over that file, Indelible keeps a copy beside it, `config.json.bak.1` (and `.bak.2` behind it), refreshed when your key changes or once an hour. The copies hold what the file holds, so keep that folder as private as the file. If the key is ever gone from the file, the message says so plainly, names the copy that still holds it, and tells you to copy it back. It never points you at a new key, because your saves stay locked to the old one; with no backup at all, it tells you to sign in at indelible.one with the same account, copy your key from Settings, and bring it back in (setup imports a key; it never makes one). If you move Indelible to a new computer by copying the file, your key comes along but your PIN does not (it lives in your computer's keychain); the message for that case names the one command that puts it back, `indelible-mcp wallet --store-pin`, which asks for the PIN once and stores nothing if the PIN is wrong. And run Indelible on one computer at a time with the same wallet: two machines saving from one wallet fight over the same coins.
+
 Free tier and the hooks: every hook runs for everyone. Restore, the time card, style loading, and Guardrails are fully free. The pre-compaction **save** is the one piece that needs Pro. On a free wallet the hook still fires, but instead of saving it prints the plain notice that saving is a Pro feature. That is not an error. Your reads, diary, and recall keep working.
 
 Hook installation is idempotent. If you ever suspect the hooks are missing, run:

package/README.md

@@ -6,6 +6,10 @@ Blockchain-backed memory for Claude Code **and OpenAI's Codex CLI**. Save your A
 
 **New in 5.3.x — the drift wire: your two pilots talk to each other.** A durable wire on your machine where Claude and Codex hold a real conversation — every message kept in an append-only log on your disk, each reply citing the one it answers. (The local wire log lives and dies with this machine — no save uploads it. What rides Bitcoin is what you save: your sessions, and the machine-to-machine verbs below. Wire messages survive only as far as a pilot read them into a session you then saved.) Deliveries are **polled** in this release — the waiting verb checks the wire every few seconds, and nothing rings a bell between checks (the doorbell machinery ships but no command sends the ring yet; the ringer arrives next release). A **summoner** goes further: when a message sits unanswered, `indelible-mcp drift summon` conjures a *fresh* pilot through its own vendor CLI to read the wire and reply — and because the memory is permanent, it arrives already caught up, then saves its own session back to the chain. Those show up in your Context tab as **Summoned Sessions** — written by a called-up mind, never confused with your own work. And a **brake** only you hold: `indelible-mcp drift pause` freezes both pilots, no wallet needed. Full manual: indelible.one → Docs → The Drift Wire.
 
+**New in 5.8.8 — the wallet file can no longer be wiped by a save race, and a stuck save has a door.** The file that holds your key (`~/.indelible/config.json`) used to be rewritten in place by every settings save, so a read that landed in the middle of another write could come back empty and be written straight back over your key. That path is closed: every write of that file is now all-or-nothing (a temp file swapped into place), on Windows and Linux every Indelible process on the machine takes one lock before it writes, and a write that cannot read the file refuses instead of guessing. The refusals a save may now print are `CONFIG_UNREADABLE` (the file exists but could not be read; nothing was changed; if this is your wallet file, restore it from your backup rather than letting anything rewrite it) and `CONFIG_BUSY` (another program has the file open; close it and retry). On macOS the all-or-nothing write and the refusals are there, but two Indelible processes writing at the same instant are not yet held apart, so run one at a time. Back that file up regardless. Two more things ride along: if an Indelible process dies while holding the save journal lock, saves on that computer pause for safety and the message names the way out, `indelible-mcp wallet --unlock-journal` (or ask your assistant to use `wallet_unlock_journal`), which clears the lock only after proving the process that held it is gone; and a project restore now stays inside the folder you asked for, refusing a saved path that would climb out of it (`RESTORE_PATH_ESCAPES`) instead of writing there. After you restart your assistant it serves 36 tools (5.8.7 served 35); nothing was removed.
+
+**New in 5.8.9 — the wallet file's message tells the truth, and the file keeps its own backup.** When the file that holds your key had been emptied, every save used to answer "Wallet not configured or PIN incorrect. Run setup_wallet first." That sentence sent people the wrong way: what an emptied file needs back is the SAME key, and setting the machine up with a different one leaves every old save locked to the one that is gone; two customers told us so. From 5.8.9 the message says what is actually true, read from the file itself: no wallet file at all (run setup only if this machine never had a wallet; restore it if it did), a wallet file with the key gone from it (restore it from the copy beside it or your own backup, or bring the same account's key back from indelible.one; setup imports a key, it never makes one, so never a new key), a key whose PIN is not on this machine (`indelible-mcp wallet --store-pin`, typed once at a prompt; this is the case after moving Indelible to a new computer, where setup refuses because the wallet is already there), or a genuinely wrong PIN. And before every write over a file that holds a key, the software now keeps a copy beside it, `~/.indelible/config.json.bak.1` (with `.bak.2` behind it), refreshed when the key changes or hourly, so a restore is a copy of one file; when the key is gone, the message names that copy and the date it was taken. Also in this release: `indelible-mcp --help` now lists the `wallet` verb, `status` exits 1 when it cannot find a wallet, and the post-compaction hook no longer prints a raw error on a machine with no wallet yet. No new tools, nothing removed, 36 tools as in 5.8.8; restart your assistant after updating as always.
+
 > **New here?** Two guides ship with this package: **CUSTOMER_AGENT_HANDBOOK.md** (your agents on day one — the Witness, the Scribe, what runs for you) and **CLI_HANDBOOK.md** (every command + common errors). They are in the package install folder, or on indelible.one/docs.
 
 ## Quick Start

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "indelible-mcp",
-  "version": "5.8.7",
+  "version": "5.8.9",
   "description": "Blockchain-backed memory and code storage for Claude Code. Save AI conversations and source code permanently on BSV.",
   "type": "module",
   "main": "src/index.js",