@join-pantheon/cli 0.29.1 → 0.31.0

package/README.md

@@ -42,8 +42,8 @@ That gives you a verified account and a unique username no one else can claim,
 across every space on the hosted relay. A second machine joins the same account
 with `pantheon login --email you@work.com`. See your devices and sign any of them
 out with `pantheon sessions`; every identity and membership event is in `pantheon
-audit`. (Self-hosting or on a LAN/tailnet? Accounts are optional — skip straight
-to `pantheon start`.)
+audit`. (Self-hosting or on a LAN/tailnet? Accounts are optional there — skip
+signing up and point `start` at your own relay: `pantheon start --relay ws://<host>:8787`.)
 
 **Then, from your project's repo — or anywhere, if there is no repo yet (see below):**
 
@@ -76,13 +76,13 @@ That's it — one command each sets up the **whole machine**: a relay and space
 (them), pantheon wired into whichever agents each of you already has (**user scope** — every project,
 every Conductor window, nothing to commit), the wake-up hook so an agent finishes what a peer is
 waiting for, the **worker** so the machine answers the team even while its human is away (on by
-default when run inside a git repo; `--no-worker` opts out — and a peer still needs an explicit
-`--may-wake` grant before they can use it), native decision alerts, and the menu bar. Each command
-ends with a "You're set" summary, then a short guided setup on a terminal: three questions — your
-name, your role, and (inside a repo) whether a run a teammate wakes may execute commands — and one
-screen of defaults to keep or change: who may wake your machine while you are away, which alerts you
-want, which decisions are yours alone (so agents stop and ask you), the worker's playbook and its base
-branch. `pantheon setup` re-runs it any time. An agent setting you up runs `pantheon setup --questions`,
+default when run inside a git repo; `--no-worker` opts out), native decision alerts, and the menu bar. Each command
+ends with a "You're set" summary, then a short guided setup on a terminal: two questions — your
+name and your role — and one screen of defaults to keep or change: your teammates can hand work to
+your machine while you are away, that work runs your tests and commits to its own branch so it
+arrives ready to review, whichever agent you use (Claude Code, Codex, Cursor or Copilot) answers
+them, which alerts you want, which decisions are yours alone (so agents stop and ask you), the
+worker's playbook and its base branch. `pantheon setup` re-runs it any time. An agent setting you up runs `pantheon setup --questions`,
 asks you in chat, and passes your answers back as flags — to `pantheon setup --yes`, or straight to
 `pantheon start` / `pantheon join`, which apply them the moment the team exists — so nobody has to
 open a terminal. Restart your agent once and ask it *"check pantheon_status"*.
@@ -108,10 +108,10 @@ so and asks for a fresh invite; a relay that cannot be reached asks you for the
 Already a member — new laptop, or just pulled a newer build? The same full setup is one command:
 `pantheon install --user` (from your project's repo if you have one).
 
-**Consent happens once, here.** Setup pre-approves exactly the six pantheon *message* tools in
+**Consent happens once, here.** Setup pre-approves exactly the nine pantheon tools — messages, status and reads — in
 each agent's own permission system (Claude Code `permissions.allow`, Cursor `Mcp()` tokens,
 Codex per-server approval), so day-to-day coordination never interrupts you with "allow
-pantheon_wait?" again. Nothing that executes is pre-approved: `--may-wake` and `--allow-bash`
+pantheon_wait?" again. Nothing that executes is pre-approved: wake rights and `--allow-bash`
 keep their prompts on purpose — they are the two decisions worth reading. `pantheon leave`
 removes the grants. What remains is one one-time click per editor that only it can ask for
 (folder trust in Claude Code, MCP enable in Cursor, `/hooks` approval in Codex).
@@ -171,8 +171,32 @@ pantheon profile set --space mobile --human-required pricing   # authority that
 
 The relay checks too: a session whose checkout is not one of the team's repos is refused, and a
 `DELIVERED` must name a commit in one of them, so work from the wrong repo cannot land in a team.
-The worker serves every bound repo from one process, one run at a time, on `pantheon/<team>/<goal>`
-branches. Details and the scenario list: `docs/MULTI-SPACE.md`.
+Details and the scenario list: `docs/MULTI-SPACE.md`.
+
+**Several repos (a frontend, a backend, a mobile app) — set up once.**
+- `pantheon use <team> --here` in the folder that holds them binds every repo inside it, and
+  registers each with the team, in one go.
+- `pantheon repo find` (and `join`, on its own) looks for the team's repos on this machine — in the
+  usual code folders, in a folder you name, and, if you say yes, in the folders your editors and
+  agents have opened. It reads only folder names and git remote addresses; nothing leaves the machine.
+- A clone of one of the team's repos, wherever it lives, is that team's the first time an agent is
+  opened in it — no binding needed.
+- The relay knows each repo by a fingerprint and its everyday name (`web`), never its address.
+
+**One worker, every repo.** The worker serves every repo and folder bound to its team, one run at a
+time, and runs each request where it belongs: in the repo the request names (`the api repo`,
+`` `mobile` ``, `acme/web`), else where the goal's work was delivered, else the repo the asker sent
+it from, else the most recently active one — with the team's other repos here attached read-only
+(clean checkouts, never your working folder) so it can look across them. A request about a team repo
+this machine does not have runs nothing: the asker is told it waits, and it is never answered from
+another repo's code. `pantheon spaces` and `doctor` say what the worker serves and what is not here.
+
+**No git at all (a PM, ops, a founder's docs).** `start` or `join` from a plain folder binds it
+(never your home folder). The worker serves it too: a teammate's question is answered from that
+folder, which the run can read but never change; anything it writes goes to a drafts folder of its
+own, and you are told. Answering from a folder unattended needs Claude Code on that machine (the one
+agent that can be opened a folder to read and held off editing it); with another agent, those requests
+wait for your live session, and the teammate is told.
 
 ### If something is wrong
 
@@ -198,8 +222,8 @@ product itself; you read it, and you decide.
 
 <details><summary>The long way round, if you want to control each piece</summary>
 
-`pantheon relay` · `pantheon init` · `pantheon join` · `pantheon members` · `pantheon admit <who> --may-wake`
-· `pantheon install` (project-scope: commits a `.mcp.json`, so `pantheon` must be on PATH). Membership by explicit
+`pantheon relay` · `pantheon init` · `pantheon join` · `pantheon members` · `pantheon admit <who>` ·
+`pantheon wake allow <who>` · `pantheon install` (project-scope: commits a `.mcp.json`, so `pantheon` must be on PATH). Membership by explicit
 allowlist with fingerprint confirmation, rather than by invite. Everything the two-command path
 does, one step at a time.
 
@@ -278,7 +302,7 @@ pantheon service uninstall
 ```
 
 A terminal window is not "while you are asleep", so use `pantheon service install` for anything
-real. Logs land in `.pantheon/worker.log`.
+real. Logs land in `~/.pantheon/logs/worker.log` (`pantheon logs worker -f`).
 
 ### The menu bar (macOS)
 
@@ -314,7 +338,7 @@ pantheon directory                        # shared responsibility and authority
 pantheon approvals                        # decisions waiting on you
 pantheon approvals answer <id> 'Approved because…'
 pantheon profile delegate --to alex --domains technical \
-  --until 2026-09-05T18:00:00Z          # expires automatically; max 30 days
+  --until <ISO time, e.g. 2026-11-01T18:00:00Z>   # expires automatically; at most 30 days ahead
 pantheon profile undelegate --to alex     # revoke early
 ```
 
@@ -347,16 +371,30 @@ domain is a conflict, not a committee — routing blocks until one of them drops
 it or delegates. Decide domain ownership out loud before publishing; shared
 decisions belong to whoever answers for them, with delegation covering absence.
 
-When a peer you granted `--may-wake` asks something and no session of yours picks it up, the
+When a teammate asks this machine something and no session of yours picks it up, the
 worker spawns a headless agent run to handle it. Verified end to end: an `ASK` from an idle
 peer's machine was answered in **31 seconds with no human involved**, and:
 
 - the run happens in a **dedicated git worktree on a `pantheon/<goal>` branch** — your checkout and
   your uncommitted work are never touched, and nothing is merged
-- it runs with **only the six pantheon message tools** approved; bash stays gated unless you pass
-  `--allow-bash`
-- the relay — not the daemon — enforces who may wake you, so a peer without `--may-wake` is
-  refused even if your worker tries
+- in a repo it runs your tests, commits and pushes to its own branch (setup's default; `pantheon setup
+  --commands no` keeps runs to edits), so work arrives ready to review; a person on this machine can
+  also grant commands later (`pantheon policy grant run-commands`, or answering the worker's own
+  request from `pantheon approvals` or the menu bar)
+- teammates the team lets wake workers (the relay's per-member `may_wake`, which the invites you send
+  include) can hand this machine work — wake "anyone", the default. To approve each teammate on this
+  machine first, choose "only people I approve" (`pantheon setup --wake approved`); then
+  `pantheon wake allow <who>` (`wake deny`, `wake list`) keeps that list, on this machine only, and the
+  first time an unapproved teammate's request needs this machine the menu bar shows "Let <them> start
+  work here? Always / Just this once / No" (or `pantheon approvals`). The same buttons answer the
+  worker's request for commands; granting it runs the request that needed them.
+- upgrading keeps what you had said: teammates you admitted with `--may-wake` are carried over; so is
+  everyone the team lets wake if you had chosen "anyone" (or never chose, on a machine set up before
+  0.30, when that was the default); a joiner who was never asked keeps the team's founder. The worker
+  says who was carried and why. Against a relay older than 0.30 (it cannot say who admitted whom) the
+  team's `may_wake` keeps deciding until the relay upgrades, so upgrading the CLI first is safe.
+- the agent's environment carries no identity secret; the run is its own process group, killed whole
+  on timeout, `pantheon stop` and `pantheon panic`
 - a human who is actually working wins — but presence is not attention. The rule, in order:
   1. a turn in flight in any of your windows (your wake-up hook reports it) → the worker waits
   2. …unless that report is over **30 minutes** old with nothing after it. Claude Code runs no
@@ -409,17 +447,41 @@ With `auto` (the default) the order is: the agent a persona pins, then the one y
 then PATH order — and a candidate that is not signed in is skipped and named in the run log, so a
 run never fails on an expired session when another agent could have answered. If nothing is
 signed in, the first on PATH runs and the alert says exactly that, with the sign-in command.
-`pantheon doctor` shows the same choice (`worker agent`). Each backend is driven the way it
-actually works, with the same "no shell unless you said so" rule spelled in its own dialect:
-
-| backend | bash gated (default) | with `--allow-bash` |
+`pantheon doctor` shows the same choice (`worker agent`).
+
+**Whichever agent you use answers your teammates while you are away** — Claude Code, Codex, Cursor
+or Copilot. Claude Code runs inside its own OS sandbox (macOS and Linux, 2.1.83+), so `auto`
+prefers it when it is installed; Codex, Cursor and Copilot answer too, so a team on any of them is
+never kept waiting. To have Codex, Cursor and Copilot leave requests for you instead,
+`pantheon setup --unsandboxed no` (or `pantheon policy revoke unsandboxed-runs`; a woken run can never
+change it). Kiro answers in your live sessions; for unattended runs the worker uses another installed
+agent. Setup turns commands on for a worker that serves a repo (`pantheon setup --commands no` keeps
+runs to edits). Each backend is driven the way it actually works, with the same commands rule
+spelled in its own dialect:
+
+| backend | bash gated (`--commands no`) | with commands (setup's default in a repo, `run-commands` or `--allow-bash`) |
 |---|---|---|
-| claude-code | `acceptEdits` + the six pantheon tools | `bypassPermissions` |
-| codex | `--sandbox read-only` (codex has no edits-without-shell mode) | `--sandbox workspace-write` |
-| cursor | proposes edits, never applies (`-p` without `--force`) | `--force` |
-| copilot | `--allow-tool=pantheon-worker --allow-tool=write` (edits without shell, Copilot's `write` kind) | `--allow-all-tools` |
+| claude-code | `acceptEdits`, no shell, reads held to the worktree, `~/.ssh` `~/.aws` `~/.config/gh` `~/.pantheon` and similar denied; the repo's own `.claude` settings never load (`--setting-sources user`) | the same file rules, plus Claude Code's OS sandbox (macOS/Linux): commands may write only the worktree, its git data and temp dirs, may not read the secret paths, and a run whose sandbox cannot start does not start. Commands: git subcommands (with its run-a-program options denied), the repo's scripts via npm/pnpm/yarn/bun, make, cargo, go, pytest, mvn/gradle, dotnet, plus the committed `.pantheon/commands` on the base branch (one per line; shells, wrappers, package runners like `npx`, and inline code are refused — use `./node_modules/.bin/vitest`). The run names any command it needed that was refused. On Windows, or a Claude Code older than 2.1.83, commands run from that same list without the OS sandbox (`pantheon setup --unsandboxed no` keeps those runs to edits) |
+| codex | `--sandbox read-only` (codex has no edits-without-shell mode; reads are not restricted) | `--approve-for-me` (Codex's workspace-write sandbox, its auto-reviewer approves; any command) |
+| cursor | proposes edits, never applies (`-p` without `--force`) | `--force` (any command, no allowlist, no sandbox) |
+| copilot | `--allow-tool=pantheon-worker --allow-tool=write` (edits without shell, Copilot's `write` kind) | `--allow-all-tools` (any command, no allowlist, no sandbox) |
 | kiro | an agent whose tools are pantheon's plus `read`, `write`, `grep`, `glob` — all pre-approved | the same, plus `shell` |
 
+**What the command grant really means.** A run allowed to run commands can edit the repo's own
+scripts and then run them through a listed command (`npm test` runs whatever `package.json` says), so
+the command list alone never contains it. Where Claude Code's sandbox runs (macOS, Linux) that
+sandbox is the boundary. Everywhere else, a command run can read what you can — and, outside
+Codex's own write sandbox, change it. After every run
+Pantheon checks for the plain ways it could have widened what the NEXT run may do — a grant or wake
+approval it added, a loosened wake setting, a changed relay address, a queued menu-bar action —
+takes them back and tells you. That is a check after the fact, not a boundary: a run that can do
+what you can could change something it does not look at. Pantheon also refuses to send an act that
+holds this machine's key, a team token, or text in the shape of a common secret (a private key, a
+cloud or API token) — a guard against a pasted secret, not against one a run takes care to disguise.
+With Claude Code, what keeps your secrets from a run is that it cannot read them: the denies and the
+sandbox above. With other agents, grant commands only where you would be comfortable with the run
+having your access.
+
 Claude Code, Cursor and Codex are verified with **real live woken runs** — an idle machine answering a
 peer's ASK end to end. Codex quirks the tooling handles for
 you: no per-run approval flag exists in `codex exec`, MCP arrives via `-c` overrides (a worktree
@@ -548,7 +610,8 @@ The rules that make this safe to commit into a shared repo:
 
 ## Guardrails
 
-All enforced in the relay, not in a prompt — a prompt can be argued out of its instructions.
+All enforced in code — by the relay, or by each machine where the relay is not to be trusted —
+never in a prompt: a prompt can be argued out of its instructions.
 
 | Guard | Default | Why |
 |---|---|---|
@@ -564,9 +627,10 @@ All enforced in the relay, not in a prompt — a prompt can be argued out of its
 | Membership | explicit allowlist, ed25519 | the token is not a credential; a name needs its key |
 | Invites | single-use, expiring | a leaked link is inert once redeemed or timed out |
 | Claims | one session per obligation | parallel Conductor workspaces cannot duplicate work |
-| Wake rights | `--may-wake`, per member | only named peers may start a run on your machine |
+| Wake rights | `pantheon wake allow`, per machine; `--may-wake`, per member for the team | under "anyone" (the default): every peer the team lets wake; under "approved": only those you also approved here. Checked by the worker before a run starts, and by the relay at its claim |
 | Run budget | 12/hour, 1 concurrent | a peer cannot drain your tokens |
 | Personas | tighten-only | a persona file — even one a teammate committed — can lower caps and turn bash off, never the reverse |
+| Signed acts | every act and goal, ed25519, since 0.31 | checked on each receiving machine against the key it pinned for the sender: the relay cannot forge, alter, re-file or replay a teammate's request without that machine noticing, and a worker runs only requests that check out. A teammate's changed key is held back until you confirm it (`pantheon trust`) |
 | Worktree hygiene | no secrets on disk | credentials reach a woken run through its environment only; run scratch files are git-excluded |
 | Verifiable delivery | branch + commit required | "I wrote the file" is not checkable from another machine |
 | Durable state | goals + obligations on disk | a relay restart used to discard every open goal |
@@ -596,8 +660,9 @@ pantheon mcp                       the stdio MCP server — your agent runs this
 ```
 
 `pantheon help --all` lists everything. `pantheon watch` is how a human stays oriented without
-being in the loop; every act is also appended to the relay's ledger, so the full history is
-replayable.
+being in the loop; every act is also appended to the relay's ledger, so a goal's history is
+replayable while it is open — closed goals are compacted once the space needs room, so export what
+you need to keep with `pantheon audit --json`.
 
 ## What this still is not
 
@@ -608,18 +673,55 @@ replayable.
   the next real gap: `DELIVERED` is now verifiable, but *conformance to the contract* is not.
 - **Nothing fetches the delivered commit for you.** The relay requires a ref and the receiving
   delegate is told to check it, but there is no `pantheon fetch` helper yet.
-- **The space token is still a shared secret** for *reaching* the relay, even though membership is
-  now key-based. Treat the relay endpoint as semi-public and rely on the allowlist.
-- **A woken run is trusted with your repo.** `--allow-bash` in particular means a peer's request
-  can execute commands on your machine. Grant `--may-wake` deliberately.
+- **The space token still reads a team's history until someone is removed.** Joining takes an
+  admitted key, but in a team that has never removed anyone the token alone can read its history
+  over HTTP (older clients need that); after any removal, reads need an admitted key. Share invite
+  links, not the token.
+- **Commands on a woken run are on by default in a repo.** A run works in its own worktree and
+  branch, inside your agent's sandbox where it has one (see above). `pantheon setup --commands no`
+  keeps runs to edits, and `pantheon setup --wake approved` lets you approve each teammate first.
+
+## Is Pantheon safe for my team?
+
+Short answer: your teammates' agents can hand your machine work while you are away — it runs in its
+own copy of the repo and is delivered on a branch for your review — and whoever runs the relay
+cannot fake or alter a teammate's request. What that means in practice:
+
+- **Pantheon never uploads your code, credentials or repo.** The relay passes messages between
+  agents and has no filesystem or shell access to anyone's computer; what leaves your machine is
+  what an agent writes into a message.
+- **The relay can read the messages** (they are not end-to-end encrypted), so treat a team space
+  like a shared team channel. It **cannot write one in a teammate's name or change one**: with 0.31
+  on the relay and on your machine, every message is signed by its sender and checked against the
+  key your machine keeps for them, and one that does not check out is marked NOT VERIFIED and never
+  starts work. (The first time your machine meets a teammate it takes their key from the member
+  list; a changed key later is held back until you confirm it.) It can still delay or withhold messages.
+- **Your teammates can hand your machine work while you are away.** `pantheon start` in a repo turns
+  the worker on (`--no-worker` leaves it off). Each run works in its own copy of the repo, runs your
+  tests, and delivers on its own branch for your review; runs are capped at 12 an hour, and
+  `pantheon panic` pauses all of it at once. `pantheon wake list` shows who can hand you work, and
+  `pantheon setup --wake approved` lets you approve each teammate first.
+- **You can see and change all of it:** `pantheon policy` (what the worker may do, including whether
+  Pantheon updates itself), `pantheon trust` (the teammates' keys this machine checks messages
+  against), `pantheon audit`, `pantheon doctor`.
+
+For a team of five, the defaults are the setup: everyone's agent answers the team while they are
+away, work arrives tested on its own branch, and decisions you reserved still come to you. Prefer to
+review every change by hand on one machine? `pantheon setup --commands no` there. When Pantheon says
+a teammate's key changed, check it with them before `pantheon trust`. Claude Code runs inside its
+OS sandbox; Codex answers inside its own workspace sandbox, and Cursor and Copilot run commands
+without asking, as you (`pantheon setup --unsandboxed no` has them leave requests for you). The
+full model, and how to report a problem: [joinpantheon.network/security](https://www.joinpantheon.network/security).
 
 ## Privacy, data, and support
 
 The hosted relay at `relay.joinpantheon.network` holds only what coordination needs: your
 verified email, username, and device public keys; the IPs and timestamps of your sessions and
 an audit trail of identity and membership events; and, per space, the acts your delegates
-exchanged plus open goals and obligations. Your code, credentials, and repo never leave your
-machine — the relay has no filesystem or shell access by design.
+exchanged plus open goals and obligations. Pantheon never uploads your code, credentials or repo,
+and the relay has no filesystem or shell access by design: what leaves your machine is what an
+agent writes into a message (and Pantheon refuses to send its own keys, team tokens, or text in the
+shape of a common secret).
 Whoever operates the relay can read those acts — the operator dashboard shows each space's
 message history — so treat a space like a shared team channel, not a private notebook.
 

package/bin/pantheon.js

@@ -11,6 +11,18 @@ import { existsSync } from "node:fs";
 import { dirname, resolve } from "node:path";
 import { fileURLToPath, pathToFileURL } from "node:url";
 
+// Node first, before anything that needs a newer one is loaded. On an older
+// Node the first failure was deep and unreadable: node:sqlite missing (it is
+// behind a flag through 22.12), or — on Node 18 behind a proxy — undici 7
+// dying with "File is not defined" on import. This file must stay free of any
+// syntax newer than Node 16, so the check itself runs on the Node it rejects.
+var nodeVersion = process.versions.node.split(".").map(Number);
+var nodeMajor = nodeVersion[0], nodeMinor = nodeVersion[1];
+if (nodeMajor < 22 || (nodeMajor === 22 && nodeMinor < 13) || (nodeMajor === 23 && nodeMinor < 4)) {
+  console.error("pantheon needs Node 22.13 or newer (it uses node:sqlite); this is Node " + process.versions.node + ". Install a current Node LTS from https://nodejs.org and run pantheon again.");
+  process.exit(1);
+}
+
 const here = dirname(fileURLToPath(import.meta.url));
 const root = resolve(here, "..");
 const entry = resolve(root, "dist", "cli.js");

package/dist/accounts.js

@@ -1,13 +1,17 @@
 import { DEFAULT_PLANS, parsePlans, parseLimits, planLimits } from "./plans.js";
 import { createRequire } from "node:module";
 import { createHash, randomBytes, randomInt, timingSafeEqual } from "node:crypto";
-import { chmodSync, mkdirSync, readdirSync, rmSync } from "node:fs";
+import { chmodSync, closeSync, mkdirSync, openSync, readdirSync, rmSync } from "node:fs";
 import { dirname, join } from "node:path";
 import { fingerprint } from "./identity.js";
 const nodeRequire = createRequire(import.meta.url);
 const CODE_TTL_MS = 10 * 60 * 1_000;
 const CODE_RESEND_COOLDOWN_MS = 60 * 1_000;
 const MAX_ATTEMPTS = 5;
+export const MAX_FAILS_PER_KEY = 10;
+export const MAX_FAILS_PER_NETWORK = 50;
+export const FAIL_WINDOW_MS = 60 * 60 * 1_000;
+const MAX_PENDING_PER_EMAIL = 5;
 const now = () => Date.now();
 const newId = (p) => `${p}_${randomBytes(9).toString("base64url")}`;
 const sha = (s) => createHash("sha256").update(s).digest("hex");
@@ -27,7 +31,12 @@ export class Accounts {
     db;
     constructor(dbPath) {
         if (dbPath !== ":memory:") {
-            mkdirSync(dirname(dbPath), { recursive: true });
+            mkdirSync(dirname(dbPath), { recursive: true, mode: 0o700 });
+            try {
+                closeSync(openSync(dbPath, "a", 0o600));
+                chmodSync(dbPath, 0o600);
+            }
+            catch { }
         }
         let DB;
         try {
@@ -40,10 +49,12 @@ export class Accounts {
         this.db.exec("PRAGMA journal_mode = WAL; PRAGMA foreign_keys = ON;");
         this.migrate();
         if (dbPath !== ":memory:") {
-            try {
-                chmodSync(dbPath, 0o600);
+            for (const f of [dbPath, `${dbPath}-wal`, `${dbPath}-shm`]) {
+                try {
+                    chmodSync(f, 0o600);
+                }
+                catch { }
             }
-            catch { }
         }
     }
     migrate() {
@@ -65,6 +76,11 @@ export class Accounts {
         created_at INTEGER NOT NULL,
         last_seen INTEGER NOT NULL
       );
+      -- The table as 0.29.1 and earlier keep it, one code per email, left in
+      -- exactly that shape: a relay rolled back to one of them runs
+      -- INSERT ... ON CONFLICT(email) against it, which needs email to be the
+      -- key. This build keeps its codes in verifications_by_device below and
+      -- only drains this one (see migrate).
       CREATE TABLE IF NOT EXISTS verifications (
         email TEXT PRIMARY KEY,
         code_hash TEXT NOT NULL,
@@ -76,6 +92,23 @@ export class Accounts {
         attempts INTEGER NOT NULL DEFAULT 0,
         created_at INTEGER NOT NULL
       );
+      CREATE TABLE IF NOT EXISTS verifications_by_device (
+        email TEXT NOT NULL,
+        code_hash TEXT NOT NULL,
+        purpose TEXT NOT NULL,
+        pending_username TEXT,
+        pending_pubkey TEXT NOT NULL DEFAULT '',
+        pending_label TEXT,
+        expires_at INTEGER NOT NULL,
+        attempts INTEGER NOT NULL DEFAULT 0,
+        created_at INTEGER NOT NULL,
+        PRIMARY KEY (email, pending_pubkey)
+      );
+      CREATE TABLE IF NOT EXISTS verify_failures (
+        email TEXT PRIMARY KEY,
+        window_start INTEGER NOT NULL,
+        fails INTEGER NOT NULL
+      );
       CREATE TABLE IF NOT EXISTS sessions (
         id TEXT PRIMARY KEY,
         account_id TEXT NOT NULL REFERENCES accounts(id) ON DELETE CASCADE,
@@ -128,6 +161,28 @@ export class Accounts {
             this.db.exec("ALTER TABLE sessions ADD COLUMN ended_at INTEGER");
         if (!scols.has("role"))
             this.db.exec("ALTER TABLE sessions ADD COLUMN role TEXT");
+        const spcols = new Set(this.db.prepare("PRAGMA table_info(spaces)").all().map((c) => c.name));
+        if (!spcols.has("owner_deleted_at"))
+            this.db.exec("ALTER TABLE spaces ADD COLUMN owner_deleted_at INTEGER");
+        const vcols = this.db.prepare("PRAGMA table_info(verifications)").all();
+        this.db.exec("BEGIN");
+        try {
+            this.db.exec(`INSERT OR IGNORE INTO verifications_by_device (email, code_hash, purpose, pending_username, pending_pubkey, pending_label, expires_at, attempts, created_at)
+        SELECT email, code_hash, purpose, pending_username, COALESCE(pending_pubkey, ''), pending_label, expires_at, attempts, created_at FROM verifications`);
+            if (vcols.some((c) => c.name === "pending_pubkey" && c.pk > 0)) {
+                this.db.exec(`DROP TABLE verifications;
+          CREATE TABLE verifications (email TEXT PRIMARY KEY, code_hash TEXT NOT NULL, purpose TEXT NOT NULL, pending_username TEXT,
+            pending_pubkey TEXT, pending_label TEXT, expires_at INTEGER NOT NULL, attempts INTEGER NOT NULL DEFAULT 0, created_at INTEGER NOT NULL);`);
+            }
+            else {
+                this.db.exec("DELETE FROM verifications");
+            }
+            this.db.exec("COMMIT");
+        }
+        catch (e) {
+            this.db.exec("ROLLBACK");
+            throw e;
+        }
     }
     close() { this.db.close(); }
     accountByUsername(username) {
@@ -179,43 +234,91 @@ export class Accounts {
             if (!acct || acct.status !== "active")
                 return { ok: false, reason: "no_such_account" };
         }
-        const prev = this.db.prepare("SELECT created_at, expires_at, pending_pubkey FROM verifications WHERE email = ?").get(e);
-        if (prev && now() - prev.created_at < CODE_RESEND_COOLDOWN_MS)
+        if (this.deviceOfOtherAccount(e, opts.pubkey))
+            return { ok: false, reason: "device_other_account" };
+        const key = opts.pubkey;
+        const t = now();
+        const acct0 = this.accountByEmail(e);
+        const ownKey = !!acct0 && this.deviceByPubkey(key)?.account_id === acct0.id;
+        const prev = this.db.prepare(ownKey ? "SELECT MAX(created_at) created_at FROM verifications_by_device WHERE email = ? AND pending_pubkey = ?" : "SELECT MAX(created_at) created_at FROM verifications_by_device WHERE email = ? AND ? IS NOT NULL")
+            .get(e, key);
+        if (prev?.created_at && t - prev.created_at < CODE_RESEND_COOLDOWN_MS)
             return { ok: false, reason: "too_soon" };
-        if (prev && now() < prev.expires_at && prev.pending_pubkey && prev.pending_pubkey !== opts.pubkey) {
-            return { ok: false, reason: "in_progress_elsewhere" };
+        if (this.failsOf(`key:${e}|${key}`, t) >= MAX_FAILS_PER_KEY)
+            return { ok: false, reason: "locked" };
+        this.db.prepare("DELETE FROM verifications_by_device WHERE email = ? AND expires_at < ?").run(e, t);
+        if (ownKey) {
+            for (const r of this.db.prepare("SELECT pending_pubkey FROM verifications_by_device WHERE email = ? AND pending_pubkey != ?").all(e, key)) {
+                if (this.deviceByPubkey(r.pending_pubkey)?.account_id !== acct0.id)
+                    this.db.prepare("DELETE FROM verifications_by_device WHERE email = ? AND pending_pubkey = ?").run(e, r.pending_pubkey);
+            }
+        }
+        const others = this.db.prepare("SELECT pending_pubkey FROM verifications_by_device WHERE email = ? AND pending_pubkey != ? ORDER BY created_at ASC").all(e, key);
+        for (const r of others.slice(0, Math.max(0, others.length - (MAX_PENDING_PER_EMAIL - 1)))) {
+            this.db.prepare("DELETE FROM verifications_by_device WHERE email = ? AND pending_pubkey = ?").run(e, r.pending_pubkey);
         }
         const code = String(randomInt(0, 1_000_000)).padStart(6, "0");
         this.db.prepare(`
-      INSERT INTO verifications (email, code_hash, purpose, pending_username, pending_pubkey, pending_label, expires_at, attempts, created_at)
+      INSERT INTO verifications_by_device (email, code_hash, purpose, pending_username, pending_pubkey, pending_label, expires_at, attempts, created_at)
       VALUES (?, ?, ?, ?, ?, ?, ?, 0, ?)
-      ON CONFLICT(email) DO UPDATE SET
+      ON CONFLICT(email, pending_pubkey) DO UPDATE SET
         code_hash = excluded.code_hash, purpose = excluded.purpose,
-        pending_username = excluded.pending_username, pending_pubkey = excluded.pending_pubkey,
+        pending_username = excluded.pending_username,
         pending_label = excluded.pending_label, expires_at = excluded.expires_at,
         attempts = 0, created_at = excluded.created_at
-    `).run(e, sha(code), purpose, purpose === "signup" ? normalizeUsername(opts.username) : null, opts.pubkey, opts.label, now() + CODE_TTL_MS, now());
+    `).run(e, sha(code), purpose, purpose === "signup" ? normalizeUsername(opts.username) : null, key, opts.label, t + CODE_TTL_MS, t);
         return { ok: true, code };
     }
-    verify(email, code, ip, pubkey) {
+    failsOf(key, t = now()) {
+        const f = this.db.prepare("SELECT window_start, fails FROM verify_failures WHERE email = ?").get(key);
+        return f && t - f.window_start < FAIL_WINDOW_MS ? f.fails : 0;
+    }
+    noteFail(key, t = now()) {
+        const f = this.db.prepare("SELECT window_start FROM verify_failures WHERE email = ?").get(key);
+        if (f && t - f.window_start < FAIL_WINDOW_MS)
+            this.db.prepare("UPDATE verify_failures SET fails = fails + 1 WHERE email = ?").run(key);
+        else
+            this.db.prepare("INSERT INTO verify_failures (email, window_start, fails) VALUES (?, ?, 1) ON CONFLICT(email) DO UPDATE SET window_start = excluded.window_start, fails = 1").run(key, t);
+    }
+    verify(email, code, ip, pubkey, net = null) {
         const e = normalizeEmail(email);
-        const v = this.db.prepare("SELECT * FROM verifications WHERE email = ?").get(e);
-        if (!v)
-            return { ok: false, reason: "no_pending" };
-        if (now() > v.expires_at) {
-            this.db.prepare("DELETE FROM verifications WHERE email = ?").run(e);
+        const t = now();
+        const rows = this.db.prepare("SELECT * FROM verifications_by_device WHERE email = ? ORDER BY created_at ASC").all(e);
+        let v;
+        if (pubkey) {
+            v = rows.find((r) => r.pending_pubkey === pubkey);
+            if (!v)
+                return { ok: false, reason: rows.some((r) => t <= r.expires_at) ? "other_device" : rows.length ? "expired" : "no_pending" };
+        }
+        else {
+            const live = rows.filter((r) => t <= r.expires_at);
+            if (live.length > 1)
+                return { ok: false, reason: "several_pending" };
+            v = live[0] ?? rows[rows.length - 1];
+            if (!v)
+                return { ok: false, reason: "no_pending" };
+        }
+        const where = "email = ? AND pending_pubkey = ?";
+        if (t > v.expires_at) {
+            this.db.prepare(`DELETE FROM verifications_by_device WHERE ${where}`).run(e, v.pending_pubkey);
             return { ok: false, reason: "expired" };
         }
         if (v.attempts >= MAX_ATTEMPTS)
             return { ok: false, reason: "too_many_attempts" };
-        if (pubkey && v.pending_pubkey && pubkey !== v.pending_pubkey)
-            return { ok: false, reason: "other_device" };
+        if (v.pending_pubkey && this.deviceOfOtherAccount(e, v.pending_pubkey))
+            return { ok: false, reason: "device_other_account" };
+        const keyId = `key:${e}|${v.pending_pubkey}`, netId = net ? `net:${net}` : null;
+        if (this.failsOf(keyId, t) >= MAX_FAILS_PER_KEY || (netId && this.failsOf(netId, t) >= MAX_FAILS_PER_NETWORK))
+            return { ok: false, reason: "locked" };
         const want = Buffer.from(v.code_hash, "hex");
         const got = Buffer.from(sha(code), "hex");
         const good = want.length === got.length && timingSafeEqual(want, got);
         if (!good) {
-            this.db.prepare("UPDATE verifications SET attempts = attempts + 1 WHERE email = ?").run(e);
-            return { ok: false, reason: "bad_code" };
+            this.db.prepare(`UPDATE verifications_by_device SET attempts = attempts + 1 WHERE ${where}`).run(e, v.pending_pubkey);
+            this.noteFail(keyId, t);
+            if (netId)
+                this.noteFail(netId, t);
+            return { ok: false, reason: "bad_code", tries_left: Math.max(0, MAX_ATTEMPTS - v.attempts - 1) };
         }
         const run = this.db.prepare.bind(this.db);
         this.db.exec("BEGIN");
@@ -243,7 +346,11 @@ export class Accounts {
             }
             const device = this.bindDevice(account.id, v.pending_pubkey, v.pending_label ?? "a device");
             const session = this.openSession(account.id, device.id, "", ip);
-            run("DELETE FROM verifications WHERE email = ?").run(e);
+            if (v.purpose === "signup")
+                run("DELETE FROM verifications_by_device WHERE email = ?").run(e);
+            else
+                run(`DELETE FROM verifications_by_device WHERE ${where}`).run(e, v.pending_pubkey);
+            run("DELETE FROM verify_failures WHERE email = ?").run(keyId);
             this.db.exec("COMMIT");
             this.audit({ actor_account: account.id, event: v.purpose === "signup" ? "email_verified" : "login", target: device.fingerprint, ip });
             return { ok: true, account, session, device };
@@ -253,8 +360,22 @@ export class Accounts {
             throw err;
         }
     }
+    deviceOfOtherAccount(email, pubkey) {
+        const dev = this.deviceByPubkey(pubkey);
+        if (!dev)
+            return false;
+        return dev.account_id !== this.accountByEmail(email)?.id;
+    }
+    isDeviceOf(email, pubkey) {
+        if (!pubkey)
+            return false;
+        const dev = this.deviceByPubkey(pubkey);
+        return !!dev && dev.account_id === this.accountByEmail(email)?.id;
+    }
     bindDevice(accountId, pubkey, label) {
         const existing = this.deviceByPubkey(pubkey);
+        if (existing && existing.account_id !== accountId)
+            throw new Error("this device key is bound to a different account");
         if (existing) {
             this.db.prepare("UPDATE devices SET last_seen = ? WHERE id = ?").run(now(), existing.id);
             return existing;
@@ -318,6 +439,7 @@ export class Accounts {
             return false;
         this.db.exec("BEGIN");
         try {
+            this.db.prepare("UPDATE spaces SET owner_deleted_at = ? WHERE owner_account = ?").run(now(), accountId);
             this.db.prepare("DELETE FROM accounts WHERE id = ?").run(accountId);
             this.db.exec("COMMIT");
         }
@@ -382,7 +504,7 @@ export class Accounts {
         return this.db.prepare("SELECT * FROM blocks ORDER BY created_at DESC").all();
     }
     recentVerifications(limit = 50) {
-        return this.db.prepare("SELECT email, purpose, created_at, expires_at, attempts FROM verifications ORDER BY created_at DESC LIMIT ?").all(limit);
+        return this.db.prepare("SELECT email, purpose, created_at, expires_at, attempts FROM verifications_by_device ORDER BY created_at DESC LIMIT ?").all(limit);
     }
     plans() {
         const row = this.db.prepare("SELECT json FROM settings WHERE key = 'plans'").get();
@@ -444,7 +566,7 @@ export class Accounts {
     }
     recordSpace(name, ownerAccount) {
         this.db.prepare("INSERT INTO spaces (name, owner_account, created_at, deleted_at) VALUES (?, ?, ?, NULL) " +
-            "ON CONFLICT(name) DO UPDATE SET owner_account = excluded.owner_account, created_at = excluded.created_at, deleted_at = NULL WHERE spaces.deleted_at IS NOT NULL").run(name, ownerAccount, now());
+            "ON CONFLICT(name) DO UPDATE SET owner_account = excluded.owner_account, created_at = excluded.created_at, deleted_at = NULL, owner_deleted_at = NULL WHERE spaces.deleted_at IS NOT NULL").run(name, ownerAccount, now());
     }
     markSpaceDeleted(name) {
         this.db.prepare("UPDATE spaces SET deleted_at = ? WHERE name = ? AND deleted_at IS NULL").run(now(), name);
@@ -453,6 +575,9 @@ export class Accounts {
         const r = this.db.prepare("SELECT owner_account FROM spaces WHERE name = ? AND deleted_at IS NULL").get(name);
         return r?.owner_account ? this.accountById(r.owner_account) : null;
     }
+    spaceOrphaned(name) {
+        return !!this.db.prepare("SELECT 1 FROM spaces WHERE name = ? AND deleted_at IS NULL AND owner_account IS NULL AND owner_deleted_at IS NOT NULL").get(name);
+    }
     spacesOwned(accountId) {
         return this.db.prepare("SELECT name FROM spaces WHERE owner_account = ? AND deleted_at IS NULL ORDER BY created_at").all(accountId).map((r) => r.name);
     }