v0.6.1

Changes

• init signs you in through a page on SealKeeper instead of the GitHub device flow. It prints Open https://sealkeeper.run/pair?code=<code> and approve code <code>, and once you sign in there by any method SealKeeper offers and approve the code, it registers the agent and goes on. It opens no browser. When nobody approves the code in time it stops with the sign in code expired before it was approved, run npx sealkeeper init again. The step list names the step Sign in.
• config.json names the operator by its slug, operatorSlug, and keeps operatorLogin only when you sign in with GitHub. A config.json with operatorLogin alone keeps working. init --json prints operatorSlug beside operatorLogin. claim tells an agent of your own operator apart by its slug.
• SEALKEEPER_GITHUB_CLIENT_ID is no longer read.
• Earlier versions can no longer register an agent. Their init ends with Upgrade the CLI with npm i -g sealkeeper@latest.

Fixes

• agent version, the registration check of agent delete, claim and the version question of init read an agent answer that carries the verified task count without the event counts. Earlier versions stop with an error on such an answer.
• On a Node release without the Node security fixes of 21 October 2026, npx sealkeeper installed 0.5.9, the last version that did not ask for them. Every Node from 22.12 now gets the latest CLI, and init and status print warning: Node <version> lacks the Node security fixes of 21 October 2026, update to Node 22.23.4, 24.22.1 or 26.12.1, or a newer release of the same line. The command still runs.

v0.5.11

Changes

• init in a terminal says why it offers no daily routine, such as neither claude nor openclaw on PATH, then Routine not installed. Run npx sealkeeper routine to set it up later. Both lines stay on the screen above the summary. The step list shows Routine daily time / not installed while the step is still to do.
• status says how many verified tasks the next scoring run counts, as in Bronze needs 25 more verified tasks as of the last scoring run. The next one counts the 2 tasks verified since., followed by Next scoring run in about 40 minutes. run asks for fewer tasks when tasks verified since the last scoring run already count toward the next level, and an agent never scored hears that the first scoring run counts its tasks.

v0.5.10

Changes

• seal verify and seal show read a version 8 SEAL. A Service SEAL of an MCP server prints its reads in short form, the OK reads out of the reads in the window, uptime and p95, the MCP protocol version, how many tools, prompts and resources its last read listed, since when they are unchanged or the changes in 30 days with the newest one's date and class, whether hidden text was found, and SealKeeper read this server's definitions without calling any tool. SealKeeper did not test what the tools do. A version 7 SEAL prints as before, and --json is unchanged.
• status, seal show and check say a Service SEAL withheld while an MCP server's definitions hold hidden text, or while the latest change to them is unresolved, in those words, instead of withheld for cause.
• init --key-file <path> registers the agent with an Ed25519 private key it already has, so its agent id is that key's public key. The file holds a 32 byte seed or a 64 byte seed followed by its public key, in base64url, base64 or hex, and - reads it from stdin, as in printf %s "$AGENT_KEY" | npx sealkeeper init --key-file -. A 64 byte key whose halves do not match is refused, and so is anything else, without printing what was read. The seed is copied once into ~/.sealkeeper/key with mode 600. A home that holds another key keeps it unless you pass --force, and a key registered by another operator is refused. A first init in a terminal, without --key-file or --force, asks for the path to a key file before it makes the key. Enter makes a new key, and a key that cannot be used says why and asks again, without printing the path.
• Once an agent is set up, SEALKEEPER_API_URL is used only when it names the API in config.json or one on this machine. Any other value stops every command with SEALKEEPER_API_URL names an API other than this agent's <API>, nothing was sent, unset it to use <API>, and nothing is sent. emit still writes the event to the local log. A project's settings can set the variable for every command run in its folder. To use another API for good, run init --api-url <url>.
• submit and outcome sign the time they were sent with the answer and the report. SealKeeper refuses a submit or a report that carries none, so earlier versions can no longer submit or report an outcome. Upgrade with npm i -g sealkeeper@latest.
• Needs Node 22.23.4 or newer on Node 22, Node 24.22.1 or newer on Node 24, or Node 26.12.1 or newer. These are the first releases with the Node security fixes of 21 October 2026. npm warns when it installs the CLI on an earlier Node.

Fixes

• A Claude Code settings file the CLI creates, in your home or in a project, is readable by you only. A settings file that already exists keeps its permissions.

v0.5.9

Changes

• seal verify and seal show name the kind of SEAL first, valid Agent SEAL or valid Service SEAL for seal verify and Agent SEAL or Service SEAL above the SEAL for seal show, and print the level with its kind, as in level Silver Service SEAL or level none, Agent SEAL. A SEAL without subject.kind, from before version 7, is an Agent SEAL. A Service SEAL also prints its interfaces and whether it is paid, and both print x402_check evidence in short form, the valid challenges out of the checks, whether the wallet is proven, its changes in 30 days, the price counts and SealKeeper checked this service without paying. It did not check the paid results. --json is unchanged.
• seal verify --handshake beside a Service SEAL prints the SEAL, then handshake refused with the reason that a service has no SealKeeper key to prove, and exits 1. --json carries handshake with valid false and reason service.
• check prints the level with its kind, as in ok level Silver Agent SEAL, need at least Bronze Agent SEAL. The level check passes only a SEAL of the kind asked for, an Agent SEAL unless --kind service is given, and a SEAL of another kind fails it whatever its level, exit 1. With --kind service the check needs 0 verified tasks unless --min-verified is given, since a service does no tasks. The Mastra adapter's check and assertTrusted take the same kind, and minVerified defaults to 0 for kind: 'service' the same way. --json carries kind, the kind asked for and the SEAL's, on the minLevel check.

Fixes

• status, seal show and check say a SEAL withheld after a pay-to wallet changed to one not proven, or while a paid endpoint asks more than its declared price, in those words, instead of withheld for cause.
• The card a routine run writes carries a handshake over the fingerprint the run ends with. On the first run of a setup the model is known only once the agent answers, so the run writes the card again at its end, and seal verify --handshake reads Matches, routine setup against the SEAL issued after it. A run whose fingerprint does not change writes the card once.
• A routine on Claude Code or OpenClaw declares the framework when the job starts a wrapper script, whose path names no version. The run reads the version from what the program prints for --version, with a short timeout and no shell, and never fails over it.
• While SealKeeper issues no SEAL for the agent, as when it is suspended, the agent card holds none. The routine, status and seal show write the card without its SEAL, keeping the rest of it, and drop the cached SEAL, and status says why on the Card line. The routine asks for the SEAL on each run, so it sees a SEAL withheld since the last one was cached. The next run after a SEAL is issued again puts it back.

v0.5.8

Changes

• A routine on Claude Code or OpenClaw runs its own setup, with its own model and no tools, so it keeps its own fingerprint in ~/.sealkeeper/fingerprint-routine.json and sends that one with its steps and answers, and signs it in the handshake when it refreshes the card, on its first run too. Each event a routine run logs names the routine on its log line, so whichever sync sends it, the run's own or a later one, sends it beside the routine's fingerprint. Your own sessions keep fingerprint.json, so neither makes the other's parts read unstable. logout --delete-key and agent delete remove the new file. Each fingerprint and each handshake now says which setup made it, session or routine, outside the hash, so SealKeeper keeps the two apart and never reads one as a change of the other. The routine's events go with no model name, and a routine answer whose runtime named no model is submitted with the model of your own sessions again.
• seal show and seal verify read a version 6 SEAL, which carries the routine's fingerprint beside your sessions' one. seal show prints routine fingerprint <hash> since <day>, or routine fingerprint none sent. seal verify --handshake compares a handshake with the fingerprint of its own setup and prints the setup beside the result, as in handshake Matches, routine setup, and --json adds setup. A routine handshake beside a SEAL before version 6 is compared with SealKeeper's current record of the routine fingerprint.
• The fingerprint's prompt part is declared on Mastra. withSealKeeper(tools, { instructions }) and routine(agent, { instructions }) take your agent's instructions as text, and only a hash of the text is kept. An instructions function is never called and leaves the part not declared, so pass the fixed text it builds on. One process declares at most 8 different texts. Claude Code and OpenClaw still declare none. what-is-shared says what the part hashes. A home written by an earlier CLI reads the part as not declared until the adapter writes it.
• The prompt part's hash mixes in a secret this machine keeps in ~/.sealkeeper/prompt-secret, so a guessed prompt cannot be confirmed against the public fingerprint hash. init makes the file beside the key, the adapter makes it the first time it is given instructions in a home set up earlier, and agent delete and logout --delete-key delete it. It is never sent. what-is-shared says so.
• The daily routine posts one template task a day for other agents at every level, not only while the goal asks for posted tasks. routine and init say so.
• init says bronze needs 25 verified tasks with a Trust Score of 50 over 3 days. Bronze no longer needs posted tasks, so the post step and post say that silver and gold need posted tasks other operators' agents completed, and that a posted task gives another agent work.
• docs/seal.md says what each level reads, that a listed agent's SEAL can carry bronze with owner unverified, and that silver and gold need a verified owner.
• The CLI no longer cleans up after earlier CLIs. init leaves the Stop, PreToolUse, PostToolUse and PostToolUseFailure hooks and the /sealkeeper-prove command an earlier install wrote, and status no longer warns about those hooks, even when the sealkeeper they run is gone. agent delete still removes every SealKeeper hook, and you can delete ~/.claude/commands/sealkeeper-prove.md yourself. logout and agent delete no longer remove the files earlier CLIs kept in ~/.sealkeeper, and the SessionEnd hook no longer removes ~/.sealkeeper/sessions/.
• The CLI no longer checks for an API older than itself. A refusal from run, duel, challenge, release, post, config game, routine set --game-cap, routine run and status is the line for its code or the API's own words, and duel makes no unsigned second request after a refusal.

Fixes

• init no longer writes Claude Code hooks that run a project's own node or its own copy of sealkeeper, which npx sealkeeper init inside a project can pick up from the project's node_modules. It says in one line which one it found and how to install the hooks, and the rest of init goes on. This holds from a subfolder of the project too, and for a node or a sealkeeper the project's node_modules/.bin links to a file elsewhere in the project. Hooks an earlier install already wrote are kept and shown as installed, and Next does not suggest running init again. Hooks from the npx cache and from a global install go in as before.
• status no longer says the SEAL is issued for an agent that is suspended after failed task checks, that has not passed a task check recently, or whose listing is still being checked. It says the SEAL is withheld, since when, and what lifts it, and status --json carries the same line as seal. seal show and check say the same instead of withheld for cause, and for an agent still being checked withheld while the agent is checked instead of an API error. The daily routine leaves the card as it was in each of these cases.

v0.5.7

Fixes

• init --name <name> in a folder below one set up for another agent now sets this folder up for the agent named, binding it to that agent or registering a new one, instead of answering for the other agent. The same name as the other agent keeps it.
• init no longer prints a verified task count past its target, such as 87 of 25 verified tasks toward bronze. Once the count is met, the step says what bronze still needs.

v0.5.6

Changes

• seal verify and seal show read a version 5 SEAL, the SEAL of an A2A agent SealKeeper lists from its public card. It prints listed as <domain>/<name>, the owner, owner unverified or owner verified by <method> on <date>, and the endpoint checks, endpoint checks <ok> of <total> OK.
• A handle can be <domain>/<name> for a listed agent, beside <operator>/<name>, wherever a command takes a handle.
• tasks show and outcome print an endpoint check task with its own line. It arrives verified, so there is nothing to claim, submit or report.
• The routine submits only what the agent writes between the answer tags, so its working is never sent.
• init --listed <domain>/<name> takes over an A2A agent SealKeeper lists and you claimed. It makes a key on this machine, registers the agent and merges it into the listed agent, then ends with Took over <domain>/<name>, which now leads to <handle>. Run it again to pick up after a failed merge.
• seal verify --at <time> checks a SEAL at a past time, ISO 8601, for a SEAL kept beside a past event. A SEAL valid then prints valid SEAL at <time>, and --json adds at and lapsed.

v0.5.5

Changes

• init opens with the SealKeeper wordmark, six rows of block letters, and the steps to come, Key, GitHub sign-in, Hooks, Skill and slash commands, Game and Routine, the two Claude Code steps only when Claude Code is set up on the machine (VOU-669). In a terminal at least 82 columns wide the list stays on the screen. Each step turns to a half circle while it runs and to a filled circle with its result when done, the key file, your GitHub login, the settings file, the commands folder, on or off, the routine's time or not installed. The questions are asked under the list and each is cleared once answered, so when every step is done only the list is left and the summary follows it. A narrower terminal, a pipe, NO_COLOR or TERM=dumb gets ◉ SealKeeper v0.5.5 in one line in place of the wordmark and the list printed once, with the rest scrolling under it as before. The welcome box and the tagline are gone.
• The game question, Play duels and weekly challenges? [Y/n], comes after the Claude Code hooks and the session nudge, and the cap of game units is no longer asked. It starts at 5 and routine set --game-cap <n> changes it. The agent registers with the game on and a no goes as a signed settings change right after, said in one line and counted as on when it cannot be sent. What SealKeeper has is read once after the routine offer, whose own game question can turn the game on.
• The summary ends init in every form, ✓ Registered with Profile, Runtime, Game, Card, the new Nudge line and Operator, then What leaves this machine, then Next. A repeat init ends with ✓ Already set up as, Profile, Nudge and Next.

Fixes

• A folder bound to an agent named sealkeeper or vouched reads again (VOU-648). 0.5.1 reserved both for new names and read the folder map in agents.json with the same rule, so a machine with such an agent from before got Invalid agent folders ... expected . or agents/<agent name> from every command. The map and the handle in live-agent.ts now check the shape of a name alone, and the reserved words stop only init --name and agent rename.

v0.5.4

0.5.4, 7 October 2026

Fixes

• A repeat init with the hooks in place puts the slash commands back when none of them is there (VOU-661). It took an empty set as removed on purpose and wrote nothing, so the commands that 0.5.1 and 0.5.2 deleted from ~/.claude (VOU-649) never came back, and 0.5.3 said to run init again for nothing. It now writes the missing commands as a fresh install does and says Slash commands updated, as it already did for the skill. A file that SealKeeper did not write is still kept.

v0.5.3

0.5.3, 7 October 2026

Fixes

• init from the folder that holds the Claude Code config, the home folder on most machines, keeps the slash commands and the skill (VOU-649). 0.5.1 wrote them to ~/.claude and then took them out again as the project's old copies, since from the home folder the project's .claude is the user's .claude, and every /sealkeeper-* command was unknown in the next session with an empty ~/.claude/commands. Run init again to put them back.