Changelog 2026

2026

2026-10 (latest)

2026-10-11

Three ways past a human approval gate are closed. Each is a behaviour change: requests that used to succeed now return 403.

A resume id is now checked against an approval. resume_after_approval_id on intent execution was read only to see whether it was set. Any UUID was enough to skip the approval requirement, and nothing ever loaded an approval, so the id did not have to exist, belong to your organisation, or have been approved by anyone. It is now verified against an approval that a human set to approved, raised for the same agent, and unused.

And a transaction resume now needs the approval, not just the waiting row. resume_tx_id required the transaction to be in your organisation and still awaiting_approval. That is a state you reach by submitting the transaction in the first place: submit once to get the 202 and a pending approval, resubmit immediately with that id, and it signed and broadcast while the human decision was still outstanding. The resume now has to name an approved, unspent approval for that transaction. The field was also absent from the OpenAPI spec despite being accepted; it is documented now.

Both are single-use. An approval authorises one execution. A second resume of the same approval is refused, enforced in the database rather than in application code, so two simultaneous resumes cannot both win. If you built against the old behaviour, the approval now has to actually happen first, and once per execution.

Executing an approved consensus item requires the role that could have approved it. POST /v1/pending-approvals/{id}/execute checked that you were a human in the right organisation. But executing mints the single-use token that satisfies the signing gate, as that endpoint's own response says, so where a consensus policy sets approval.required_roles, a member whose role is not listed could still turn an approved decision into signing authority. Execution is now gated on the same roles as approving. Policies that do not set required_roles are unchanged.

Published. @1claw/openapi-spec 0.61.61.

2026-10-10

A platform app can add an agent to a tenant it already provisioned. Bootstrap runs once per connection — it also creates the vault, the policies and the plan tier, and none of those should happen twice — so a second call answers 409. That left no way to add an agent later at all: PATCH /v1/agents/{id} is a 403 because every bootstrapped user gets its own org, the fleet bulk-patch refuses capability flags by design, and the user-facing create needs delegation, which only the connected end user can switch on in person. The one thing that worked was that user's own dashboard, which a platform cannot automate. POST /v1/platform/connections/{id}/agents takes a template id and applies only its agent portion, leaving the vault, policies, automations and plan tier alone; new agents attach to the vault the connection already has. Configuration comes from a template rather than from fields on the request so the agent portion of a spec keeps exactly one reader, shared with bootstrap, and a capability cannot work in one and not the other.

One agent per provisioning call. An agent's API key is returned once and cannot be re-issued to a platform app — rotate_agent_key requires a caller in the agent's own org — so a response carrying several would put several unrecoverable credentials in one payload, where one logged response body takes out every agent in the batch with no way to rotate any of them. A template declaring more than one agent is now refused when it is written and again when it is used, the second check covering templates that predate the first. Nothing in use was affected: 1047 live templates declared exactly one agent, the three that declared three were 1Claw's own, and no connection had ever been bootstrapped from a multi-agent one.

The cached bootstrap response is encrypted at rest. platform_bootstrap_idempotency stores the whole response body so a retried request replays it instead of provisioning twice, and that body contains the one-time ocv_ agent key in plaintext for 24 hours. One such row was live in production. Envelope encrypted like secrets and OAuth tokens — per-row DEK, KEK in KMS, AAD bound to the connection so a ciphertext cannot be replayed against a different one. Rows already in flight are still read from the plaintext column rather than deleted: the row is the only thing stopping a retry from provisioning a second set of billable agents, so dropping it would have traded a bounded disclosure for duplicate resources.

A template asking for raw signing now gets it. Reported from production: a template created with raw_signing_enabled: true returned 201, echoed the field back on read, and provisioned an agent with it false, so sign_digest refused. Bootstrap read a fixed set of keys out of each agents[] entry and that was not one of them. Both signing flags are honoured now, and a template naming a field provisioning cannot honour returns 400 identifying it rather than accepting it and dropping it — which matters most for the spend caps, where the silent drop handed back an agent with no cap to a caller who believed it was capped. A ratchet derives the field list from the agent API, so a new field has to be classified as honoured or refused instead of quietly joining the dropped set.

A channel's admin can be named and revoked from the dashboard. owner_sender_id is what authorises admin slash commands when no sender allowlist is set, and nothing in the product could write it, while the refusal text told operators to set it. PATCH also accepted sender_allowlist and silently dropped it. Both doors were shut, so a non-developer had no route to admin commands at all. Agent → Channels now lists the senders a channel has already heard from, by name, so nobody has to hunt for a numeric ID; the first person to message a new channel becomes its admin automatically; and an explicit null revokes. The allowlist is kept as a separate control because it does more than grant admin — its first entry stops every other sender getting replies.

Runtime URLs work again. {slug}.run.1claw.co was dead from 2026-08-03 to 2026-10-08, 895 Cloud Run domain mappings in Ready: False against 2 working. The vault's service account was listed under Search Console users on the 1claw.co property but was not a verified owner, and Cloud Run's domain-mapping API checks ownership. Two things hid it for two months: a mapping failure was non-fatal, so the API returned a public_url that could never resolve, and the production smoke test checked DNS rather than TLS and reported healthy throughout.

Treasury chain and chain_id must agree. They defaulted independently, so {"chain": "ethereum"} with no chain_id recorded a treasury as Ethereum carrying Base's 8453. Signing uses the id, so the Safe rejected the signature — safe, but surfacing as an unexplained rejection rather than the configuration error it was. Now derived from the name, or refused when both are given and disagree.

Security. The login redirect check was a denylist that missed a backslash or tab in second position, both of which the URL parser resolves off-origin; it now resolves the candidate against our own origin and accepts only what stays there. The card orphan monitor windowed on request time, so an approval-gated order was flagged as an orphaned payment while it was still being filled, with a customer webhook to match; it now windows on payment time and only announces a transition it actually made. Spend-cap widenings reach the approval queue in orgs that require one, and an approved widening now applies the cap instead of completing with nothing changed. proxy-addr 2.0.8 and @modelcontextprotocol/sdk 1.32.1 close a critical IP-spoofing issue and a high in the MCP image. Referral card fingerprints can be backfilled for existing customers rather than waiting a year for each renewal.

A shell was running the agent key. 1claw setup configured Claude Code by joining its command into one string and handing it to a shell, and the parts are not all constants: the -e KEY=VALUE pairs carry an agent API key that comes from a flag or from an API response, and the daemon variant carries a socket path derived from a user-settable config dir. A value holding ; or a backtick executed. Our keys happen to be ocv_ plus base64url and our paths happen to have no metacharacters, so the realistic exposure was small, but that made the client's shell safety a property of the server's output format, which is the wrong place for it. It was a plain correctness bug too: joining on spaces breaks any path containing one. Now an argv array with no shell. Confirmed rather than assumed, which is worth saying: reverting the fix makes the new test create its canary file, on a machine where the tool being configured is not even installed, because the ; splits the line and the second half runs on its own.

The Hermes sidecar is no longer installed by a script fetched at runtime. Sweeping for the rest of that class found one more shell string, and a worse arrangement around it. Hermes fetched install.sh from the sidecar repository's default branch and piped it to a shell when the binary was missing. The script verified a sha256, but warned and continued when the checksum file could not be fetched, so withholding a single file downgraded the install to no verification at all. It was fetched from a moving branch rather than a tag, and it resolved the latest release at install time, so two installs a week apart produced different binaries. The binary now arrives as a per-platform npm package under optionalDependencies: npm pins the version through the lockfile and verifies the tarball, nothing runs a shell, and nothing reaches GitHub. An unsupported platform still installs, and falls back to a binary on PATH. install.sh stays for hand installs and now fails closed.

Terraform state is no longer a file on a laptop. It held plaintext secrets, two Stripe secret keys, an AWS access key and a postgres URL with its password, in a working tree, with no locking and no history. Thirty-nine attributes in it were marked sensitive, which controls whether Terraform prints a value and not whether it stores one. State now lives in a GCS bucket with object versioning, so a corrupted state rolls back a generation; uniform bucket-level access, so IAM is the only control; and public access prevention enforced. Encryption is Google-managed rather than customer-managed on purpose, because that state manages the KMS key ring and its keys, and encrypting it under that KMS would mean a destroyed key makes the state unreadable and Terraform unusable to repair it.

Moving it surfaced drift nobody had looked at, in two opposite directions. The tee_transit KMS key and its two IAM bindings exist and are enabled in production but were missing from state, so Terraform wanted to create them, and a KMS key cannot be created over a name that already exists, so an apply would simply have failed. And two Artifact Registry cleanup policies existed only in the cloud, so Terraform wanted to remove them, which would have stopped untagged-image cleanup on the repository every deploy pushes to. The first is imported, the second is written down. terraform plan now reports no changes, which it had not done before.

The sidecar binary ships as a package. @1claw/shroud-sidecar-linux-x64 and @1claw/shroud-sidecar-darwin-arm64 are published, so a Hermes install outside a runtime image gets a version pinned by the lockfile and verified by npm instead of fetching a script from a branch and piping it to a shell. Runtime images are unaffected by design: they compile the sidecar themselves from the pinned source and now install Hermes with optional dependencies omitted, because the resolver prefers a package over anything on PATH and publishing would otherwise have quietly moved every runtime onto a registry binary its image had never been tested against.

Our own tests were checked for whether they can still see what they assert. A family of guards reads the source of the code they protect and asserts on a slice of it. Those slices were fixed byte counts, which stop covering the function as it grows: three were reading a fraction of what they claimed, one of them 4,000 bytes of a 28,000-byte handler, and several reached past the end into a neighbour, which matters most for the guards that assert something is absent. All of them are now bounded by a real terminator rather than a number. Separately, one guard was found to be asserting something its own anchor supplied, so it held no matter what the code said: deleting the entire error message it was meant to protect left it green. There is now a check across every test in the vault that fails on that shape.

Published. @1claw/mcp 0.63.11, @1claw/openapi-spec 0.61.60, @1claw/sdk 0.61.41, @1claw/cli 0.61.31.

2026-10-08

GET /v1/platform/apps answered in ten seconds. list_apps counted connected users once per app, inside a loop, each await its own round trip. One org has 181 platform apps, so the endpoint issued 182 serial queries and took 9.99, 10.15 and 10.42 seconds across three measurements. That consistency was the tell: a fixed per-row cost rather than a slow query. One grouped query joined in memory now, so 182 becomes 2. It surfaced as HTTP 000000 in the production suite, retried three times at a ten-second limit, because the endpoint sat exactly on that timeout and a plain N+1 presented as a connection fault.

No new account could reach guided onboarding. resolvePostLoginPath hardcoded the developer flow and never asked whether the org was in the guided cohort, and it is the only decider on the post-auth path for the password form, the SSO callback, the OAuth return and email confirmation. So every new account landed on the developer flow regardless of the rollout percentage. The redirect that does check eligibility skips every path under /onboarding, so once post-login had dropped someone there, nothing could move them. The guided flow was reachable only from the sidebar link or two billing buttons.

"Reconnecting" was covering three different states in the control plane. The badge read connected-or-reconnecting, so everything that was not connected claimed to be transient. Two were not: the first attempt of any page load, where nothing had connected yet, which is what you see for the first moment of every visit; and a permanent refusal, where a 401, 403 or 404 cannot improve by being retried because the org is not entitled to the control plane or the route is not deployed. The old loop retried those forever and discarded the status code, so the caption said "reconnecting" indefinitely.

Accessibility and layout. Every label in the execution-intents card is now connected to its field, the icon-only buttons have names, and buttons nested inside links are unnested. Settings pages have one heading each, and Webhooks is no longer stranded. Twelve tables that pushed the whole page sideways on a phone now scroll inside their own cards.

Security and dependencies. The four open MEDIUM findings from the running audit are closed. Three wasmtime advisories cleared, which needed a version cap lifted, along with the critical and every blocking high advisory outstanding at the time.

2026-10-07

The agent-wide stablecoin cap is settable. It shipped enforced, returned by the API and displayed in two places, with no field anywhere to set it. UpdateAgentRequest did not carry the key, which is the proof the dashboard could not have sent it. Meanwhile the docs and the org-level spend controls page both told you to set it, and the row's own button led to a page without the field, so the only way in was a hand-written PATCH. It now lives in the Spend limits card, next to the explanation of what it bounds, and both the create and update requests carry it.

The daily spend limit is a calendar day, and it does not bound everything. The wallet-security page described it as a "rolling 24-hour cumulative cap on all transactions" that "limits total exposure even if the agent is fully compromised". Both halves were wrong: the window resets at midnight rather than decaying hour by hour, and it bounds transactions only, so an agent with cards or x402 enabled can spend past it on either. Every surface now says which cap bounds which operation, with the window stated for all four.

2026-10-06

A card order whose approval was rejected or cancelled stayed pending forever. The order sits in awaiting_approval while it waits. Ending the approval ended the approval and left the card row where it was: a pending order, displayed indefinitely, for a purchase nobody was going to make. The transaction path already had the rejection half of this cleanup; card orders had neither half, and nothing had the cancellation half. Both paths release the card now, scoped to awaiting_approval so they can never touch one that has since been approved and ordered. Orders already stranded are reconciled rather than only new ones being released correctly.

2026-10-05

One cap across all stablecoin spending (migration 307, agents.usdc_daily_limit_usd). There were three independent daily caps, each bounding one handler and none bounding the others, so "limit this agent to $50 a day" was not expressible: cap each route at $50 and the agent can still spend $150. The card path does not reference the transaction guardrails at all, so setting those and believing stablecoin spend was capped was the natural mistake. This adds one cap over x402 payments and card orders together. NULL means no cap, so no existing agent changes. The window is the UTC calendar day, matching the pay path; the card path keeps its own rolling 24 hours, because two windows disagreeing is confusing but silently redefining an existing card limit would be worse. Alongside it, an org-wide view of every agent's spend.

The cap is checked before an approval is queued, not after. A request over the cap used to reach the approval queue and only fail once someone had approved it, which spends a reviewer's attention on something that was never going to be allowed, and tells the requester nothing until then. It is checked up front and returned in the refusal.

An explicit null could not clear any spend limit. Sending null to remove a cap was indistinguishable from omitting the field, so the cap stayed. Three caps now distinguish absent from explicitly null.

Card failures stopped eating the budget, and Laso's answer is shown in full. Both rejection sites excerpted the upstream body at 200 characters, which lands inside the guidance field, ahead of payer, the one field that separates "the wrong key signed this" from "the right key is short of funds". The full body is logged server-side and the excerpt is 600 characters. x402 responses now echo the accepted entry including its network, rather than leaving a client to infer which rail was used.

2026-10-04

Referrals count people, and count the ones who paid. For a contest paying out on "registered and subscribed to Pro". The first part was a plain bug: email_verified was never set on either path that actually proves a mailbox. The column defaults to false, the OTP path never touched it, and password signup did not either, even though it only reaches account creation by presenting a token mailed to the address. Only social signup marked it. Since the countable rule requires a verified email, the leaderboard counted Google signups and nothing else, so a referrer who brought fifty people by email code saw zero. Platform-provisioned rows are deliberately left unverified, because that state is what marks a row as unclaimed.

A referral scope for Sign in with 1Claw. The code travels with the sign-in, so a partner site can attribute a signup instead of asking the person to paste a link into a form and scraping it back out of post text. Its own scope rather than folded into profile, because a referral code is a thing the holder is asked to spread: an app has to ask for it by name and the consent screen names it. A platform app can read its own users' counts, and GET /v1/referrals/me takes an optional date range.

An upgrade now claims the included runtime slot. Pro includes one runtime, but billing_kind was decided once at creation and frozen on the row, and the only caller of the claim was the create path. So creating a runtime on Free, where nothing is included, made it a $39 add-on; subscribing to Pro afterwards revisited nothing, and you paid the add-on on top of a plan that includes one. That is the obvious order to do things in, try it and then pay for it, and it was the order that overcharged. Reported from a real account showing $39 a month for a single Medium runtime on an active Pro plan.

Settings tabs keep their labels and wrap rather than hiding anything.

2026-10-03

Six more polled endpoints stopped being billed to the customer. Charging someone because they left a tab open bills them for our refresh loop rather than for anything they asked us to do, and the exemption list disagreed with the UI in six places. The largest omission was the channel messages poll at five seconds, which is 17,280 calls a day from one open page. Measured on a live Pro account: 28,470 of 33,072 counted calls were the dashboard's own polling, and the account read as 165% of its 20,000 limit on traffic nobody requested.

Three ways to reach a page that could not be reached. The admin referrals page had no link anywhere, so it worked only if you typed the URL; a test now walks the route tree and fails when an admin or settings route is missing from the nav that indexes it. Two sidebar entries pointed at the same page, both highlighting at once. And Shared Env Vars sat beside Settings rather than inside it, which is why the Settings entry carried a hand-written exclusion for it. The two worst forms on the dashboard were fixed in the same pass.

Labels connected to their fields, from 33% to 50% coverage. Worth recording the trap, because it nearly shipped: the first pass found each label's control by searching forward, which is right for a label followed by an input and wrong for a switch followed by its label. Twenty-two of the Shroud tab's sixty-two are switch rows, so each switch would have received the next row's control, and tapping "Unicode Normalization" would have toggled "Strip zero-width". That is worse than no association, because the label looks connected. Nothing structural catches it: no duplicate ids, every key present.

2026-10-02

CRITICAL: the treasury signing endpoints never verified the step-up credential. authorise_and_load_key read X-Auth-Confirm, inferred from the value's shape which kind of credential it was, and handed that kind to the policy check. That check answers "is this kind of credential permitted"; it never looks at the credential itself. So nothing did: no password verified, no re-auth token validated or consumed, no passkey challenge used up. A request carrying X-Auth-Confirm: x and x-passkey-token: x returned a signature, and the literal x also satisfied orgs configured for passkey-only. Anything authenticated as a user reached it: a stolen session, any 1ck_ key whatever its scopes, or a platform app through claim reissue. An EIP-2612 Permit signed this way drains the approved token. Live since the previous day. The send path has always verified properly; this handler copied the classification block that runs after send's verification and left the verification behind. Passwords and re-auth tokens now go through the real check, passkeys consume their challenge and must be bound to the payload, and platform-claim callers are refused outright. The old test asserted the source contained the string X-Auth-Confirm, which it did throughout.

Treasury signing refuses the payloads that grant spending power. With the step-up fixed, nothing on that path looked at what was being signed. An org requiring two approvers for a treasury send, or a spend policy refusing an unlimited approval, got neither control on an EIP-2612 Permit or a Permit2 transfer authorisation, which authorise exactly the same movement. These fail closed rather than being decoded and evaluated: decode-and-evaluate is the right end state, but half of it is worse than none, because a guard that understands four of nine shapes reads as protection and is not. The payload's chain id is also bound to the wallet's own chain, since a treasury wallet is per-chain and without this a payload naming another chain is signed by the key for this one.

One phished signature was a session. EIP-4361's domain line is an RFC 3986 authority, and userinfo is legal in one. The host extraction took everything before the first colon, so 1claw.xyz:1@evil.com read as 1claw.xyz to us and as evil.com to the wallet. On a page served from evil.com the wallet sees its own origin, raises no mismatch warning, the victim signs, and the server matched the userinfo against its own domain and minted a full user token. The challenge endpoint is unauthenticated, so the nonce is public and the whole attack is one signature collected anywhere. The helper now parses the authority properly, and the dashboard flow gets something stronger: migration 301 stores a hash of the exact issued message against the nonce and verification requires equality, which subsumes every individual field check and binds the nonce to its message. It had been free-floating, satisfying any message that quoted it.

A wallet's account could be claimed before it ever signed in. With no row holding the address, SIWE login looked up the synthetic email derived from it and signed into whatever owned that address, then bound the wallet there permanently. The synthetic address is derived from a public key, so anyone could compute it for a wallet that had never been near us, and two writers could place a row there: member invitation creates a real row for any address an org owner names, and the OIDC branch takes the email from a tenant-supplied claim. The reserved domain was refused at exactly one writer, which is one fewer than the number of writers. The victim's first sign-in landed them inside the attacker's org with their wallet bound there for good, and they could not add an email to recover. Refused in the primitive now, so invite, sub-org add, change-email and the OIDC upsert all inherit it. The verified-wallet constructor is the one door through, and it requires the address to be exactly the one derived from the wallet that signed.

Staking redemption worked for nobody, because every balance read as zero. The live service quotes points as a JSON string. The parser asked for an integer and then a float, both of which are absent for a string, so it fell through every key and returned 0. Redemption had been live and unusable since it shipped: the Staking tab showed zero available to everyone and redeem refused for insufficient points. It was caught by calling the real endpoint rather than by reading the code, which is the only way this one surfaces, because every case in the existing shapes test was written as a JSON number and so agreed with the parser instead of with the service.

Two points is a dollar, and 58 points is a month of Pro. Previously 120 points a month at $0.20 a point, which made a point worth $0.2417 as plan time against $0.20 as credit, so the subscription was deliberately about 21% better. At $0.50 a point and 58 points a month, 58 points is a $29 month or $29 of credit: the same value either way, and the choice turns on what the holder needs rather than on which one we steer them to. Credit remains the only option for an org with a Stripe subscription, since a Pro grant would overwrite the tier it pays for. A staker can now pay for Pro with points from guided onboarding, where the only previous routes to a runtime were a card for the trial or a card for Pro, and someone who arrived by signing a wallet has usually already paid in the sense that matters to them.

Wallet accounts are asked for an email address. Signing in with a wallet produces an account at a synthetic local address that nobody can receive mail at. A signature proves possession of a key, not a reachable person, so until this is answered there is no receipt, no security notice, no way back in after a lost key, and points cannot be redeemed. The ask existed in one place, inside the staking redemption card, which renders only for a wallet holding enough points, so a wallet user with no points was never asked at all. One shared component now, so someone who starts in one place and finishes in another does not meet a different form, and verifying in either silences the other. A corner panel rather than a modal, only on the dashboard, so it never interrupts a task.

The dashboard's own polling was billing the customer. Two reports from the same user turned out to be one bug and its consequence: the API-calls figure kept rising with no agents active, and the upgrade prompt kept appearing. The exemption existed, and the comment at the tagging site said the tag and the read-time filter "share one definition so they cannot drift apart". They did not share one; they were two hand-written copies, one carrying a keep-in-sync note. The predicate covered three endpoints while the dashboard polls ten, and the largest omission was the fastest poll in the app, at five seconds. One agent page left open is 17,280 billable calls a day against a 20,000-a-month plan, so roughly 28 hours of an open tab exhausts the plan with no agent activity at all.

Also. Our own CSP was blocking WalletConnect on the login page. The $5 promotional offer on the pricing page was invisible to anything without JavaScript. Guided onboarding lost its top half on a phone. The staking spent-points ledger is append-only in intent, and migration 299's own header said so, while declaring both foreign keys as cascading deletes four lines below: an org owner removing a member took the ledger rows with it and refunded every point that member had spent, redeemable again by the same wallet. Migration 300 makes those keys null on delete instead. The email-OTP attempt budget sat only on the miss branch, so the code was compared first and the counters consulted after, which meant exceeding them reworded that one failure and stopped nothing: a correct guess won however many wrong ones preceded it.

2026-10-01

A phone can sign in with a wallet. Reported from iOS Safari: "Continue with wallet" was disabled under the text "mobile wallets and WalletConnect are coming", which is a dead end on the device most stakers actually hold. Three routes now, each offered only when it exists. Installed extensions are discovered over EIP-6963 rather than by reading window.ethereum, which holds whichever extension loaded last, so with two wallets installed you got a coin toss and no way to reach the other; each now announces its own name and gets its own button. WalletConnect covers keys on a phone while browsing on a laptop, and is lazily imported, measured as absent from all ten of the login page's eager chunks. The SIWE sign-in domain is also editable in the dashboard, after production reports of MetaMask's suspicious-request warning on stake.1claw.co.

The control-plane header stopped pushing the side panel off the screen.

2026-09-27

Nothing in the streaming path cuts a generation short any more. A Google backend service times out the whole response and defaults to 30 seconds. Shroud streams LLM output through one, so every generation slower than that died mid-stream — headers sent, zero bytes, connection closed at 30.1s — while the caller retried and paid for upstream generations it then discarded. Eight of them were recorded in a single hour before shroud/k8s/backendconfig.yaml raised timeoutSec to 3600 and the GKE ingress controller reconciled it onto the backend service. The vault's own runtime-chat hop had the same shape and the same fix. scripts/check-stream-timeouts.sh now fails a build that reintroduces a short timeout anywhere in that path, and the Shroud deploy verifies the live backend service after applying — a gate that itself had to be rewritten when it failed a deploy claiming the manifest had not applied, on the strength of a lookup the deploy service account is not permitted to make.

Where a stream's wait went. Shroud recorded a frame count and a total hold time at the end of each stream, which cannot tell a slow model from a gateway that buffered the whole completion from an inspector holding everything back — three different problems with three different owners. Every streamed response now records when the upstream produced its first byte and when the client got its first byte; the gap between them is ours. Both are absent rather than zero when that byte never arrived, because "never" and "immediately" are opposite findings.

Agents lost their tools to a load balancer. MCP's streamable-HTTP sessions live in memory on the instance that created them, and Cloud Run runs up to five. Without session affinity a keepalive landed on an instance that had never seen the session, the client reconnected, and after three attempts Hermes parked the server — the agent then carried on answering with none of its tools and nothing said so. Affinity is now set in both the Terraform and the deploy, and a check fails if only one of them has it.

Four internal callbacks were naming no runtime. The vault refuses a runtime-bound agent JWT that arrives without a matching X-1Claw-Runtime-Id header. One of Shroud's five agent-JWT callbacks sent it. The other four did not: AI-spend settlement stopped being recorded (161 successes in one hour, then two against a hundred and twenty failures), the per-request inspection fee went uncharged, the signing path's key fetch would have failed for any runtime-hosted agent, and — because the budget reserve fails closed — the first customer to set a daily AI budget would have found every LLM call from that agent refused with a 503 rather than capped. All five now build their request in one place.

A query string cost a request its headers. Shroud's vault proxy carries the Intents API's list, get and simulate routes. It attached the TEE-origin header and forwarded x-request-id, idempotency-key and x-payment — then, if the path contained a ?, discarded that request for a fresh one carrying only Authorization. The rebuild existed to append the query string, but the path already held it, so the block changed nothing except what it dropped: a paginated list arrived without the header the vault uses to tell a TEE request from any other, and without the caller's x402 payment proof. It also re-switched on the method with only GET and POST spelled out, silently reissuing a PUT, PATCH or DELETE as a GET.

"Restart the runtime" was the worst possible advice for a runtime that was starting. Cloud Run accepts a service before it publishes an address, and a runtime spends its first minute in that state after a restart. The vault's lookup answered None for four different findings — ready, exists-but-no-address-yet, not there, and the Cloud Run API not answering — so a runtime mid-provision was reported as one with no address, and eleven consecutive chat attempts over seventy seconds each told the user to restart the thing that was already starting. The lookup now keeps the four apart; a service that exists without an address is "starting", which routes to the message that was already correct and to the dashboard's three-minute retry budget rather than eighty seconds.

RENEW-H1. POST /v1/runtimes/{id}/agent-token/renew hands back a token carrying runtime_image, the claim a runtime_image_in policy condition reads to decide whether a caller is inside an attested container. It checked that the caller was the runtime's agent but not that the caller's token was the runtime's — so an ordinary agent JWT, exchanged from an ocv_ key, could be traded for one carrying the attested image's digest, from anywhere. CallerIdentity now carries the runtime binding from the JWT claim, and renewal refuses a credential that was not minted inside the runtime it names. A production test covers the refusals; the successful renewal happens inside the container and is checked by reading a running runtime's own logs.

Chat. A turn the platform cut off at the five-minute request limit no longer looks finished — it is marked in the transcript and in the export, and the agent is not handed a guillotined answer as context on the next turn. The composer accepts an over-length paste and says how far over instead of silently dropping it; the message editor had the quieter half of the same bug, truncating at the browser level so the tail of a pasted log disappeared. Find-in-conversation, session token/reply/tool-call totals, and a Markdown transcript you can paste into a bug report. Stay unlocked now works — it rendered only inside the locked early-return, so the button existed on a screen where pressing it could not help. The tools card shows what the agent actually has rather than what the template usually ships with, and a runtime running an image older than the credential-renewal change is told so.

Runtime tools stopped blaming the user. Five tool families — GitHub, Google, Slack, notify and social — collapsed every failure into "you have not connected it", including an expired token, a network error and a permission the connection genuinely lacks. Each now records why the lookup failed and says that instead. The notify tools no longer assert a channel does not exist when the check itself could not be made.

Discovery documents describe what is shipped. server-card.json, ai-catalog.json and the /.well-known/mcp endpoint 1claw.co serves are how an agent decides what this product is and which package to install. They advertised @1claw/mcp 0.61.40 against a published 0.63.6, and the number of MCP tools appeared as 160 on the marketing site, 30 in the document agents fetch, and 160 in the serverInfo.instructions a client reads on connect — against a real 161. The parity check that was meant to catch this compared everything against the OpenAPI spec's version, read only the first catalog entry, and ran in no workflow. Each artifact is now checked against the thing it actually describes, counts included, from a manifest generated out of the live tool catalog. The Homebrew formula was installing @1claw/cli 0.61.22 against a published 0.61.29 and is now checked too.

Published. @1claw/mcp 0.63.7, @1claw/openapi-spec 0.61.43, @1claw/sdk 0.61.36, @1claw/agentkit 0.57.1.

2026-09-26

A long-running runtime stops losing its credential. A runtime's ONECLAW_AGENT_TOKEN is a ~2h JWT that Cloud Run resolves from Secret Manager when the instance starts, and never again. A fresh secret version is published every 45 minutes so a cold start always reads a live one, but an instance that stayed up past the TTL kept what it booted with — so the more continuously a runtime was used, the sooner its credential died, and the only remedy was for the user to restart it. Hermes caches the token at boot, so its whole MCP toolset went with it: an agent could lose every tool it had and carry on answering as though nothing had happened. Containers now renew in place against POST /v1/runtimes/{runtime_id}/agent-token/renew at about 70% of remaining life, authenticated by the token being replaced. It grants nothing new — the same claims with a later expiry — is exempt from the monthly request quota, and stops working the moment the token lapses, the agent is suspended, or the runtime is no longer deployed. A loopback MCP relay inside the container hands the current token to the agent's MCP client, so the agent's tools follow the renewal without the agent knowing. A runtime started before this ships needs one Restart to pick it up, and the chat panel says so when that applies.

Hermes was shipping without Hermes. An image built with a broken npm cache owner installed nothing and said nothing: the installer's error was discarded, the build succeeded, and the container came up with no agent. Three causes, all fixed — the npm cache is chowned to appuser, the C++ toolchain the installer needs is present, and a failed install now fails the build. Every agent template is guarded against the same shape.

The honeytoken tripwire had never once fired. Two repositories asked the database SELECT 1 and decoded the answer as an i64 whether or not a row came back, so the decoy-credential tripwire and the token-revocation check both read as "no match" on every call. Both now ask SELECT EXISTS(...) and read a boolean, and a test scans for the class.

The skill was published three times and all three disagreed. skill/SKILL.md is the published package; docs/static/skill.md and dashboard/public/skill.md are what agents actually fetch from docs.1claw.co/skill.md and 1claw.co/skill.md. Nothing kept them in step. They are now one file with a check that fails when the copies drift.

Chat. Stop a turn, retry an answer, copy a message, edit a message, type while the agent is answering; / opens the commands and they match what this agent can actually do; tool results are shown as shape rather than content; the history each turn resends is bounded, and you are told when that bites; saved sessions can be filtered; the unlock warns before it lapses rather than after; "new chat" no longer calls itself a delete. Errors inside the runtime stopped being reported as sign-in problems, and the remedies point at Restart, which is one button, instead of describing a two-step stop-and-start.

Errors that say what happened. Lock contention is reported as a queue rather than a fault; a runtime that failed to start says why instead of pointing at logs it never wrote; a secret whose key has been destroyed is 410 Gone, not a 500. The KEK health alarm means something again and Cloud Logging can filter on the severity.

2026-09-25

Runtime chat talks to the agent, not through a bridge. Dashboard chat now routes to Hermes's own native API server where the template has one, with a per-conversation Hermes session and a badge showing which model actually answered; OpenClaw gets the same direct path. Tool chips are richer, sources are clickable, and the panel auto-retries a cold-start or "enabling chat" 503 instead of presenting it as a failure. Runtime chat follows the agent's configured LLM default rather than pinning openai/gpt-4o-mini.

The runtimes surface, reworked. Preset specs come from one source (small-cc/large-cc labels included), the create wizard has idle-timeout preset chips and a working slider range, the list supports full-row click, the detail view has real ARIA tablist semantics, and Configuration gained an LLM provider/model editor with OpenRouter added to the registry. The runtime's image version and when it last changed are shown — image_updated_at is recorded when the running digest actually changes — and rollback confirms in a dialog rather than a native confirm(). One-click enable recommended tools for existing runtimes. Advanced config is no longer dropped when provisioning a new agent alongside a runtime, and a runtime's bound vault access policies are linked from its detail page.

Onboarding. The guided runtime steps are tier-aware and disclose Pro at $29/mo; the BYOK flow surfaces every Shroud provider, including OpenRouter, Cohere and Venice.

Shroud. Non-streaming Anthropic→OpenAI conversion, so a client that asked for a complete response gets one in its own shape. A secret-matching automaton that was burning CPU at idle was rebuilt as a contiguous NFA, and the HPA can scale down again now that an unservable custom metric is gone.

2026-09-24

x402 accepts more than one rail. Inbound 402 settlement now takes Base USDC and RHC USDG.

1claw run. @1claw/cli 0.61.23–0.61.27: run a command with an agent's resolved environment, --save-agent-key, provider/model namespacing, wider proxy-client coverage, and a Gemini example that works. Docs updated alongside each.

2026-09-23

Three coding-agent compatibility bugs, all found the same day from real OpenCode traffic through 1claw proxy. An OpenAI-compatible client (OpenCode, via @ai-sdk/openai-compatible) pointed at a Claude model sends genuine OpenAI-shaped requests regardless of the model name — three places in Shroud assumed otherwise. (1) CommandInjectionFilter scanned the whole raw request body, so a coding agent's own system prompt/tool descriptions (which legitimately mention shell command chains) tripped shell_command_chain/shell_redirect at Critical severity and blocked every request; it now scans only message roles that can actually carry untrusted content (user turns, tool/context results), never the system prompt or the model's own replies. (2) Anthropic's Messages API requires max_tokens; OpenAI's does not — a request missing it was hard-rejected by Anthropic/Vertex with max_tokens: Field required; ensure_anthropic_max_tokens now fills in a default (from OpenAI's max_completion_tokens alias if present, else 4096) only when the field is genuinely absent. (3) A tool-use response ("Write" tool) crashed the client with OpenAI Chat received content after the finish reason — two independent bugs: determine_upstream_path's "already versioned, keep it" shortcut forwarded a client's /v1/chat/completions path straight to Anthropic (which doesn't serve it) instead of translating to /v1/messages, and no Anthropic→OpenAI stream converter existed anywhere in the crate, so even a correctly-routed request relayed raw Anthropic SSE (content_block_delta, message_delta, …) to a client that only understands choices[].delta/finish_reason. Both fixed; the new AnthropicToOpenAiStreamConverter sets finish_reason only from message_delta's stop_reason or message_stop, never content_block_stop (which fires after every content block, not just the last one). A related gap found while building a client-compatibility fixture harness: an OpenAI-shaped "role":"tool" message routed through the Anthropic parser fell through to Unknown and silently escaped the injection scan — map_anthropic_role now recognizes it too.

Client-compatibility fixture harness. All three bugs above shipped because the existing tests used hand-written example strings, never a real client's actual request shape. shroud/tests/client_compatibility.rs runs every fixture in shroud/tests/fixtures/clients/ through the real inspection pipeline — fixtures are sourced from each client's actual public code where possible (OpenCode's real system prompt + tool descriptions from sst/opencode, Codex's real system prompt from openai/codex), clearly labeled REAL/RECONSTRUCTED/APPROXIMATED where exact source wasn't recoverable. New shroud-check CI job runs it (and the rest of Shroud's suite) on every PR touching shroud/** — nothing did before. 1claw proxy --capture-dir <path> (CLI 0.61.20) writes every outgoing request (secrets redacted) to disk, so a future real failure can become a permanent fixture in one step instead of hand-reconstructing what the client sent.

Two more bugs from the same investigation. A tool-use request from the same OpenCode-targeting-Claude traffic was hard-rejected with tools.0: Input tag 'function' found using 'type' does not match any of the expected tags: OpenAI's function-calling tool schema ({"type":"function","function":{name,description,parameters}}) has no Anthropic equivalent, and OpenCode sends its bash/edit/grep/write/glob tools in that shape regardless of the target model. convert_openai_tools_to_anthropic now converts only genuinely OpenAI-shaped entries (type: "function" with a nested function object) to Anthropic's custom tool shape; an already-Anthropic-shaped tool (Claude Code, on the native SDK) passes through untouched. Separately, reasoning_effort: Extra inputs are not permitted — Anthropic's Messages API rejects any top-level field it doesn't recognize outright, unlike OpenAI's silent-ignore behavior; strip_openai_only_fields_for_anthropic now removes a denylist of 19 known-OpenAI-only fields (reasoning_effort, frequency_penalty, presence_penalty, logit_bias, response_format, parallel_tool_calls, …) before forwarding an OpenAI-shaped body to Anthropic — a denylist rather than an allowlist, so a real Anthropic field this list doesn't know about is never silently dropped. Both are covered by the client-compatibility fixture suite alongside the existing max_tokens/tools checks.

Codex (OpenAI Responses API) targeting Claude models. Codex's CLI always sends OpenAI's Responses API shape (instructions/input[], no messages at all — current versions have no chat/completions fallback), which shares no top-level keys with chat/completions, so none of the normalization fixes above ever fired for it: a Codex request targeting a Claude model was forwarded essentially unconverted and hard-rejected. convert_openai_responses_to_anthropic_messages reshapes the whole body (instructions/developer-role items → system, input[] → messages[], function_call/function_call_output → tool_use/tool_result content blocks, flat type: "function" tools → Anthropic's custom shape); a new AnthropicToOpenAiResponsesStreamConverter converts Anthropic SSE into real Responses API events (response.output_text.delta, response.function_call_arguments.*, response.completed, …) for Codex's stream: true traffic. A same-day follow-up fixed determine_upstream_path, which still forwarded a Responses-shaped, Anthropic-targeted request straight to /v1/responses on Anthropic's real API (which doesn't serve it) instead of translating to /v1/messages — the same bug shape as the chat/completions path fix above, just not extended to cover this path; caught because the original change's verification ran cargo test --lib, which never executes router.rs (a bin-only module, not included in lib.rs) — CI now also runs cargo test --bin shroud. Codex's own built-in tool types (namespace, web_search, …) and Responses-only input item types (reasoning, local_shell_call, …) have no Anthropic equivalent and are dropped rather than forwarded unconverted, flagged as a follow-up. New real fixture codex_responses_real.json, captured via 1claw proxy --capture-dir from an actual codex exec run.

Examples reorganized. The four separate shroud-demo/shroud-llm/shroud-router-key/shroud-security example projects are now one examples/shroud/ with four numbered sub-examples (01-basic-demo, 02-llm-billing, 03-router-key, 04-security-offline) and a README explaining which to pick; doc links updated to match. Three new examples: Browser Bridge (@1claw/browser-bridge — the agent drives the page with real puppeteer-core, a separate process types the password, the agent never receives or reads the value), Telegram Channel (register a bot, send/list messages through the Channels API), and Passkey Safe (a Gnosis Safe whose only owner is a WebAuthn passkey via Safe's SafeWebAuthnSharedSigner — no private key exists anywhere for the Safe).

Guided onboarding: coding agents get the whole flow, not just MCP. The coding-agent path now also walks through connecting Codex, OpenCode, OpenClaude, or Claude Code to Shroud/LLM Token Billing via the local 1claw proxy — one command, both MCP and LLM routing configured. 1claw setup gained real Codex/OpenCode MCP auto-configuration (~/.codex/config.toml [mcp_servers.1claw], ~/.config/opencode/opencode.json mcp.1claw) instead of only listing traditional GUI clients, plus install hints (e.g. npm install -g @openai/codex) next to any client it didn't detect. Fixed a same-tab Stripe-checkout redirect that lost in-progress wizard/chat state on several pages (checkout now opens in a new tab); fixed a race that sent onboarding-eligible users to the wrong (developer) onboarding path instead of the guided one; reworked the OIDC Federation (Anthropic WIF) setup UX to auto-fill the audience and walk through registration step by step.

Platform-default web search. Agents with no BRAVE_API_KEY/TAVILY_API_KEY/SERP_API_KEY/binding of their own now get a working web_search tool by default: POST /v1/tools/web-search, proxied server-side through a shared 1claw-provided Brave Search key (never reaches a tenant runtime), hard-capped at 900 requests/month platform-wide (platform_web_search_usage, comfortably under Brave's free-credit volume).

Adoption/usage metrics, one source for the dashboard and the investor report. New GET /v1/admin/stats/growth-timeseries?vertical=&period= (15 verticals — signups, subscriptions, Shroud usage/security, execution/transaction intents, vault/runtime/memory usage, automations, embedded wallets, platform API — gap-filled 24h-hourly/7d-daily/30d-daily, with a period-over-period delta) and GET /v1/admin/stats/retention?window_days= (% of orgs older than the window still active). Wired into the live admin analytics dashboard (/settings/admin/analytics, a new Adoption & Usage section plus a retention tile) and a rewritten weekly investor report: the email body is now a curated summary (a 24h/7d/30d table across all verticals, real charts for the four highest-signal ones, a retention card, a cumulative-growth curve), full per-vertical/per-window detail moves to the PDF attachment. Charts are rendered locally as SVG (scripts/lib/svg-charts.mjs) instead of through a third-party charting service, which previously carried real MRR/revenue figures in a public URL. weekly-investor-report.yml gained a dry_run input that renders against real data without emailing or writing the trend-snapshot row. Also fixed a long-silent bug: /v1/admin/stats's Memory stats queried a table (agent_memory) that never existed — the real table is agent_memory_entries — so those four fields always silently read zero.

Live-tested every genuine coding-agent CLI against 1claw proxy. Claude Code, Codex, OpenCode, OpenClaude (@gitlawb/openclaude), and Goose (Block's agent) all confirmed clean — Claude Code/OpenClaude/Goose needed no fixes, sending either native Anthropic or the same OpenAI-shaped traffic the fixes above already cover. Gemini CLI (@google/gemini-cli) is different: it speaks Google's own native contents/systemInstruction format to /v1beta/models/{model}:generateContent, not OpenAI's. The proxy's provider auto-detection had no case for that path and defaulted to openai, so Shroud couldn't parse req.messages from the mismatched body and fell back to a raw-full-body scan — false-positive-blocking on ordinary shell syntax in Gemini CLI's own system instructions, the same false-positive class as bug (1) above, here caused by a provider mislabel rather than a scan-scope bug. @1claw/cli 0.61.21 now recognizes /v1beta/models/{model}:(generateContent|streamGenerateContent|countTokens) and routes it as provider: google, mirroring the existing /v1/messages → anthropic special case. New real fixtures openclaude_anthropic_real.json and goose_anthropic_real.json in the client-compatibility suite; see IDE & tool setup for per-client instructions.

Audit remediation. STRIPEPATH-C1 (a client-supplied setup_intent_id was path-injected into a Stripe API call made with the platform's live secret key), SETUPINTENT-H1 (the trial gate never checked the SetupIntent belonged to the caller's org), AIBUDGET-H1 (daily AI spend was a non-atomic check-then-record; now an atomic reserve/settle against agent_daily_ai_spend/agent_daily_ai_spend_holds), AIMODEL-H1 (the client-supplied X-Shroud-Model/-Provider headers could diverge from the body actually billed; the body now wins), TXBUDGET-RACE (the same class of race in value-based daily transaction budgets, closed by widening the existing daily-tx-cap advisory lock), AUTOPARK-M1 (a nested execute_intent step inside a parked automation was allowed through), AUTORATE-M1 (automation-triggered binding executions skipped the rate/concurrency guardrails the direct execute path enforces), RUNTIMEROLLBACK-M1 (a runtime restart proceeded even when stopping the old container failed), CHANAUTORESPOND-M1, PAYPAUSE-M1.

Dashboard 2026-09-22

Guided onboarding. A SetupIntent-gated free trial (card required, not charged unless kept) alongside the existing subscribe-to-Pro path, an AI spend/pricing/budget engine, the first version of the weekly investor report (adoption/usage/revenue over the trailing 30 days, HTML email + PDF, Stripe MRR pulled live), and a large dashboard UX restructure. Migs 281–283.

Dashboard 2026-09-21 (b)

One way to do each thing. /agents/new and /vaults/new redirect to the wizards (the agent wizard's Advanced step now carries auth method with mTLS/OIDC fields, scopes, token TTL, expiry, environment and memory; sub-agents are linked from the wizard rather than offered as a second button); the runtime list's Quick Create is gone; every list and empty state has one primary button. One Inbox (/inbox: Agent approvals · Team consensus · Wallet proposals, one badge) replaces three sidebar entries; the old routes redirect. Settings are grouped (You · Organization · Security · Developers · Billing) with a search box; Billing is Plan / Usage / Payments / Add-ons; Security is Sign-in / Data protection / Guardrails / Honeytokens with org-wide policies under Advanced. Forms: the access-policy form is three fields in Simple mode with a plain-English preview of the policy it will create (effect, priority, conditions, consensus under Advanced); the secret form is path + value (type, tags, description, expiry, access cap under Advanced). Pages: platform app tabs get Simple (Overview · Users · Templates + More), the vault page renames Policies to Access, explains env vars, and keeps encryption settings under Advanced; Treasury has a first-run explainer. Wayfinding: sidebar says Agents / Runtimes; a persistent setup checklist on the Overview; one status pill style across lists.

v0.61.49 (2026-09-21)

AI spend. Every LLM request through Shroud is now priced at ingest from a per-model price card (mig 281: shroud_activity.cost_micro_usd + priced; llm_model_prices seeded with September 2026 list prices for Anthropic, OpenAI, Google/Gemini, Mistral, DeepSeek, xAI, Groq, Together, OpenRouter, Venice, Ollama; existing rows backfilled — 8,013 of 8,016 in prod). New GET /v1/spend/ai?from&to&interval&agent_id&provider: totals with the previous window, a series by provider, breakdowns by provider / model / agent (each agent with its daily_budget_usd, today's spend, utilisation and requests blocked for budget), router-key spend caps, credit balance and 1Claw inspection fees; GET /v1/spend/ai/export.csv; the price card at GET/PUT /v1/spend/ai/prices, DELETE /v1/spend/ai/prices/{id}, POST /v1/spend/ai/reprice (owner/admin). The dashboard control plane gains a Spend tab (9) — Ramp-style: period/provider/breakdown/compare filters, KPI cards with deltas, stacked spend-over-time, provider donut, top models, agent table with budget bars, limits panel, price editor, CSV export. OTEL: each request also emits ai.cost_usd, ai.tokens.input, ai.tokens.output (attributes agent.id, ai.provider, ai.model, ai.action) so an org's own collector gets the same numbers. The system overview's inference spend now reads the priced rows (the ledger it read before was never written). Shroud enforces daily budgets from the same card (Shroud fetches GET /v1/admin/llm-prices every 5 min, prices each request identically, and re-syncs each agent's UTC-day counter from GET /v1/shroud/activity/today every minute — the old flat $0.01/1K in-memory counter that reset 24 h after first use and was lost on restart is gone); budget blocks are 429 with the spend named; allowed responses carry x-shroud-budget-limit-usd / -spent-usd / -remaining-usd. @1claw/sdk 0.61.33 (spend.ai/listPrices/setPrice/deletePrice/reprice), CLI 0.61.19 (1claw spend ai|export|prices). Spec 0.61.40.

Dashboard 2026-09-21

Beginner and advanced, everywhere. Every wizard (runtime, agent, sub-agent, vault, platform, register-agent form) and the agent detail page share one Advanced switch, remembered per browser and also in the command palette. Simple mode asks only for what cannot be guessed; every optional block becomes a one-line summary of the defaults with Customise. The runtime wizard is now five steps with agent frameworks first (Hermes, OpenClaw, OpenCode, OpenClaude, then Python/Node/binary/Docker), two-column template cards, three-column presets and a pre-filled name; Simple mode skips Runtime Options and each step fits on one screen. A greyed Next always says what is missing. The automations chooser leads with Assist (the easy way) over the step-by-step wizard.

Navigation. ⌘K/Ctrl+K command palette (pages, create flows, agents/vaults/runtimes/automations, pending approvals, theme, wizard mode; ? lists shortcuts); g+letter and n+letter two-key shortcuts. Phones get a hamburger, a bottom tab bar (with the pending-approval count) and a slide-in sidebar; tab strips scroll instead of overflowing. The Activity sidebar link is gone — it is the Overview tab on the dashboard.

Polish. Skeletons in place of spinners on detail pages and the consensus/proposals/sharing/cards lists; teaching empty states (what the thing is for, and the first action) on vaults, agents, consensus and proposals; one Danger Zone at the foot of every detail page (typed-name confirmation) — vaults, agents, runtimes, and automations, which gained a delete; an approval needs you toast when the pending count rises while you are elsewhere (badges refresh every 30 s). Discovery artifacts (.well-known/mcp/server-card.json, ai-catalog.json, the MCP serverInfo) now report spec 0.61.39 and 160 tools.

NemoClaw / NanoClaw. Documented why neither can be a hosted template (each needs a container runtime on the host) and how to use 1Claw inside them; an OpenShell-backed provider stays on the roadmap.

v0.61.48 (2026-09-20)

Clients for the uplift. @1claw/sdk 0.61.32 (runtimes.provision/resolvedEnv/rollback, schedule on update, org.overview), CLI 0.61.18 (runtime provision|env|rollback, runtime update --schedule-cron/--stop-after/--clear-schedule), MCP 0.63.6 (manage_runtime gains restart/rollback; new runtime_env — 160 tools). Example examples/automations/engine-v2-automation.ts walks retry/continue, callback park, for_each, versions, rollback and re-run end to end. Dry run no longer flags {{resume.*}}, {{item}}, {{index}} or nested-body templates as unresolved.

Runtime console (uplift batch D). The runtime page opens on an Overview tab: status, last heartbeat, idle auto-stop countdown, hours and egress this month, last image scan, the attested image and the previous one with Roll back & restart (POST /v1/runtimes/{id}/rollback; previous_image_digest recorded at each start whose resolved image changed), a schedule editor, and the resolved environment (GET /v1/runtimes/{id}/env/resolved — every variable by source with vault-derived and minted values masked). Provision in one call: POST /v1/runtimes/provision creates or reuses the agent, its keys and default-vault grant, the runtime, and starts it, under every existing gate; the New runtime wizard's Agent step gains New agent. Spec 0.61.39.

v0.61.47 (2026-09-20)

Runtimes (uplift batch C, part 1). Attested image: runtimes record image_digest (Cloud Run's resolved image, digest form), runtime-minted agent tokens carry it as runtime_image, and access policies can require it with conditions.runtime_image_in (strict: no claim → refused) — mig 278. Scheduled runtimes: schedule {start_cron, timezone, stop_after_secs} on PATCH /v1/runtimes/{id}; a leader-elected scheduler starts on the cron through the same gates as a manual start and stops after the window (mig 279). Reconciler: every ten minutes the controller also probes non-running rows and stops any container still alive at the provider (orphaned compute after a half-failed stop/delete). Engine fixes from prod: parks were marked failed right after parking; {{run.*}}, {{resume.*}}, {{item}}/{{index}} template roots; nested step bodies keep their templates until they run; a parked run exposes its partial step_results; webhook_signature: null removes the scheme. Already present and now documented: custom images on the docker path are allow-listed by registry prefix; per-user log-stream cap + 15-minute idle timeout. Spec 0.61.38.

v0.61.46 (2026-09-20)

Dashboard: one overview of the whole system. New GET /v1/org/overview?hours= returns inventory, activity in the window, spend, health signals and a 7-day trend in one call (every subquery org-scoped; guard test). The dashboard control plane gains an Overview tab (needs-attention list, activity, inventory, spend, trend — each number links to where you act), and the former Activity pages are now tabs on the same screen (Shroud, Risk, Audit) with Topology still first; /platform-activity/* redirects, ?view= deep-links, keys 1–8. @1claw/sdk 0.61.31 (org.overview()), spec 0.61.37.

Automations UX (uplift batch B). Dry run: POST /v1/automations/{id}/dry-run and POST /v1/automations/dry-run (unsaved spec) render every step after template substitution — resolved fields, side effect, on_error policy, templates that resolve to nothing, conditions, the budget crossing — with nothing done; Preview run in the editor and on the detail page. Run timeline: step results record duration_ms, attempts, continued and the resolved input (credentials removed); the dashboard run dialog is a timeline with expandable input/output, attempts and cost, a parked-run banner with inline Approve/Reject (or "skip the wait" / "continue without the callback" for owners), and Re-run from here on every step (POST …/runs/{run_id}/rerun {from_step} — a new run seeded with the finished run's results). Versions panel on the detail page with one-click rollback. The editor knows the v2 step types (wait_until, awaiting_callback, for_each, call_automation) and has Step name and On error (fail / continue / retry ×N with backoff) on every step. Fixed: the dashboard read run fields the API never returned (trigger, completed_at, step_type), so the Runs table showed blank triggers and a step card threw on open — runs are now normalised in one place. @1claw/sdk 0.61.30 (dryRun, rerunFromStep), spec 0.61.36.

v0.61.45 (2026-09-20)

Automation engine v2 (runtime & automations uplift, batch A). Every step may carry an on_error policy — fail, continue, or retry with bounded linear backoff (fund-moving and parking steps are never retried). Specs may carry a budget (max_tokens, max_cost_cents, max_steps, the last counting every loop iteration and sub-workflow step). Two new parks stop the 300-second clock like approval_request does: wait_until (the scheduler wakes it, up to 72 h) and awaiting_callback (the run gets a per-run token at start as {{run.callback_url}}; POST /v1/automations/{id}/runs/{run_id}/callback/{token} continues it with the body as {{resume.*}}). New control flow: for_each (bounded fan-out with {{item}}/{{index}}) and call_automation (inline sub-workflow, depth 1, recorded as its own run with parent_run_id). Agent-created automations may now use execute_intent — network access only through a binding a human created, with the binding's allowlists, conditions, secret scan and approval policy applied in the executor exactly as on the direct execute path; a policy that wants a human parks the run and re-runs the step once approved. Versions: every workflow_spec is kept (mig 277 automation_versions; GET …/versions, POST …/versions/{n}/rollback); runs record spec_version. Widening edits (adding fund-moving or network-reaching steps, raising a budget cap) go through control-plane consensus under the new automation.widen action; PATCH now validates step types like POST always did. Idempotent triggers: {input, idempotency_key} / Idempotency-Key on trigger and webhook (GitHub delivery ids and Stripe evt_ ids are used automatically) — the same key returns the existing run with 200. Signed inbound webhooks: webhook_signature {scheme: stripe|github|hmac_sha256, secret, header?, tolerance_secs?} on a webhook automation; the secret lives encrypted in the agent-keys vault and an unsigned or mis-signed delivery starts nothing. Run responses carry paused_reason, paused_until, paused_expires_at, spec_version, idempotency_key, parent_run_id; new run statuses waiting and awaiting_callback. @1claw/sdk 0.61.29 (trigger(id, input, {idempotencyKey}), listVersions, rollback, callback, StepOnError, RunBudget), CLI 0.61.17 (automation trigger --input --idempotency-key, versions, rollback), MCP 0.63.5 (trigger_automation takes idempotency_key; the SDK/MCP trigger body previously sent a bare object the vault ignored). Spec 0.61.35.

v0.61.44 (2026-09-20)

Security audit remediation (2026-09-20 cycle: 8 HIGH, 8 MEDIUM, 4 LOW). Router-key tokens are routing-only: the vault refuses every route outside the gateway surface (inspection debit, vault list, provider/api-key reads, agent self, bankr leases, activity, health) and Shroud refuses execution/transaction paths for them. Passkey-Safe agent spends run the org's signing policies and the consensus gate like every other send, and both relayer-key fetches go through one wallet-access-gated, audited primitive. POST /v1/automations/{id}/runs/{run_id}/resume no longer decides the approval — a pending one is 409 with a pointer to POST /v1/approvals/{id}/decide — and a parked run pins its workflow_spec (hash + copy) and fails rather than run an edited workflow under an old approval. Tool bindings require the agent (or the creating user) to already read the secret. Deactivating a parent agent stops its children's inherited policies. Pairing approve/deny is compare-and-set (409 on replay). Included runtime slots are claimed under a per-org lock. K_enclave release fails closed if its audit row cannot be written, pins RS256, and refuses secboot=false / non-confidential hwmodel. Recovery codes are spent on redemption (a fresh one is shown). Shroud: the client IP is the TCP peer, with X-Forwarded-For believed only behind a trusted proxy (SHROUD_TRUSTED_PROXY_CIDRS), and a per-IP pre-auth rate limiter (SHROUD_PREAUTH_RATE_LIMIT_PER_MIN, default 600) sheds unauthenticated floods; deploy-shroud.yml attaches Cloud Armor network DDoS protection to the NLB and refuses to retire the L7 Ingress until it is verified. CI: docker-build and deploy-vault.yml both gate on the migrations applying to a fresh Postgres. Dashboard: Settings → Connected Apps gains Connect Muse.

v0.61.43 (2026-09-20)

Router-rail fixes found in production, and the site catches up. The inspection-fee debit now reaches the vault: Shroud calls it over SHROUD_VAULT_INTERNAL_URL (the public API host proxies only /v1/*) and the route lives in the authenticated group rather than the Intents-gated one (a router-key agent need not have the Intents API on) — before this every router-key POST failed closed. The 1 MB router-rail cap runs right after authentication, ahead of provider-key resolution (413, never a 401 about a missing key). POST /v1/x402/topup claims the payment proof before looking the wallet up, so a replay never opens a shadow org. Shroud rollouts that stall on node-pool capacity with ≥ 2 new pods ready are treated as deployed; the HPA no longer scales on memory. Docs: API reference gains child agents, router keys, tool bindings, connectors/event subscriptions, charts and the x402 top-up; /for-ai gains four Shroud cards; 1claw.co/shroud gains the drop-in section; the billing page explains what credits pay for. New example examples/shroud-router-key. @1claw/sdk 0.61.28, oneclaw 0.61.13 (READMEs). Ops runbook internal-docs/runbooks/shroud-ai-router-rail.md.

v0.61.42 (2026-09-20)

Format adapters, the offline conformance gate, Signal T0, the egress lock. Shroud's canonical IR now covers the OpenAI Responses API (instructions + input items, function_call / function_call_output; streamed response.output_text.delta inspected per frame and response.function_call_arguments.* assembled like chat tool calls) and MCP JSON-RPC (tools/call, sampling/createMessage). tests/conformance_track_a.rs is the offline half of the conformance suite — 102 vectors from tests/conformance/config.toml's bars (single-arg, DSN-embedded, streaming-split at every third byte of every secret, prompt-cache stability, and the adversarial set: unauthorised tool, exfil host, wrong argument, markdown-image exfil, amplification, bad checksum, legacy tag) — currently leak rate 0, rehydration 1.0/1.0, adversarial refused 1.0. Blocked-request audits carry Signal T0 fingerprints (SHA-256 + 64-bit SimHash over 3-word shingles of the redacted, placeholder-stripped span; hashes only, no verdict changes). k8s/networkpolicy-egress-fqdn.yaml names the vault, providers, KMS, ACME, facilitator and RPC hosts and drops the 0.0.0.0/0:443 rule when SHROUD_EGRESS_LOCK=true (needs GKE FQDN network policies). @1claw/sdk 0.61.27 / oneclaw 0.61.12 / CLI 0.61.16: tool bindings (createToolBinding…, agent bind-secret | tool-bindings | unbind-secret). Spec 0.61.34.

v0.61.41 (2026-09-19)

Placeholders the model can place but never read; rehydration only inside the enclave. With the attestation-released enclave key, Shroud now replaces vault secrets in prompts with ⟦sk:{type}:{tag}{ck}⟧ placeholders — deterministic per (org, secret), so prompt caches survive; rotated with the secret; checksummed; typed (pg-dsn, bearer, pem, …) — and keeps a per-org reverse index in enclave memory (legacy [REDACTED:#…] stays when no key is held). POST /v1/agents/{agent_id}/tool-bindings (GET, DELETE …/{binding_id}; human-only; migration 276 secret_tool_bindings, RLS) records which secret may be rehydrated for which agent, tool and argument (JSON pointer) and toward which destination hosts. The vault forwards an agent's bindings with every TEE execution; the enclave substitutes within strings only where a binding matches the resolved destination host, refuses (403) unbound arguments, wrong hosts, bad checksums, unknown tags and >4 repeats, and reports the secret paths it used, never the values. A non-overridable egress deny-list (cluster-local services, the vault and gateway hosts, ONECLAW_EGRESS_DENIED_HOSTS) runs before any customer allowlist. Spec 0.61.33.

v0.61.40 (2026-09-19)

Router rail is paid from request one; the ledger is micro-USD; the x402 agent door opens. Migration 274 moves the prepaid ledger to micro-USD (organizations.credit_balance_micro_usd, credit_transactions.*_micro_usd; the cents columns every reader used become derived, so nothing that read them changes) and GET /v1/billing/credits/balance / the subscription response now carry balance_micro_usd and dollars at the ledger's precision. Shroud debits $0.005 per inspected router-key request at accept (POST /internal/v1/shroud/inspection-debit: idempotent on the request id, FIFO across top-ups, counted against the key's spend_cap_usd, TEE-origin gated); an in-flight stream is never cut off for billing — the next request gets 402. Router-rail bodies cap at 1 MB (413). POST /v1/x402/topup is the wallet rail: a 402 quote for $1 of USDC on Base (up to $100), then verify → claim → credit → settle; an unknown wallet's first settled top-up provisions a shadow org + Shroud agent + router key (returned once) after OFAC SDN screening (fails closed) and the geofence — migration 275 x402_wallet_orgs, same wallet = same org. The gateway drives it for Authorization: Bearer x402: no X-PAYMENT → the quote; with one → the request is served on a ≤60 s token and answers carry x-shroud-router-key (first time) and x-shroud-balance-micro-usd. Metrics shroud_inspection_fees, shroud_inspection_fee_refusals, shroud_x402_challenges, shroud_x402_topups. Spec 0.61.32.

v0.61.39 (2026-09-19)

Router keys: a stock SDK can talk to Shroud. POST /v1/agents/{agent_id}/router-keys mints an sk-shroud-v1-<32> key (plaintext returned once, with base_url), GET lists, DELETE …/{key_id} revokes — human-only, Shroud-enabled agents, 20 live keys per agent, optional per-key max_concurrent_streams and spend_cap_usd. The gateway now accepts a lone Authorization: Bearer in any of four forms — router key, lone ocv_ agent key, agent_id:ocv_, or an agent JWT — and exchanges the key-only forms itself (POST /v1/auth/agent-token with api_key alone). Router-key tokens carry a router_key claim and live at most 60 s, so a revoke lands at the gateway inside the SLA; open streams are counted per router key. Authorization: Bearer x402 is answered with a 402 challenge (x402Version: 1, accepts[]) instead of a 401, so a paying client can settle and retry once the ledger path lands. Migration 273 (agent_router_keys, RLS). Spec 0.61.31. New prod suite scripts/test-router-keys-prod.sh.

v0.61.38 (2026-09-19)

Shroud streams are inspected per frame. stream: true through the Shroud proxy no longer buffers the whole response (and never forwards it raw): text deltas are released behind a tail buffer sized to the org's longest vault secret (≤ 256 bytes; longer values matched by prefix and swallowed), so a secret split across chunks is redacted before any byte of it reaches the client; tool-call deltas (OpenAI delta.tool_calls[], Anthropic input_json_delta) are held until the call is complete, checked against the agent's tool policy, then released in their original frames and order. Two modes on shroud_config: streaming_inspection_mode: "rolling" (default; injection heuristics warn-only, blocks only on secret literals, denied tools, secret-bearing tool arguments or an exfil URL beside a redaction) and "holdback" (streaming_holdback_chars, default 512; injection blocks as on the buffered path). A mid-stream block sends one error frame and closes cleanly; OpenAI-format requests gain stream_options.include_usage so token counts still land; Shroud Activity rows are finalised at stream end; Gemini stays buffered. Per-key cap of 20 open streams (max_concurrent_streams), 429 + Retry-After beyond it. New metrics shroud_stream_frames, shroud_stream_frame_inspection_seconds, shroud_streams_blocked, shroud_streams_over_concurrency. OpenAPI spec 0.61.30 (the three new ShroudConfig fields).

v0.61.37 (2026-09-19)

Content inspection catches prompt injection and pasted API keys. POST /v1/shroud/inspect-content, the MCP inspect_content tool (@1claw/mcp 0.63.4, local mode too) and the OTEL redactor now flag instruction overrides ("ignore all previous instructions"), role manipulation, delimiter attacks, system-prompt extraction, indirect injection and encoding evasion — the rule set ported from Shroud's request-pipeline detector — plus Stripe, OpenAI, Anthropic, GitHub, Slack, Google and 1Claw keys by shape (critical; redacted in telemetry). 1claw.co: the hero now has a live, no-sign-in inspector — paste anything an agent might read and watch the verdict — running that same engine in-process at /api/demo/inspect (rate-limited, no LLM call). A weekly newsletter signup in the footer (/api/newsletter → Resend audience), with scripts/send-weekly-newsletter.mjs and weekly-newsletter.yml to send an issue from newsletter/.

v0.61.36 (2026-09-19)

No more plan trials. POST /v1/billing/subscribe no longer starts a 14-day Stripe trial: checkout collects a payment method and charges on completion, for every tier. The request's trial field is accepted and ignored (deprecated in the spec) so older clients are not rejected; existing subscriptions already in a trial run to their end unchanged. The pricing page, homepage, billing settings and the in-wizard upgrade prompt now offer a single Subscribe action and say what every paid plan includes (one Small/Medium Agent Runtime). Guard test checkout_never_starts_a_trial. The spec's SubscribeRequest enums also caught up with the code (tier: pro | team | business, interval: monthly | annual). The Free tier's limited runtime access (10 hours, 3-day window) is unchanged. OpenAPI spec 0.61.29.

v0.61.35 (2026-09-19)

Packages catch up with the API. CLI 0.61.13: 1claw connector install --host/--token (api-token), connector subscribe | subscriptions | poll | unsubscribe, agent children, agent create-child. @1claw/sdk 0.61.24: org.diffChart / org.applyChart (+ ChartDiffResponse/ChartApplyResponse types). oneclaw 0.61.10: org.diff_chart / org.apply_chart. @1claw/mcp 0.63.3: list_event_subscriptions (execute toolset) and list_child_agents (vault toolset) — 159 tools; cancel_approval documented in the skill and tool tables. /for-ai cards for connectors (catalogue + event sources), automations (resume), charts (bindings), runtimes (templates, included slot), approvals (list/cancel), memory (value search) and child agents. New sweep suite scripts/test-muse-connector-prod.sh runs the connector's production E2E.

v0.61.34 (2026-09-19)

Meta Muse connector (packages/muse-connector, new submodule, Apache-2.0, muse.1claw.co). Muse builds Custom Connectors from a service's API description plus a stored credential, so 1Claw now ships that API: a read-and-decide surface — pending approvals from both queues in one shape, approve/reject (the only write, consensus votes bound to the payload_hash the connector read), portfolio, balances, automations, activity — in front of the Platform API, scoped per user by an HMAC connector token (mcn_…) that names one platform connection and is revoked by disconnecting the Muse app. New dashboard page /connect/muse mints the token after the standard link consent and the connected-apps agent grant. Unit tests and a 19-check production E2E; submission kit for muse.ai/platform. @1claw/sdk 0.61.23: the published .d.ts files carried extensionless relative imports, so under moduleResolution: NodeNext (with skipLibCheck) the whole client typed as any — declarations now get .js extensions too, guarded by a test.

v0.61.33 (2026-09-19)

Chart bindings wait for their secret; api-token hosts. A chart binding whose credential names a secret not yet stored (the vault is usually created by the same apply) is now skipped as "waiting on secret … store it and apply again" instead of failed; the next apply creates it (test-chart-apply-prod.sh §5 exercises the three-apply sequence). The api-token connector refused hosts that merely start with http — httpbin.org — because of a scheme check written as a prefix test; it now checks for a scheme separator and refuses ports. OAuth callback default fixed. When an org's OAuth app credentials named no redirect_uri — the dashboard's recommended setting — the vault built the default on the dashboard host (https://1claw.co/v1/oauth/callback), which the dashboard answers with "This is the dashboard", so the consent round trip could never complete. The default is now https://api.1claw.co/v1/oauth/callback (the vault's public URL). Register that URI on every provider app. Guarded by a test.

v0.61.32 (2026-09-19)

Connector event triggers — the polling interim (nanobots plan, item 4). Event-triggered automations were limited to vault and policy lifecycle events; a reactive swarm had to poll on a cron and dedupe itself. Connector presets now advertise event_sources (Gmail gmail.message.received; Drive drive.file.changed; Calendar calendar.event.changed; GitHub github.notification.received; Stripe invoices, customers, payment intents; HubSpot contacts, deals), and POST /v1/agents/{agent_id}/event-subscriptions (human-only; GET, DELETE, POST …/{id}/poll) subscribes an installed binding to one. A leader-elected poller reads the source through the binding's own executor — same allowlists, credential and SSRF guard — keeps the last 500 item ids, primes on the first poll (emits nothing), emits at most 25 new items a poll oldest-first as automation events of that type, backs off on failure and switches off after 20 in a row. Migration 272. SDK connectors.subscribe/listSubscriptions/unsubscribe/pollNow (and the connector types are now exported from the package index), Python client.connectors (new resource: list_presets, install, subscribe, …). New prod suite scripts/test-event-subscriptions-prod.sh. OpenAPI spec 0.61.28, @1claw/sdk 0.61.22, oneclaw 0.61.9 (0.61.7 and 0.61.8 never published: mypy caught list[str] annotations shadowed by the resources' own list method — now builtins.list).

v0.61.31 (2026-09-19)

Charts create policies, connectors and bindings (nanobots plan, item 8). 1claw apply used to validate a chart's policies and connectors and then create only the vaults and agents; both are now created through the same gated handlers a dashboard click takes, in dependency order (vault → agent → policy → connector → binding). A connector install returns its authorization_url on the resource — OAuth consent is the only human step — and a re-apply after the sign-in reports it unchanged. New spec.agents[].bindings: an execution-intent binding declared in full (binding_type, config, guardrails), with two rules the API alone does not impose — guardrails.allowed_hosts must be non-empty (the binding's egress is the declaration) and the credential is a pointer into a chart vault (credential: {vault_ref, path}, a vault_ref credential source), never an inline value. Policies are keyed per path (vault:agent:path); permissions, binding config/guardrails, connector presets and vault fields are create-only and a difference is refused naming the endpoint that owns it. An agent's description / system_prompt are now patched in place through update_agent (result patched). A dependent whose vault or agent was queued for approval this run is skipped as "waiting on …" and created by the next apply. scripts/test-chart-apply-prod.sh section 5. Deploy fix: migration 269 wrote a JSON-style literal into a TEXT[] column and failed the Cloud Run startup probe (production stayed on the previous revision); fixed, and CI now applies every migration to an empty pgvector Postgres so SQL that never runs under cargo test is exercised before a deploy. OpenAPI spec 0.61.27, @1claw/sdk 0.61.21, CLI 0.61.12.

v0.61.30 (2026-09-19)

binary runtime template — run a compiled program (Go, Rust, …) from a release asset (env_public.BINARY_URL, HTTPS, pinned by BINARY_SHA256, archives unpacked) or a startup_command after a repo clone; the create call refuses a binary runtime with nothing to run. CLI 0.61.11 runtime create lists the real templates/presets and gains --source-repo, --source-branch, --startup-command. Platform-default OAuth apps — ONECLAW_OAUTH_DEFAULT_APPS (JSON, per provider) lets connections use a 1Claw-owned app when the org registered none; org credentials always win; the dashboard shows "Using 1Claw default"; GET …/oauth/app-credentials returns platform_defaults. Registering the apps and Google's restricted-scope verification remain the operator's decision. Automation runs resume after their approval. An approval_request step already parked the run and stopped the clock; nothing woke it up (nanobots plan, item 5). Now the run's state is saved at the step (migration 270), deciding the approval resumes it automatically (approved → next step, rejected → failed with the reason), POST /v1/automations/{id}/runs/{run_id}/resume hands off a decision made elsewhere (human-only, optional payload as {{resume.*}}), the resumed segment gets its own 300-second clock, and a run parked for more than 72 hours becomes timed_out. New webhook event automation.run.resumed. SDK automations.resumeRun, Python resume_run. Child agents (nanobots plan, item 3) — POST /v1/agents/{agent_id}/children creates a sub-agent under a parent (human-only, up to 50 per parent, migration 271): it gets its own API key, memory namespaces (default child:{id}) and action-approval policy; its vault_ids and scopes must be a subset of the parent's (a superset is refused); it inherits the parent's vault policies and guardrails; it does not count against the plan's agent cap, cannot have children of its own, and reports agent_type: "child" / parent_agent_id on every agent response. GET …/children lists them. SDK agents.createChild / listChildren, Python create_child / list_children. OpenAPI spec 0.61.26, @1claw/sdk 0.61.20, oneclaw 0.61.7.

v0.61.29 (2026-09-19)

Connector catalogue: Google Drive, Google Business Profile, Stripe, HubSpot, LinkedIn, and a generic api-token connector (host named at install, token stored in the vault, same SSRF rules as every binding; migration 269 seeds the three new OAuth providers and the Google drive.file / business.manage scopes). Three things nanobots asked for. POST /v1/agents/{id}/memory/search now matches text stored in values — it decrypts the namespace (bounded, most recent 500 + shared) and scores key + value lexically (exact 1.0, substring 0.95, token overlap 0.3–0.9); it returned nothing for any value text before. POST /v1/approvals/{id}/cancel lets the requesting agent (or the addressed human) withdraw a pending approval, first-answer-wins, delivered to subscribers as approval.decided with decision: "cancelled" (new status cancelled, migration 268). GET /v1/approvals as an agent returns the approvals that agent created. SDK approvals.cancel, Python approvals.cancel, MCP cancel_approval (157 tools). The memory prod suite now asserts a value-text hit instead of accepting zero results.

v0.61.28 (2026-09-19)

One Agent Runtime included with every paid plan. Pro, Team, Business and Enterprise each include one Cloud Runtime at no charge — Small or Medium (up to 1 vCPU / 2 GB), with no monthly hour cap and no Stripe add-on. The vault assigns the included slot to the first small/medium runtime you create (billing_kind: included; GET /v1/runtimes reports included_runtime: { allowance, used, presets }), the create wizard shows "Included with your plan" instead of a price, and deleting the runtime frees the slot. Large and Confidential Compute presets, and further small/medium runtimes, remain paid add-ons; pool runtimes still draw from the plan's hours. Medium is now 1 vCPU / 2 GB (was 1 GB). Migration 267. OpenAPI spec 0.61.25, @1claw/sdk 0.61.19. Also: passkey-Safe execute checks the relayer's gas balance before signing and names the address, chain and amount to fund; the Safe card shows the gas payer. Pairing approve/deny now read the pairing columns (the previous column list dropped them, so --pair never received its key) — caught by the new scripts/test-custody-prod.sh on its first run.

v0.61.27 (2026-09-19)

Passkeys registered on the old domain no longer lock an account. A credential is bound to the rpId it was registered under, so a 1claw.xyz passkey cannot answer on 1claw.co; every step-up gate now counts only passkeys usable on the current domain — registering a new passkey no longer demands a step-up nothing can satisfy, and a stranded credential on an account with no other factor can be removed with the live session (audited). The security page marks such passkeys "Only works on 1claw.xyz". Custody deny switch at the insert: ONECLAW_SERVER_CUSTODY_GENERATION=deny now covers signup auto-provisioning, platform bootstrap and the smart-account signer, because the check lives where every server-custody key is inserted. Agent TSS parity: agent-driven threshold sends honour per-agent wallet-access policies (and so do delegated server-custody key reads); a background sweeper reaps abandoned ceremonies' round secrets; a failed ledger write after broadcast is an error and an audit event, not silence; runtime-share provisioning refuses platform-claim sessions. Admin usage-pattern reads are audited. PostHog identify no longer sends platform-admin status. Runtime negative tests for forged passkey assertions and server-share-only signing. New prod suite scripts/test-custody-prod.sh.

v0.61.26 (2026-09-19)

Agents spend from passkey-owned Safes, capped on chain. Agent spending on a passkey Safe grants an agent a per-period allowance through Safe's Allowance Module v1.0.0: one passkey touch enables the module, adds the agent's Ethereum signing key as a delegate and sets the cap (POST /v1/treasury/passkey-safes/{id}/grants, …/grants/{grant_id}/revoke; execute accepts a delegatecall only into the pinned MultiSendCallOnly and only for calldata it prepared). The agent spends with POST /v1/agents/{agent_id}/passkey-safes/{safe_id}/spend (agents.spendFromPasskeySafe in @1claw/sdk 0.61.17, spend_from_passkey_safe in oneclaw 0.61.4) after its guardrails and the sanctions screen; the module — not the vault — enforces the cap. Counts as one signature. Passkey Safes name their passkey, prepare returns its transports (Touch ID instead of the cross-device QR), and a passkey registered on another domain (1claw.xyz vs 1claw.co) is refused at create/prepare with the reason instead of a prompt that can never complete. Canonical domain sweep: every remaining 1claw.xyz default, link and message in the vault, packages, scripts and internal runbooks now says 1claw.co (.xyz stays accepted as legacy); runtime slug URLs mint {slug}.run.1claw.co. OpenAPI spec 0.61.24.

v0.61.25 (2026-09-19)

Two wraps before funds, enforced. A self-custody (client_tss) wallet's address and Receive are held back on the wallet card until the owner's share is recoverable from two places; GET /v1/treasury/wallets now reports owner_wraps (passkey PRF + recovery-code wraps; runtime holder wraps do not count). New Backups dialog: Add a passkey (rewrap under a second PRF passkey), Create / Rotate recovery code (32-character code shown once, never stored by 1Claw; the share is wrapped under HKDF of the code with a fresh salt), and Restore from code (re-wraps the share under a new passkey when every holding passkey is gone). Runtime base image moves to Node 24 (openclaw requires ≥ 24.16). OpenAPI spec 0.61.23, @1claw/sdk 0.61.16 (generated types).

v0.61.24 (2026-09-18)

Agent pairing with a fingerprint. POST /v1/agents/enroll takes an optional public_key; the response carries the key's SHA256: fingerprint, which the approval page now shows for the human to compare with what the agent printed, and a poll_token the agent uses on GET /v1/agents/enroll/{pairing_id}/status to learn the decision and collect its API key itself, once — no key in an email. 1claw agent enroll --pair does the whole ceremony (CLI 0.61.8); AgentsResource.pair() in @1claw/sdk 0.61.15, enrollment_status() in oneclaw 0.61.3. Proposals (/proposals): agent signing requests — messages, typed data, digests, transactions — rendered structurally with a decided history, "Refresh status", and passkey step-up for tier-2 signatures; the same view ships as <OneclawProposalDetail /> in @1claw/wallet-react 0.6.0 with client.listProposals/getProposal/decideProposal. Home: an agent activity feed ("Nothing needs you" / N updates). OpenAPI spec 0.61.22.

v0.61.23 (2026-09-18)

Agents sign with self-custody keys, unattended. The second share of a client_tss wallet can be held by the Shroud sidecar in a hosted runtime: the sidecar registers a P-256 key at boot (POST /v1/runtimes/{id}/tss/holder), the owner's passkey re-wraps their share to it (PUT /v1/keys/{id}/client-share/holder, ECIES, opaque to the vault), and the agent sends through /v1/agents/{id}/tss/{prepare,sign/begin,sign/complete,broadcast} — prepare applies the agent's guardrails and the sanctions screen and records the message, sign/begin refuses anything unprepared, broadcast verifies and records the transaction. Sidecar 1.1.0 runs the same FROST crate as the browser via wazero (POST /tss/send on its loopback API). Re-key to self-custody: a server-custody Solana wallet can be replaced by a threshold key in one ceremony (replace_existing), the old key's last signature sweeping its balance across (audit treasury_wallet.rekeyed). Custody policy switches: ONECLAW_SERVER_CUSTODY_GENERATION=deny (with an exception list) and ONECLAW_LAZY_WALLET_PROVISIONING. Proof: no_server_only_reconstruction.rs fails the build for any key read that is not gated on custody, threshold, or passkey-owner — and found two ungated server paths (card orders, x402 pay) which are now gated. OpenAPI spec 0.61.21.

v0.61.22 (2026-09-18)

Passkey-owned Safes on EVM (custody: passkey_owner). A Safe v1.4.1 whose only owner is Safe's WebAuthn shared signer configured with your passkey's P-256 key — no private key exists anywhere. POST /v1/treasury/passkey-safes derives the counterfactual address; …/{id}/prepare runs the sanctions screen and spend policies and returns the SafeTx hash, which your passkey signs as its WebAuthn challenge; …/{id}/execute verifies the assertion locally (this passkey, this hash, a 1Claw origin, user verification) and relays execTransaction — deploying the Safe on the first send — from your Ethereum treasury wallet, which pays gas and is not an owner. Base, Optimism, Arbitrum and Polygon verify through the RIP-7212 precompile; Ethereum and the Sepolias through the Daimo P-256 verifier. Treasury → Passkey-owned Safes in the dashboard. Safe registry corrected: the pinned v1.4.1 singleton and proxy creation code were not the canonical ones (the singleton had no code on any chain) and the SafeTx struct hash double-hashed data; counterfactual addresses now match SafeProxyFactory.createProxyWithNonce on Base byte for byte, and the Allowance Module pin is v1.0.0. No existing account was affected (no counterfactual agent Safes had been created). OpenAPI spec 0.61.20.

v0.61.21 (2026-09-18)

Self-custody Solana wallets (custody: client_tss). A 2-of-2 FROST/Ed25519 key generated between the vault and your browser (@1claw/tss-wasm); the private key never exists. Your share is wrapped under your passkey's PRF output and stored opaque; the vault's is a tss_share secret no server signing path reads. New: POST /v1/keys/tss/keygen/{begin,round2,complete}, POST /v1/keys/{id}/tss/sign/{begin,complete} (passkey-bound to the message digest; the vault decodes the message and runs the sanctions screen on every transfer inside it; nonces are single-use), POST /v1/treasury/wallets/{chain}/tss/{prepare,broadcast} (wallet access, sanctions, spend policies; broadcast only a verified signature over the screened message). Treasury → Self-custody Solana wallet in the dashboard; tx-assert actions tss_keygen / tss_sign. Server-side product analytics: the vault reports named API actions (token exchange, secret read/write, sign/submit, approvals, runtime chat/shell, treasury sends) to PostHog under the same identity as the dashboard, grouped by org. OpenAPI spec 0.61.19. EVM/Bitcoin/Tron keys remain server custody; see Key custody.

v0.61.20 (2026-09-18)

Sanctions screen on every signing path. Agent submit/sign, the unified /sign, automations, the TEE-forwarded path, human treasury sends and Safe proposals (creation and execution) now check the destination — and the recipient inside ERC-20 calldata — against the OFAC SDN digital-currency list before anything is signed. A hit is refused with 403 naming OFAC and audited as sanctions.blocked; no allowlist, cap or policy admits it. The list is refreshed daily from Treasury's SDN publication and the screen fails closed: older than seven days and transfers pause with 503 until it refreshes. Custody is now a fact on the key. custody (server today; client_tss for passkey-held threshold keys) is on every treasury wallet and agent signing key, the dashboard shows a Custodial / Self-custody badge, and the server signing path refuses to unwrap a client_tss key — see Key custody. Client-held shares: PUT/GET /v1/keys/{key_id}/client-share, POST …/client-share/rewrap and DELETE …/client-share/{share_id} store the customer's wrapped share of a threshold key, opaque to the vault. Passkeys report PRF support (prf_supported on registration and in the list; "Can hold wallet keys" in Settings → Security). Geofence: creating a 1Claw-held wallet is refused from New York (403, audit custody.geofenced) until threshold keys ship; signup from New York proceeds without the auto-provisioned wallet. TEE key delivery is no longer metered (GET /internal/v1/keys/… was billed as a customer request, so TEE signing 402'd for an org in overage and every TEE sign cost two metered calls) and reports the key's real key_version on explicit paths. OpenAPI spec 0.61.18.

v0.61.19 (2026-09-17)

intents_require_tee no longer needs client-side routing. A transaction submit or sign that reaches api.1claw.co for a TEE-required agent is carried to Shroud by the vault (the agent's own JWT is replayed; Shroud signs, broadcasts and records as for a direct call). MCP, SDK and CLI clients that only know the vault host now work with the flag on; execution_require_tee likewise forces the TEE execution path instead of refusing. Refusals remain for delegated/human credentials and DPoP-bound tokens. Failed broadcasts release their nonce. A submit whose RPC broadcast fails now gives the nonce back, and the nonce tracker only stays ahead of the chain's pending count when the gap is covered by the vault's own recent broadcasts — a failed broadcast can no longer leave the next transaction queued behind a hole. Approval emails say what is being approved: reason, target and the request's summary fields are rendered as rows alongside the action.

v0.61.18 (2026-09-17)

MCP 0.63.0: split packages. @1claw/mcp-vault (vault + approvals + inspect_content; no signing, execute, cards, memory, platform or admin code in the package) and @1claw/mcp-guard (inspect_content only; no credentials, no vault client) are published in lockstep with @1claw/mcp. Internally the server bootstrap moved to core/server.ts, toolset modules own their tool lists, and the client is split by domain behind the same OneClawClient facade — no tool renamed, no behaviour change for the umbrella. SDKs: TokenResponse.entitlements typed in @1claw/sdk 0.61.13 and oneclaw 0.61.1. CLI 0.61.7: 1claw agent binding proxy and 1claw daemon proxy require a per-run token (printed at startup, or --token / ONECLAW_PROXY_TOKEN) presented as the tool's API key; other local processes get 401. Vault: OTEL span attributes are allow-listed by key at the collector (unlisted keys dropped, logged once); rustls 0.23.45 (RUSTSEC-2026-0285). Shroud: attestation now reports confidential — the node's Confidential-VM identity token is relayed into the pod (Workload Identity tokens cannot carry it) and published as node_identity_token; image measurement (sev_snp) is still not attested.

v0.61.17 (2026-09-17)

Agent token exchange returns entitlements. POST /v1/auth/agent-token now carries the flags a client needs to shape its tool surface in one round trip — intents_api, execution_intents, execution_require_tee, intents_require_tee, cards, memory, shroud, discoverable — plus two facts the agent profile cannot express: treasury_signer and has_delegations. Claim-bearing PATCHes revoke tokens. Changing an agent's scopes, vault_ids, is_active, intents_api_enabled, shroud_enabled/shroud_config, execution_intents_enabled, intents_require_tee, execution_require_tee or environment now revokes the agent's outstanding JWTs (audit event agent.tokens_revoked), so a downgrade takes effect on the next call instead of at the end of the token TTL. Deleting a running runtime stops it first. DELETE /v1/runtimes/{id} (and the platform-scoped sibling) stop the provider-side compute before dropping the row and refuse the delete if the stop fails — a deleted row was compute nothing could find again. MCP server 0.62.0 offers each session only the toolsets its agent is entitled to; see the MCP docs.

v0.61.16 (2026-09-17)

read_contract automation step. eth_call a view function (an oracle price, a balance, a health factor) and decode the result into steps.<name>.output.values[...] for a condition to act on, so fund-moving automations no longer need an http step to a price API. Static ABI types; output types from the step or from an uploaded contract ABI; allowed in agent-created automations (it signs nothing). Connection record carries email and display_name on GET /v1/platform/connections/{id}, so a returning user can be recognised and a passkey ceremony begun from the connection alone. LLM token billing status now states billing_model: postpaid_metered and inference_allowed; credit_balance is Stripe's prepaid credit-grant balance and is 0 for most orgs, which does not block inference. All three from the Fathom team's integration notes.

v0.61.15 (2026-09-16)

DELETE /v1/platform/connections/{id}/runtimes/{runtimeId}. A platform app could create a runtime on a connection but not remove it: the human DELETE /v1/runtimes/{id} refuses plt_ keys, and the connection-scoped route had only GET and POST. The DELETE is gated exactly like the GET (app owns the connection, the connection lists the runtime, the runtime is in the end user's org), stops a running runtime at the provider first, cancels any runtime add-on before the record goes, trims the connection's runtime list, and writes platform.connection.runtime_deleted to the audit chain. MCP tool platform_delete_connection_runtime; SDK client method platformDeleteConnectionRuntime. Surfaced by the Fathom team, who had a stopped probe runtime stranded on a live connection.

CLI 0.61.4–0.61.6 (2026-09-15)

0.61.6. The CLI config file, which holds the cloud session token, stayed 0600 only until the next unrelated config write (conf rewrites the file atomically); it is 0600 for good now. 1claw daemon start --socket-group <group> shares the daemon socket (0660) with an agent running as its own Unix user, so the agent reaches policy-gated secrets but not the human's session; login now warns on a host that has a local vault or daemon.

1claw agent binding proxy <binding> and 1claw daemon proxy <secret> --base-url <url>. A local HTTP front for one execution binding, for vendor CLIs and SDKs that accept a base-URL override. Each request becomes POST /v1/agents/{id}/execute for the binding; the vault applies the host and path allowlists and the agent's policies, injects the credential, and the upstream response comes back. The tool's own credential is dropped locally and never forwarded, so a placeholder satisfies its "key must be non-empty" check. A refusal is a 403; an unreachable vault is a 502 and the tool stops. Written for the Bankr CLI (BANKR_API_URL), whose bankr login otherwise leaves the real key in ~/.bankr/config.json where any agent on the host can read it. The Bankr guide now leads with keeping the key off the machine. The Shroud bankr provider is documented for what it is: the LLM chat endpoint only. The daemon form runs the same proxy in front of the local daemon: policy and injection come from the local vault, and nothing leaves the machine except the upstream call.

v0.61.9 – v0.61.11 (2026-09-12 → 13)

Control plane. 1claw.co/dashboard now opens on a live topology map of the org — agents, the policies they hold, the vaults those grant, the chains they sign on and the systems they call — with a threat register ranked by blast radius, metrics, a Sankey of who actually read from which vault, and an SSE signal stream with Last-Event-ID resume. Every agent carries a continuous 0–100 trust score recomputed every 30 s from policy denials, threat hits, egress blocks and spend velocity; the engine runs in recommend-only mode (findings are shadow: true) and never auto-suspends. Dark mode, touch, keyboard shortcuts (?), search (/), filters, a minimap for large orgs, and per-org layout persistence. Docs: Dashboard → Control plane.

API. GET /v1/otel/{stream,topology,threats,summary,metrics,flows} and GET /v1/otel/agents/{id}/trust — human users only; agents are 403 so a compromised agent cannot read the org's map. Team orgs can fan the same signals out to their own collector over OTLP/HTTP JSON (/v1/org/settings/otel-export). Signal attributes are redacted at the source before they are buffered.

Platform apps get the same views over their own connections' agents — GET /v1/platform/connections/{id}/otel/{topology,threats,summary,stream}. The topology is walked outward from the connection's agents, so a vault shared with another tenant's agent never reveals that agent. SDK 0.61.12 adds client.otel (with an async-iterator stream()) and client.platform.getConnectionOtel*; MCP 0.61.1 adds platform_get_connection_otel_{summary,threats,topology}.

Also. Deleting an agent now removes its access policies (1,427 orphaned rows from earlier deletions were swept); trust-score history only records a sample when the score moves, and is pruned after 30 days.

v0.61.0 (2026-09-07)

1claw pay. An agent can now pay somebody else's x402 paywall, under a passkey or a capped spending grant. 1claw pay --agent <id> <url> fetches, captures the 402, gets it authorized, signs, and retries — Base USDC on the direct-fetch path.

The CLI holds the network connection and nothing else. It sends the vault the exact bytes the paywall served; the vault computes the digest, decides what may be signed, and renders the authorize page from that stored preimage rather than from anything the client claims about it. The digest binds the transfer value, not the challenge's maxAmountRequired ceiling, so what a person approves and what gets signed cannot drift.

--mode is a request. pay_require_passkey defaults to true, and while it is true every payment needs a human touch — an allowlisted recipient does not bypass that, it only widens which recipients a grant may cover. auto is never honoured while a passkey is required; it degrades to the ceremony the agent is configured for. An unattended agent with no allowlist pays nobody: a null allowlist is not a wildcard.

Spending grants turn one touch into a cap and a window. The cap is decremented in a single guarded statement, so two concurrent payments cannot both spend the last dollar, and a grant can never exceed the agent's own maximum cap or window.

Limits are charged at signing, not settlement. A signature that was produced and then lost still consumed authority. Reporting a failure afterwards returns "limit_released": false — only a vault-verified reconciliation can give headroom back, and that is not built yet.

When a challenge window closes, the CLI re-fetches the resource rather than re-using the challenge it holds: the stored bytes would reproduce the same closed window, and many challenges carry a single-use nonce. It tries twice, then says so and suggests a grant.

New: PATCH /v1/agents/{id}/pay/settings, POST .../pay/prepare, .../pay/sign, .../pay/grants, .../pay/{payment_id}/result, GET .../pay/{payment_id}, GET|POST /v1/pay-sessions/{id}, POST /v1/pay-sessions/{id}/authorize, DELETE /v1/pay-grants/{id}.

Supported: USDC/USDT on Base, Optimism, Avalanche, BNB Chain and Solana — EIP-3009 on the EVM chains, a signed SPL transfer on Solana, chosen by the chain rather than by a flag. Every address and mint verified on-chain; BNB Chain stables are 18 decimals, not 6, and treating them as 6 would understate a payment by 10^12. An unlisted asset is refused rather than guessed at. Signing happens in the vault, not yet in the Shroud TEE. The dashboard authorize page is not built; the endpoint behind it is.

See Paying x402 paywalls.

v0.60.1 (2026-09-07)

Directory job board. Post a task to the agent directory, receive bids from discoverable agents, award the work. POST /v1/directory/jobs, .../bids, .../accept/{bid_id}, .../cancel, .../complete. The award returns a handoff pointing at the bidder's own a2a_url — 1Claw hosts the board, not the runtime.

Job and bid text is written by one party and read by another party's model, so every field is inspected before it is stored. High-confidence injection is refused; anything below that threshold is returned as an untrusted-content envelope rather than a string, server-side, for every client. The SDK types it so passing it into a prompt is a type error. MCP gets read-and-bid tools only. See Directory job board.

Policy presets compile to Cedar (Team+). POST /v1/agents/{id}/policy-preset/cedar returns the Cedar a preset produces, validated against the deployed schema. It does not convert the presets' USD limits into value_gwei — that needs a live price, and a price written into a policy is wrong the moment it is written. Those limits come back as residual_guardrails and stay with the guardrail columns. See Policy presets.

Honcho connector fixed. The preset pointed at a host that does not answer; it now points at api.honcho.dev. The production suite dials every preset's base_url, because every static check passed while the host was dead.

Security fixes. Configuring an email or push notification target no longer suppresses approval notifications — suppression is keyed on the channels that actually deliver. Notification targets always belong to their creator. X-Platform-Connection is validated against the caller everywhere it is read. New-recipient risk elevation is derived server-side instead of read from the requesting agent's own payload. Connected Account OAuth2 tokens are now attached to outbound requests. Reports on a listing are one per person and clearable.

v0.60.0 (2026-09-06)

Fleet management — every agent one bootstrap template provisioned, managed as one cohort.

GET /v1/platform/apps/{id}/fleets/{template_id} and /agents; POST .../bulk-patch, .../rollout, .../pause. CLI 1claw platform fleet status|agents|patch|rollout|pause; SDK client.platform.getFleet and friends; MCP platform_get_fleet, platform_list_fleet_agents, platform_plan_fleet_rollout.

Bootstrapping now stamps the fleet and the template version on each agent, so version_skew answers "how many are behind?" — and spec_hash distinguishes a version bump that changed nothing from one that did.

Every route here does what it does a thousand times, and nobody reviews it per agent. That is the whole design:

• Guardrails and capability flags are not bulk-patchable. Raising a spend limit across a fleet is not a deployment operation; it is a thousand separate decisions that happen to share a form. Enabling intents_api_enabled for a cohort is the largest privilege change this API can express. Both stay per-agent. Read bulk_patchable_fields off the fleet summary rather than hard-coding it.
• A bad field refuses the whole patch, rather than applying the acceptable parts. A partially-applied bulk patch across a thousand agents is worse than a rejected one.
• Hand edits are skipped, not corrected. An agent changed outside fleet control is left alone and the field is recorded on it — the standing answer to "why is this agent behind?". force overrides the skip but still cannot carry a guardrail.
• A dry run claims no job, so it never blocks the real rollout behind the one-rollout-per-template rule. job_id is null and the type says so.
• MCP is read-only here. platform_plan_fleet_rollout always dry-runs, and sets that itself rather than accepting it as an argument. Bulk-patch and pause are absent: a thousand agents changed from one call is a decision for a human at a terminal.

See Fleet management.

v0.59.18 (2026-09-06)

Four features shipped in this release. Peer memory is below; the other three were omitted from this entry when it was first written, which made them look unreleased to anyone reading the changelog rather than the API.

Learned auto-approval, shadow-first. GET /v1/org/approval-learning/shadow-report reports which approval patterns would be automated; POST /v1/org/approval-learning/{profile_id}/promote is the only write, and it is human-only.

Every decision made through the approvals path has been observed since this shipped, so the shadow window is already accumulating — the report is a read over data that is being collected now, not something that starts when a UI appears. Promotion refuses entirely while the org is in shadow mode.

A promoted rule covers only what was actually approved: it is bounded by the amount band it was earned in, and a run of approvals for a familiar recipient never licenses a new destination. A profile promotes onto the agent whose approvals built it and no other. See Guardrail governance.

Policy presets. Four plain-language presets — read-only-assistant, small-business-spender, inbox-agent, treasury-operator — that compile to guardrail columns, access policies and approval rules. GET /v1/policy-presets, POST /v1/agents/{id}/policy-preset/preview, and POST /v1/agents/{id}/policy-preset.

Applying a preset that loosens a guardrail returns 202 or 403, never a silent 200: a preset builds the same request a person editing by hand would send and passes it to the same handler, so it is a friendlier interface to the approval flow rather than a way around it. Preview names every field that would widen. See Policy presets.

Trust signals on listed agents. GET /v1/agents/{id}/trust returns badges, rating and review count for a public listing; POST /v1/agents/{id}/review and /report are human-only, one per person per agent. The public view carries no reviewer notes or report reasons — those are queue-internal, and publishing them would publish accusations about an agent's owner. See Trust signals.

Peer memory — a shared model of one person across the agents serving them, so each agent does not learn them independently.

POST /v1/peers, GET /v1/peers/{id}, /context, /events, /predict-approval, /by-connection/{id}, and GET /v1/agents/{id}/peer-context. SDK client.peers.*; MCP get_peer_context. Bootstrapping a platform connection provisions its peer with that connection's agents as observers.

A peer is the most sensitive thing an agent can read about someone, and unlike a secret it is derived — nobody deliberately granted it. So:

• Access is by observer list and nothing else. Same organisation, same connection, broad scopes: none of it grants access. A peer with no observers is readable by no agent — if empty meant "everyone", forgetting to set observers would expose a behavioural profile silently and totally.
• Creating a peer is human-only. An agent that could do it could add itself.
• Prediction is not permission. predict-approval returns likelihood (an observation about a person) and suggest_auto (a statement about your action_approval_policy) as separate fields. suggest_auto is true only where a rule you already wrote permits this exact case; a confident model never becomes new authority, and a blocked_reason says which of your rules prevented it.

Derivation is deliberately narrow: per fingerprint bucket rather than action type, so three approvals of $5 do not become a belief spanning $500; three observations minimum; a mixed history is not a tendency at all; and confidence is capped below certainty, because a 1.0 reads downstream as "no need to check".

Facts outlive their evidence without losing their basis. When events pass the 90-day retention window, each provenance entry becomes a tombstone keeping the kind of event and the decision but not the content — so "why does this system think that about me?" stays answerable. A human correction is never overwritten by re-derivation.

v0.59.17 (2026-09-06)

Declarative charts. One file provisions a whole swarm:

1claw diff  -f chart.yaml     # what would change
1claw apply -f chart.yaml

POST /v1/org/apply/diff and POST /v1/org/apply, plus per-user usage exports from v0.59.15's Feature 7 work. Both endpoints are human-only — a chart provisions agents, vaults and access policies, so an agent that could apply one could grant itself access to a vault it cannot currently read.

The interesting half is what apply refuses to do:

• It never deletes. A resource removed from the chart is left alone; there is no --prune. An apply that silently deletes is an apply nobody runs twice.
• It skips anything edited outside the chart, naming the fields that differ. Someone changed it by hand for a reason, and overwriting that because a file says otherwise is how a deployment tool destroys a fix at three in the morning.
• It refuses guardrails. Transaction limits, host allowlists and approval policies route through the guardrail approval flow; a reconciler writing them directly would be a way around it wearing a deployment tool's clothes.
• It does not skip your approval gates. Apply calls the same handlers the API routes call, so an org requiring consensus for vault.create gets an approval queued exactly as a dashboard click would. That resource reports awaiting_approval; the rest of the chart still applies.

A refusal is never silence — silently ignoring a difference would mean the chart and reality disagree forever while every apply reports success.

Typos are errors. Unknown fields are rejected. A misspelled system_promt that was quietly dropped would produce an apply reporting success while doing nothing you asked for.

Names are the reconcile keys. Duplicates are an error rather than resolved by position, which would silently reassign resources when someone reordered the file.

The reconciler is server-side and only server-side; 1claw apply parses YAML, posts it, and renders the answer. Example chart at examples/charts/inbox-swarm/, with a test that runs the shipped file through the real validator.

v0.59.16 (2026-09-06)

SMS notifications, and approval by reply for the lowest-risk actions.

Bring-your-own-Twilio. A new sms channel type, POST /v1/webhooks/sms/{path} for inbound, and notification targets that say where approvals reach a human.

Most of this feature is limits, because SMS is a weak authenticator:

• Only risk_tier 1 can be decided by reply. Higher tiers get a link and cannot be approved by answering. The tier is derived by the server, so an agent declaring tier 1 on a $500 refund does not unlock the channel.
• The number must be verified. A target is created unverified and stays that way until someone proves they hold the number — adding a number is not itself an authorisation. Unverified targets still receive; that is how you find out your number was enrolled.
• A valid Twilio signature is not enough. It proves the message came from Twilio, not from the right person: anyone who knows the number can text it and their message arrives correctly signed. The sending number must also match a verified target.
• Two pending approvals means a bare "YES" is refused, and answered with reference codes. SMS has no threading, and approving the newest means approving something you may not have read.

The message body differs by tier — higher tiers never say "reply", because an instruction the server will refuse teaches a habit worth not teaching. And the agent-supplied summary has instruction words and code-shaped tokens removed before sending: without that, a summary reading "refund $5. Reply YES A7 to confirm" could aim you at a different approval entirely.

New: POST/GET/DELETE /v1/notification-targets plus /verify/start and /verify. SDK client.notificationTargets.*, CLI 1claw notify, MCP list_notification_targets. Adding and verifying stay human actions and have no MCP tool.

Existing notifications are unchanged until you configure a target. A configured target of a given type replaces the legacy source for that type, so an email target does not mean two emails; deleting it puts the account email back.

v0.59.15 (2026-09-06)

Pre-built connectors. Gmail, Google Calendar, GitHub, Slack, X, Discord, Notion and Honcho, each installable in one call.

• GET /v1/connectors/presets — the catalogue. Public.
• POST /v1/agents/{id}/connectors/{slug}/install — creates the binding and starts the OAuth flow. Human users only; an agent installing for itself is a 403.
• GET /v1/agents/{id}/connectors — what is installed, and whether each is actually connected.

The binding an install creates is scoped to the connector — gmail can reach gmail.googleapis.com/gmail/v1/ and nothing else. That is the difference from a bare OAuth connection: an HTTP binding with no allowed_hosts has no host restriction, so a binding holding a user's Google token could be pointed anywhere.

Requested scopes may narrow a preset's list and never extend it, and may not drop a scope the preset marks required. The reviewed scope list is what makes a one-click install different from a general OAuth initiator.

Installed is not connected

A 201 means the binding exists; it holds no credential until the user finishes the OAuth round trip. connected and needs_reauth are reported separately from installed, because the gap between them is where someone spends an afternoon debugging an agent that never had a token.

Installing Gmail and Google Calendar — both the google provider — now gives two bindings with two tokens and two path allowlists, rather than the second install landing on the first one's binding.

SDK client.connectors.*; MCP list_connector_presets and list_installed_connectors; a connector gallery on the agent's Connections tab. Installing has no MCP tool: it stays a human action.

v0.59.14 (2026-09-06)

Approvals a human can actually read.

An approval used to describe a transaction. It can now describe a refund, a post, an invoice — any business action — in plain language, with the risk tier decided by 1claw rather than by the agent asking.

POST /v1/approvals/request accepts business actions. Name them namespace.verb (refund.create, social.post). Two new fields:

• payload — what the action will actually do (amount_usd, customer_email). Separate from summary, which is what the human is shown. The risk tier is derived from the payload, so a summary that flatters it changes what your operator reads and nothing about how strong the approval must be. The dashboard shows both.
• declared_risk_tier — advisory. 1claw derives its own floor and takes the higher of the two. You can ask for a stricter review, never a weaker one: an agent declaring tier 1 on a $500 refund gets tier 2, and the response returns risk_tier (enforced), declared_risk_tier (asked for) and declared_below_floor. risk_tier still works as the old request-body name.

The response also returns human_summary — the line your operator receives on SMS, push, or email, rendered from your agent's summary_template.

Integrator-affecting: five actions are now rejected on this endpoint

policy_change, card_order, agent_transaction, agent_execution and agent_sign_intent return 403 when an agent requests them directly. These are the approvals 1claw executes when a human approves — and the wording a human reads has to come from the same place as the side effect that follows. They are still raised for you automatically by the endpoints that need them.

If you were requesting policy_change to ask for wider access, use access_request or policy_request instead. Our own documentation showed policy_change in that example and has been corrected.

New: action_approval_policy on agents. Says which business actions need a human and above what amount, and carries the summary_template used to render the sentence:

{
  "rules": [{
    "action_type": "refund.create",
    "mode": "approve",
    "require_for_amount_above_usd": "50",
    "summary_template": "Refund {{amount_usd}} to {{customer_email}}"
  }]
}

Editing it counts as widening a guardrail — raising a threshold takes a human out of the loop — so it routes through the same approval flow as loosening a transaction limit. Malformed rules are rejected when you save them rather than ignored when they are read: a threshold of "fifty" used to be a rule that silently did nothing.

Consensus approvals keep their summary. POST /v1/pending-approvals and the platform equivalent now store the summary you send, so the queue an approver decides from shows it. It was previously included in the webhook and nowhere else. Sending one is not yet required; submissions without one are accepted and counted.

Fixed, in the packages

• CLI: 1claw approval list and approval get threw TypeError: tier.toLowerCase is not a function on any real approval — risk_tier was typed as a string and the API sends a number. The list now leads with the plain-language summary.
• MCP: get_approval and list_approvals read resource_type, resource_id and metadata, which the API has never returned, so they showed the action and nothing about what it was for. They now read the real fields and show the summary, tier, and payload. request_approval no longer tells agents to request policy_change, or that the tier range is 1–5 when the column has always been 1–3.
• OpenAPI: the request-side risk_tier was documented as 1–5 against a column that has always been CHECK (risk_tier IN (1, 2, 3)).

v0.59.13 (2026-09-02)

Three endpoints were returning 500 on every call. They are fixed.

• POST /v1/secrets/{id}/share — secret sharing failed for every caller. The query behind it named its columns by hand and did not gain two fields the row type had gained, so it failed against the database every time and surfaced as "An unexpected error occurred". If you have integration code that quietly skipped sharing, it will start working.
• DELETE /v1/org/sub-orgs/{id} — archiving a sub-organization had never once succeeded. Its first statement wrote a column that did not exist, so the transaction rolled back and nothing was archived.
• POST /v1/vaults now answers 409 for a duplicate name and 400 for an empty one or one over 255 characters. All three were 500s. Names are unique per organization, and the name is trimmed before it is stored — the trimmed value is what must be unique.

Browser bridge

Integrator-affecting: four fill fields are now required

POST /v1/agents/{id}/browser/fills requires form_path, field_names, redirect_chain and current_generation. They were optional and filled in server-side when absent, which turned three of the policy's own checks off: the redirect chain was always empty so its check never ran, current_generation defaulted to generation and was compared against itself, and form_path defaulted to "", which matches no fingerprint pattern and denied every binding that carried one.

A request missing any of them is now refused with a 400 naming the fields. Send current_generation as the generation you observe now — sending the same value as generation makes the staleness check compare a value to itself.

• GET /v1/browser/devices and DELETE /v1/browser/devices/{id} are documented. Revoked devices are listed rather than hidden, because "was this machine ever paired" is the question asked after a laptop goes missing.
• Stock CDP clients connect. Puppeteer, Playwright, and the agent frameworks built on them can now attach to the bridge, open a page and navigate. Previously they were refused on the second method they sent.
• Commands are confined to a client's own targets, not only events: one agent cannot list, attach to, or drive another agent's page.

Runtimes

• POST /v1/runtimes/{id}/chat answers 503 when the runtime's last start failed under 120 seconds ago. Chat starts a stopped runtime, so a client that retries on failure turns each attempt into another deploy. Wait out the cooldown, or call the start endpoint to see the underlying error.

Packages — OpenAPI spec and SDK → 0.59.10. Purely additive: the two browser-device routes, the newly required fill fields, and the 409/503 responses above.

---

2026-08

v0.59.12 (2026-08-31)

Discoverability — two catalogues that were previously prose only

• GET /v1/runtimes/templates — the provisionable runtime template catalogue, with chat_capable per entry. Public, no auth. This path previously collided with /v1/runtimes/{runtime_id} and answered 400 UUID parsing failed.
• GET /v1/automations/step-types — the full workflow_spec step vocabulary (14 types), each marked agent_allowed and moves_funds, plus step caps and the run timeout. Public, no auth.
• Unrecognised automation step types are still skipped rather than fatal, but the run output now names the step and lists the known types instead of reporting a bare "unsupported step type".

Platform API

• PATCH /v1/platform/apps/{id} accepts redirect_uris from a plt_ key. Previously no platform-key route could change them, so an app moving domains needed a human operator token.
• A refused PATCH now names the offending fields rather than only restating which field is permitted, so a reconcile loop can retry without them.

---

v0.59.8 – v0.59.11 (2026-08-30 → 08-31)

Integrator-affecting: the OIDC issuer moved

The Vault mints and advertises https://api.1claw.co as its issuer. The legacy issuer https://api.1claw.xyz is still accepted on validation — tokens minted before the move stay valid until they expire — but is never minted. If you pin an expected iss, accept both during the transition.

The OIDC discovery document previously advertised an authorization_endpoint on the legacy apex, which now 301s; a redirect inside an authorization request can drop state or code_challenge. It is now on https://1claw.co.

WebAuthn rp_id also moved to 1claw.co. Passkeys enrolled against the old origin cannot be used on the new one; affected users are re-prompted to enrol.

• Billing — the dashboard metering exemption is now scoped to the three polled endpoints (GET /v1/runtimes, /v1/runtimes/{id}, /v1/automations) in addition to requiring a non-api_key caller. Session-authenticated GETs to other routes, including secret reads, are billable and count toward the monthly quota.
• Email OTP — the per-address send budget is now scoped to (address, sender). Previously anyone who knew an address could spend its budget and silently suppress the owner's sign-in code.
• Automations — platform-created workflows are validated at create and re-validated at run.
• SMTP execution — a recipient value must be a single mailbox; commas, semicolons and whitespace are rejected, so a list cannot be smuggled past the per-execution recipient cap.
• Packages — OpenAPI spec, SDK, CLI, MCP → 0.59.8; @1claw/wallet-react → 0.5.2; Python SDK → 0.59.8. All client defaults moved to api.1claw.co.
• docs.1claw.xyz now redirects (308) to docs.1claw.co.

---

v0.59.5 – v0.59.7 (2026-08-27 → 08-29)

• Content inspection — POST /v1/shroud/inspect-content REST parity, webhooks catalog.
• Onboarding — golden-path provisioning, runtime log streams, runtime chat history.
• Midnight / NIGHT chain family support behind ONECLAW_MIDNIGHT_ENABLED (Preprod only).
• Auth — email-OTP sign-in promoted on the login page; passkey rp_id recorded per credential.

---

v0.59.4 (2026-08-27)

Platform connection expansion

• GET /v1/platform/connections/{id}/portfolio (alias GET .../balances) — unified balances for connection agents (?chains=, ?include_tokens=).
• POST /v1/platform/connections/{id}/pending-approvals — create consensus/HITL pending approval for connection agent (202).
• Connection automations — GET/POST .../automations, POST .../automations/{aid}/runs/{rid}/cancel (plt_-scoped; not org /v1/automations).
• Connection memory — GET/PUT/DELETE .../memory/{namespace}/{key} (optional ?agent_id=).
• POST /v1/shroud/inspect-content — REST parity with MCP inspect_content (fail-closed threat scan).
• Docs sync — webhook events (pending_approval.created, tx.awaiting_approval, sign.awaiting_approval, automation.run.failed), idempotency matrix, siwe_domain, provisioned_tier / platform_pays.

Packages

• OpenAPI spec, SDK, CLI, MCP, Python SDK → 0.59.4

---

v0.59.3 (2026-08-27)

Platform connection operations (Fathom parity)

• GET /v1/platform/connections/{id}/signing-keys — list agent signing keys (public metadata: chain, address, public_key, curve). Optional ?agent_id=. Use instead of org-scoped GET /v1/agents/{id}/signing-keys with plt_ keys.
• GET .../signing-keys/{chain} — single-chain lookup with same metadata.
• PATCH /v1/platform/connections/{id}/agents/{agent_id} — enable intents_api_enabled, execution_intents_enabled, or update system_prompt on existing bootstrapped agents without re-bootstrap.
• Docs: Platform API overview clarifies wallet_address (SIWE staker identity) vs agent signing key address (signing-keys endpoints / bootstrap summary.signing_keys).
• Template aliases: intents: true, intents: { enabled: true }, intents_api_enabled: true (and execution equivalents) documented in overview.

Packages

• OpenAPI spec, SDK (listConnectionSigningKeys, getConnectionSigningKey, patchConnectionAgent), CLI, MCP → 0.59.3
• Python SDK (oneclaw) → 0.59.3

---

v0.59.2 (2026-08-27)

Onboarding golden path (MCP stdio)

• GET /v1/org/onboarding/status — human-only progress: welcome bundle, agent, policy, sample secret, first read.
• POST /v1/onboarding/provision — idempotent welcome vault (default), examples/hello, MCP agent, ** read/write policy, one-time ocv_ key, and mcp_stdio_config (stdio npx @1claw/mcp).
• Signup hooks — async welcome bundle after email verify, Google signup, social login, email OTP.
• Agent create — skip_default_policy on POST /v1/agents; default onboarding applied on human create and enrollment approve unless skipped.
• Dashboard — /onboarding/connect wizard, connect CTA on dashboard/sidebar/marketing; post-login redirect to connect flow.
• CLI — 1claw setup calls /v1/onboarding/provision instead of manual vault/policy steps.
• MCP — vault auto-discovery prefers vault named default; GET /.well-known/oauth-protected-resource on httpStream (metadata).
• Tests — scripts/test-onboarding-prod.sh; wired into run-production-tests.sh and OpenAPI contract checks.

Packages

• OpenAPI spec, SDK (client.org.getOnboardingStatus(), .provisionOnboarding()), CLI, MCP → 0.59.2
• MCP registry: io.github.1clawAI/1claw-mcp @ 0.59.2

---

v0.59.0 (2026-08-27)

Fathom platform integration (migration 221)

• agents.system_prompt — default chat system prompt on create/update and template agents[].system_prompt at bootstrap.
• Connection chat — POST /v1/platform/connections/{id}/agents/{aid}/chat accepts system, system_prompt, and messages[] with role: system; billing failures return 402 (not 500).
• Connection passkey enroll — POST .../passkeys/enroll/begin|complete for plt_-scoped WebAuthn registration of connected end-users. Withdrawn 2026-08-27 and now always 403. A passkey is exchangeable for a full, non-delegated user session through the public assert flow, so an app able to enrol one held a credential stronger than the delegation boundary it operates under. The user enrols in their own session instead.
• Connection runtime GET — GET /v1/platform/connections/{id}/runtimes/{runtimeId} (plt_ scoped; use instead of GET /v1/runtimes/{id}).
• platform_pays tier inheritance (migration 220) — Template plan at bootstrap grants tier to end-user org; GET /v1/platform/connections/{id} returns provisioned_tier.
• Bootstrap runtime fix — provision_runtime uses valid Cloud Run provider and respects tier limits.
• OpenAPI — GET /v1/platform/apps/{id}/users response wraps { users: [] }; passkey enroll schemas added.

Packages

• OpenAPI spec, SDK, CLI, MCP, Python SDK, Go SDK → 0.59.0
• New SDK/MCP/CLI methods: getConnectionRuntime, connectionPasskeyEnrollBegin|Complete, system_prompt types
• MCP tools: platform_get_connection_runtime, platform_connection_passkey_enroll_begin
• Prod tests: scripts/test-platform-expansion-prod.sh (passkey begin, runtime GET, system_prompt chat)

---

v0.58.2 (2026-08-26)

Platform connection control plane (runtime + chat)

• Bootstrap runtimes: Top-level runtimes[], nested agents[].runtime, and provision_runtime: true (+ runtime_preset / runtime_template) now create Cloud Runtimes during bootstrap. Connection detail includes runtime_ids and automation_ids.
• GET /v1/platform/apps/{id}/templates/{tid} — plt_ or user JWT; inspect template spec after bootstrap.
• POST /v1/platform/connections/{id}/runtimes — create runtime in end-user org (fixes plt_ → POST /v1/runtimes 404).
• POST /v1/platform/connections/{id}/agents/{aid}/chat — connection-scoped agent chat (fixes plt_ → POST /v1/agents/{id}/chat 403).
• Spend-policy PUT replace — second write no longer 500 (unique per-user app policy).
• Connection-scoped control: pending-approval get/decide, mobile approval decide, signing-key deactivate (v0.58.0 continued).

Tests: scripts/test-platform-expansion-prod.sh covers template GET, spend-policy replace, control-plane routes, bootstrap provision_runtime, connection runtime create, connection chat.

---

v0.58.1 (2026-08-25)

Agent-created automations (chat/runtime)

• POST /v1/agents/{agent_id}/automations — agent-token only. Simple manual/webhook workflows with guardrailed steps (log, notify, memory_get, memory_put, wait; max 10 steps, 25 per agent). Optional auto_trigger for manual runs. Humans remain on POST /v1/automations (agents get 403).
• created_by_type on automations (human | agent, migration 218). Dashboard shows an Agent-created badge.
• Runtime tools: create_automation, create_test_automation, agent-access tools (request_access, request_approval, request_binding, request_signing_key, request_guardrail_change), forget, capabilities prompt injection across Hermes/OpenClaw/OpenClaude/OpenCode templates.
• Vault: request_timeout middleware, runtime chat cold-start improvements.

Packages

• OpenAPI spec, SDK (agents.createAutomation()), MCP (create_agent_automation), Python SDK (agents.create_automation()), Go SDK (Agents.CreateAutomation()), CLI (1claw agent automation create) → 0.58.1
• MCP registry: io.github.1clawAI/1claw-mcp @ 0.58.0 (tool shipped in prior release)
• Prod tests: scripts/test-automations-prod.sh §24 (agent-scoped create + human-route 403)

---

v0.58.0 (2026-08-24)

Platform API control plane (Fathom bundled release)

• SIWE recovery ids: Accept EIP-191 signatures with recovery byte 27 or 28 (MetaMask/viem) in addition to 0/1.
• App-scoped reads (plt_): GET /v1/platform/connections/{id}/approvals, .../approvals/{approval_id}, .../pending-approvals (includes payload_hash), .../spend-policy.
• Spend policy: GET /v1/platform/apps/{id}/spend-policies/{policy_id}; PUT .../connections/{id}/spend-policy supports optional Idempotency-Key (24h body-hash replay).
• App lifecycle: PATCH slug changes → 400; DELETE soft-deactivates and returns { id, slug, deleted_at }; GET inactive app → 404; slugs unique per org (migration 216).
• Ownership transfer: POST /v1/platform/apps/{id}/transfer-ownership with step-up auth.

Packages

• Vault API 0.58.0 (migrations 216–217)
• OpenAPI spec, SDK, CLI, MCP, Python SDK, Go SDK → 0.58.0 with Platform control-plane parity
• MCP registry: io.github.1clawAI/1claw-mcp @ 0.58.0
• New MCP tools: platform_list_connection_approvals, platform_get_connection_approval, platform_list_connection_pending_approvals, platform_get_connection_spend_policy, platform_get_spend_policy, platform_transfer_ownership, platform_delete_app
• Prod tests extended: scripts/test-platform-api.sh, scripts/test-platform-expansion-prod.sh

---

v0.57.0 (2026-08-24)

Platform API expansion (migration 215)

• SIWE wallet provisioning: POST /v1/platform/siwe/challenge + upsert with subject_token_type: urn:1claw:params:oauth:token-type:siwe, siwe_message, siwe_signature. Atomic DB nonces; siwe_domain on platform apps.
• Parameterized bootstrap: parameters on bootstrap requests; POST .../templates/{id}/preview for dry-run; params-aware bootstrap idempotency via Idempotency-Key + body hash.
• Connection polling: GET /v1/platform/connections/{id} returns claim status, entitlement_status, wallet_address, resource IDs.
• Per-connection usage: GET .../connections/{id}/usage — monthly inference_spent_usd.
• On-chain entitlements: Template entitlements[]; GET/POST .../entitlements + refresh; background monitor; webhooks platform.entitlement.granted/revoked.
• Inference budgets: Spend policy fields (inference_allowance_usd, max_request_cost_usd, etc.); JWT inference_budget claim; Shroud per-request cap; GET /v1/treasury/wallets/inference-budget.
• Claim expiry webhook: Background worker fires platform.claim.expired when 10-min claim tokens lapse unclaimed.

Packages

• Vault API, OpenAPI spec, SDK, CLI, MCP bumped to 0.57.0
• Python SDK tag 0.57.0 (CI publish)
• MCP registry: io.github.1clawAI/1claw-mcp @ 0.57.0
• New prod tests: scripts/test-platform-expansion-prod.sh

---

v0.56.3 (2026-08-24)

Cumulative gas budget & outbound idempotency

• gas_daily_budget_native: Per-chain guardrail field in per_chain_guardrails — UTC-day cumulative EVM gas (sum of gas_limit × max_fee) enforced alongside per-tx max_fee_per_gas_gwei / max_gas_limit. Tracked in agent_gas_ledger (migration 213).
• inject_idempotency_key: Binding guardrail — when true, Vault injects a deterministic Idempotency-Key on outbound HTTP/GraphQL execute requests (SHA-256 hex of binding id, HTTP method, path, and JSON body). Wired in domain/execution/http.rs and graphql.rs.
• Expo push on approvals: When ONECLAW_EXPO_ACCESS_TOKEN is set, pending approval/HITL events send best-effort Expo push notifications to registered mobile device tokens (domain/push_notify.rs, wired from approval_notify.rs).
• Passkey for login 2FA (migration 214): Per-user require_passkey_for_mfa via GET/PATCH /v1/auth/settings. When enabled, password/social/email-OTP login returns mfa_method: "passkey" and completes via POST /v1/auth/mfa/passkey/begin + .../complete instead of TOTP. Disabling requires step-up (X-Auth-Confirm, purpose security.mfa_passkey.disable). Dashboard toggle on Settings → Security MFA card.

Packages

• Vault API, OpenAPI spec, SDK bumped to 0.56.3

---

v0.56.2 (2026-08-24)

Guardrail widening approvals & treasury HFA passkey parity

• Guardrail widening queue: Binding and agent guardrail edits that widen access now require policy_change approval with step-up re-auth (X-Auth-Confirm). PATCH handlers return 202 with pending_approval_id until approved.
• Treasury HFA passkey parity: Swap operations support passkey tx-assert digests (treasury_swap_digest); send/swap/export honor Human Factor Auth with passkey-only flows in dashboard and @1claw/wallet-react.
• HFA audit events: human_factor_auth.satisfied / human_factor_auth.denied emitted on treasury wallet operations.

Phase 5 Safe foundation (counterfactual)

• Agent accounts API: GET/POST /v1/agents/{id}/accounts, POST .../accounts/migrate, POST .../accounts/{chain}/deprecate-eoa — counterfactual Safe provisioning, EOA→Safe migration wizard, execTransaction signing path.
• Module registry: GET /v1/safe/module-registry/{chain} — pinned Safe v1.4.1 + Zodiac module addresses per chain.
• Org allowance sync: POST /v1/org/safe/sync-allowances — compiles allowance targets from agent guardrails; returns drift report (onchain_sync: counterfactual).
• Guard.sol: Foundry scaffold with tests; on-chain deploy/cosign/passkey/timelock/4337 stubs return 501 pending external audit.
• Dashboard: Safe migration wizard at /agents/[agentId]/migrate-safe.

Tests & tooling

• HFA unit tests (human_factor_auth.rs); guardrail shadow/revisions/replay checks in scripts/test-guardrails-prod.sh.
• CLI: 1claw agent accounts list|migrate|deprecate-eoa, 1claw safe module-registry|sync-allowances.
• Prod smoke: scripts/test-safe-prod.sh.

Packages

• Vault API, OpenAPI spec, SDK bumped to 0.56.2
• MCP: list_agent_accounts, migrate_agent_to_safe, deprecate_agent_eoa, get_safe_module_registry, sync_org_safe_allowances

---

v0.56.0 (2026-08-24)

Guardrail governance, HFA, Safe foundation (Phases 3–6)

• Convention 6 shadow/enforce on execution guardrails — enforcement: "log"|"enforce" on bindings and agents; audit guardrail_shadow.would_deny.
• Address screening — per-agent address_screening_policy (mode: off | deny | approve); env deny list ONECLAW_SCREENING_DENY_LIST.
• Solana simulate_first on non-EVM submit/sign when configured.
• Governance APIs: GET /v1/org/guardrail-shadow-report, GET /v1/org/guardrail-revisions, POST /v1/agents/{id}/guardrails/replay.
• Guardrail revisions recorded on agent/binding guardrail PATCH.
• Org unfreeze T3 step-up; webhook org.unfrozen.
• Execution honeytoken on vault-ref credential loads.
• Shroud tx escalation — POST /v1/admin/shroud/tx-escalations; Shroud heuristics escalate to HITL.
• HFA on treasury send/swap/export; Safe stubs — agent accounts + module registry.

Packages

• Vault API, OpenAPI spec, SDK, CLI, MCP bumped to 0.56.0
• CLI: 1claw guardrails shadow-report|revisions|replay
• Dashboard: Settings → Security → Guardrails tab

---

v0.55.0 (2026-08-24)

Guardrail phases 1.3–2.7 (extended HITL & enforcement)

• Sign HITL: EIP-712 typed data and raw digest signing can route to 202 awaiting_approval when typed_data_policy or raw_signing_policy is approve. Webhook: sign.awaiting_approval. Approve via /v1/approvals/{id}/decide auto-executes stored sign intent.
• Simulation HITL: Tenderly revert can route to tx HITL when simulation_failure_policy is approve (instead of 422).
• Extended tx guardrails: tx_block_unlimited_approvals, per-recipient daily limits, new-recipient caps, USD caps (tx_max_value_usd, tx_daily_limit_usd), gas budget checks, in-flight daily budget reservations (tx_budget_reservations).
• Signing policies: raw_signing_policy (allow/deny/approve), personal_sign_policy JSON, allow_erc4337, allow_eip7702.
• Execution guardrails (2.4–2.7): binding time windows + source IP (execution_conditions), outbound secret pattern scan, per-binding concurrency cap.
• Org freeze: POST /v1/org/freeze and POST /v1/org/unfreeze (owner/admin emergency stop).

Packages

• Vault API, OpenAPI spec, SDK, CLI, MCP bumped to 0.55.0

---

v0.54.0 (2026-08-24)

Graduated guardrails & HITL (Phase 1–2)

• Transaction HITL: agents.tx_approval_policy JSON — graduated thresholds (require_above_native, require_for_chains, require_for_new_recipients, unlimited ERC-20 approve detection). Matching txs return 202 awaiting_approval with approval_id; humans approve via /v1/approvals/{id}/decide to resume signing.
• Execution HITL: Binding guardrails.approval_policy (mode: off | always | conditional) and allowed_methods. Execute returns 202 approval_required when policy matches; approve auto-runs the intent.
• dry_run on execute: Validates guardrails and approval policy without side effects (status: dry_run).
• Circuit breaker: Repeated guardrail denials can auto-suspend agents (auto_suspended); org-level frozen_at. Webhooks: tx.awaiting_approval, execution.pending, agent.suspended, org.frozen.
• Agent API: tx_approval_policy, typed_data_policy, simulation_failure_policy, auto_suspended on GET; PATCH supports clear_auto_suspended (owner/admin).
• Production scripts: scripts/test-guardrail-hitl-prod.sh; extended scripts/test-execution-guardrails-prod.sh (allowed_methods, dry_run).

Packages

• Vault API, OpenAPI spec, SDK, CLI, MCP bumped to 0.54.0
• MCP: execute_intent accepts dry_run; CLI: 1claw approval status <id>

---

v0.53.4 (2026-08-23)

Execution guardrails (Phase 0)

• Machine-readable guardrail_violation JSON on execute denials (reason_code, optional limit / current / attempted)
• Per-binding guardrails: max_request_bytes, max_response_bytes, allowed_request_headers, GraphQL depth/mutation/introspection limits, DNS-pinned HTTP/GraphQL clients
• Per-binding and per-agent max_requests_per_minute — denied executions do not count toward RPM
• GET /v1/approvals/{approval_id}/status — agent-only lightweight approval poll
• Production script: scripts/test-execution-guardrails-prod.sh

Packages

• Vault API, OpenAPI spec, SDK, CLI, MCP (io.github.1clawAI/1claw-mcp / @1claw/mcp) bumped to 0.53.4
• MCP tool: get_approval_status
• SDK: client.approvals.getStatus()

---

v0.53.3 (2026-08-20)

Execution Intents parity

• All ten binding type executors are live on Pro+ (HTTP, GraphQL, Postgres, MySQL, Redis, gRPC, SMTP, Cloud SDK, S3, Custom)
• Production regression script section 30 supports optional EXEC_* real-service smoke tests
• Dashboard Security settings: env policy, credential recovery, and Shamir KEK endpoints wired correctly

1claw.co domain parity

• api.1claw.co, mcp.1claw.co, shroud.1claw.co, intents.1claw.co, and run.1claw.co mirror .xyz routing
• Smoke and Shroud prod scripts validate .co health endpoints

Docs & packages

• SDK, CLI, MCP (io.github.1clawAI/1claw-mcp / @1claw/mcp), OpenAPI spec, Python SDK bumped to 0.53.3
• Marketing copy and agent skills updated for Pro+ binding tier gating

---

v0.53.2 (2026-08-19)

Release engineering & OpenAPI sync

• OpenAPI @1claw/openapi-spec 0.53.2: ShroudAttestationResponse adds attestation_level (none | identity | confidential | sev_snp) and confidential_claims (SEV-SNP tier metadata)
• SDK, CLI, MCP, Python SDK, Go SDK, and OpenClaw plugin bumped to 0.53.2
• Production test scripts validate attestation_level on GET /v1/shroud/attestation
• @1claw/wallet-react v0.5.0 — audit-driven auth/session fixes; parent submodule pointer updated

Shroud & execution

• SEV-SNP attestation verification with measurement match against published image digest
• TEE execution forwarding: Vault POST /v1/agents/{id}/execute with execution_mode: "tee" dispatches to Shroud when ONECLAW_SHROUD_EXECUTION_URL is configured
• Shroud secrets manifest refresh notifications for faster redaction automata updates

Dashboard & policy UI

• Policy Engine v2 dashboard parity: tx conditions editor, consensus skip_when / require_when, expression engine fields
• Embedded wallet UX improvements and blog post on competitive positioning

Security (2026-08-19 audit)

• HIGH/MEDIUM findings from security audit remediated in vault and dashboard

---

v0.53.1 (2026-08-19)

Raw Transaction Deep Decode

• Added raw_transaction (base64) and tron_transaction (JSON) fields to sign and submit endpoints
• Pre-built Solana, Bitcoin, and Tron transactions are now deep-decoded for policy enforcement
• Base64 validation and 64KB size cap enforced server-side

Credential Recovery Hardening

• Split approve/execute into two steps with configurable delay window (default 72 hours)
• Added POST /v1/auth/credential-recovery/requests/{id}/execute endpoint
• Admin/owner role verification required for approve and execute actions
• Org-configurable credential_recovery_delay_hours setting

Shamir KEK TEE Forwarding

• Reconstruct endpoint now forwards to Shroud TEE for secure key reconstruction
• Returns 501 when Shroud is not configured (deployment without TEE)
• Shroud stub handler at POST /v1/admin/shamir/reconstruct

Wallet Access Policies

• New CRUD endpoints: POST/GET/DELETE /v1/treasury/wallets/access-policies
• Per-chain, per-agent/user permission policies with conditions (value caps, token allowlists)

OpenAPI Specification

• 15 new endpoint definitions (wallet access, credential recovery, Shamir KEK, execute)
• Full request/response schemas with component definitions

Expression Engine & Chain Decoders

• Expression engine now evaluated in signing path for schema v2 policies
• Solana, Bitcoin, and Tron transaction decoders integrated into policy context builder
• Fail-open fallback when decode fails (graceful degradation)

---

v0.53.0 — Embedded Wallet Competitive Parity (2026-08-19)

Whole-agent governance hardening for embedded wallet competitive parity with Turnkey-style signing infrastructure.

New features

• Expression engine — Mini DSL in tx_conditions.expression for signing-time policy evaluation (schema version 2). Fail-closed with step budget and length limits.
• Policy schema versioning — policy_schema_version on access policies (migration 202). Version 1 = legacy field-matching; version 2 = expression engine support.
• TEE attestation endpoint — Public GET /v1/shroud/attestation on Shroud returns GCE identity token + image hash with verification steps.
• Audit chain verification — GET /v1/audit/verify returns org-scoped hash chain integrity result with HMAC-SHA256 scheme metadata.
• Multi-chain deep decode — Full Solana, Bitcoin, and Tron transaction parsers feed TransactionContext for policy engine evaluation.
• Control-plane action kinds — action_kind_in on consensus triggers for version-agnostic grouping (e.g. signing_key.*, policy.*).
• Approval bypass — approval_id on consensus-gated requests (policy create, agent create, signing key export, treasury send).
• Shamir org KEK — Infrastructure for 2-of-3 Shamir KEK custody across HSM providers (migration 203).
• Credential recovery escape hatch — Time-delayed recovery for MFA/passkey consensus gating in solo/small orgs (migration 204).
• Wallet access policies — Role-based wallet permissions schema (migration 205).
• allowed_tokens enforcement — Spend policies now enforce allowed_tokens at signing time.

Security docs

• Security overview, trust model comparison, Turnkey migration guide, security whitepaper.
• Policy versioning guide, external security review scope runbook.

Migrations

• 202: access_policies.policy_schema_version
• 203: organizations.kek_custody, org_kek_shares, org_kek_recovery_codes
• 204: credential_recovery_requests
• 205: wallet_access_policies, users.wallet_roles, agents.wallet_roles

Clients

• @1claw/sdk@0.53.0, @1claw/cli@0.53.0, @1claw/mcp@0.53.0, @1claw/openapi-spec@0.53.0
• Python SDK oneclaw@0.53.0, Go SDK v0.53.0
• Vault 0.53.0, Shroud 0.8.0

---

v0.52.0 — Agent Environment Tagging (2026-08-18)

Tag agents with a named environment for policy scoping and automatic env var resolution.

New features

• Agent environment tag — environment, environment_locked, env_auto_resolve, and per_environment_guardrails on agents.
• JWT claim — Agent tokens include environment when the agent is tagged.
• Policy scoping — Access policy conditions.environment_in restricts policies to specific environments.
• Auto-resolve — When env_auto_resolve is true, GET /v1/vaults/{id}/env-vars/resolve uses the agent's tag when environment is omitted.
• CLI flags — --environment, --environment-locked, --env-auto-resolve on create; update supports --per-environment-guardrails.
• Dashboard — Environment tag UI on agent create and detail pages.

Bug fixes

• consensus_policy unit tests updated for require_credential_types field.

Migrations

• 201: agents.environment, environment_locked, env_auto_resolve, per_environment_guardrails

Clients

• @1claw/sdk@0.52.0, @1claw/cli@0.52.0, @1claw/mcp@0.52.0, @1claw/openapi-spec@0.52.0
• Python SDK oneclaw@0.52.0, Go SDK v0.52.0

---

v0.51.0 — Environment Variables (2026-08-18)

First-class per-key environment variables on vaults, bringing Vercel-style env management to 1Claw.

New features

• Per-key env vars — Store DATABASE_URL, STRIPE_KEY, etc. as individual encrypted entries targeting specific environments (production, preview, development, custom). Replaces the config/prod/* path hack.
• Named environments — Built-in production/preview/development plus tier-gated custom environments with copy-from support.
• Org shared vars — Organization-level env vars linked to multiple vaults. Vault-level vars with same key+environment always win.
• Resolution endpoint — GET /v1/vaults/{id}/env-vars/resolve returns the final KEY=VALUE set with three-tier precedence (shared < vault < branch override).
• Sensitive write-only vars — Values non-readable after creation for human callers. Disallowed on Development-only. Org enforcement policy available.
• Cloud Runtime injection — Resolved env vars merged into container environment at start/rebuild. 64KB combined limit. Restart required for changes.
• CLI commands — env ls, env add, env rm, env environments ls|add|rm, -e flag on pull/push/run.
• SDK — client.envVars.list(), .create(), .get(), .update(), .delete(), .resolve().
• MCP — resolve_env tool.
• Dashboard — Env Variables tab on vault detail, Shared Env Vars settings page, environment management.

Bug fixes

• CLI env pull now correctly unwraps the { secrets: [...] } response wrapper.
• CLI env push now sends type instead of secret_type (matching the API's serde rename).

Migrations

• 197: env_vars table
• 198: vault_environments table (built-in + custom)
• 199: org_env_vars and org_env_var_links tables
• 200: runtimes.environment column

Clients

• @1claw/sdk@0.51.0, @1claw/cli@0.51.0, @1claw/mcp@0.51.0, @1claw/openapi-spec@0.51.0

---

Auth & dashboard security (2026-08-17)

Human authentication

• Changed: TOTP MFA is available on all tiers (including Free); the Pro+ gate was removed.
• New: Per-user setting require_passkey_for_vaults (migration 193) — when enabled, GET secret reads require X-Passkey-Token from a user-verified WebAuthn assertion.
• New: GET/PATCH /v1/auth/settings — read/update require_passkey_for_vaults (user-only; enabling requires at least one registered passkey).
• New: POST /v1/auth/passkeys/vault-assert/begin + .../complete — issue a reusable 5-minute vault unlock token after passkey verification.
• New: Dashboard passkey suggestion prompt after login for users without a passkey (dismissible, 7-day snooze). Toggle in Settings → Security ("Vault unlock" card).

---

v0.50.0 — Policy Parity Sprint (2026-08-18)

Consensus precision & approver identity

• New: threshold_wei on ConsensusCondition::value_above — arbitrary-precision wei thresholds (preferred over deprecated threshold_gwei).
• New: required_roles, per_role_minimums, and require_credential_types on consensus approval requirements — enforce role-based and credential-gated approvals (e.g. require passkey-verified approver).
• New: credential_type on approval_signatures (migration 195) — records auth method used at vote time (password, passkey, totp, biometric, api_key).

EIP-712 & EIP-7702 policy conditions

• New: tx_conditions fields: eip712_primary_type_in, eip712_verifying_contract_in, eip712_domain_name_in, eip712_domain_chain_id_in — fine-grained typed data signing policies.
• New: eip7702_authorized_addresses_in — restrict EIP-7702 delegate contracts via authorization_list in TransactionContext.

Control-plane governance

• New: Org setting control_plane_consensus_policy_id — gates policy CRUD, signing key export, and member mutations behind consensus (returns 202).
• New: ConsensusCondition::action_in — match control-plane actions (policy.create, policy.update, policy.delete, signing_key.export, member.role_change, member.remove).

Clients

• @1claw/sdk@0.50.0, @1claw/cli@0.50.0, @1claw/mcp@0.50.0, @1claw/openapi-spec@0.50.0
• Python SDK oneclaw@0.50.0, Go SDK v0.50.0

---

v0.49.0 — Policy engine composability & deep inspection (2026-08-17)

Built-in transaction policies

• New: tx_conditions.match_mode — "all" (default, AND) or "any" (OR) for combining individual condition fields at signing time.
• New: tx_conditions.deep_inspect — when true, conditions are also evaluated against inner calls extracted from wrapper transactions (multicall, Safe execTransaction, ERC-4337 handleOps).

Policy time windows

• New: IANA timezone and cron_expr on policy conditions.time_window — schedule-aware access control with timezone-aware hour/day checks and cron matching.

Consensus composability

• New: consensus_trigger.skip_when — array of flat condition sets; when ALL fields in ANY entry match, consensus is bypassed.
• New: consensus_trigger.require_when — consensus is only required when at least one entry matches; if set and none match, consensus is skipped.
• New: consensus_trigger.deep_inspect — evaluate consensus conditions against inner wrapper calls, not just the outer transaction.

Deep decode

• New: crypto/deep_decode.rs — unwraps multicall, Safe, and ERC-4337 batch transactions to populate inner_calls on TransactionContext for policy evaluation.

Fixed

• Fixed: POST /v1/pending-approvals/{id}/execute no longer returns 500 when JSONB key reordering caused payload_hash mismatch — canonical alphabetical key sorting in pre_sign.rs.

Clients

• @1claw/sdk@0.49.0, @1claw/cli@0.49.0, @1claw/mcp@0.49.0, @1claw/openapi-spec@0.49.0
• Python SDK oneclaw@0.49.0, Go SDK v0.49.0
• Integration packages @1claw/agentkit, @1claw/openclaw-plugin, @workspace/1claw-hermes, 1claw-mobile at 0.49.0

---

v0.48.2 — tx_conditions, consensus tokens & security hardening (2026-08-17)

Built-in transaction policies

• New: tx_conditions JSONB on access_policies (migration 189) — AND of present fields evaluated at signing time: function_name_in, function_selector_in, erc20_amount_above, value_above (gwei), to_address_in, chain_in, intent_type_in, decode_failed, program_id_in. All tiers. Dashboard: TxConditionsEditor on policy create/edit.

Contract ABI registry

• New: interface_kind on contract ABIs (migration 190) — evm_abi (default) or solana_idl for Anchor IDL decoding. Solana program instructions populate function_name, program_id_in, and related TransactionContext fields.

Consensus / pending approvals

• New: Single-use approval_id bypass token (migration 191) — consumed atomically on execute, submitter-bound (only the original submitter can execute). Works on the EVM submit path after human approval.

Treasury delegation

• Fixed: Per-delegation guardrails (to_allowlist, allowed_chains, max_value_eth) are now enforced at signing time during treasury-mode Intents API requests — strictest of agent + delegation limits wins.

Security & reliability

• Changed: ip_filter middleware fail-closed on DB errors (500 instead of silent allow). Production requires ONECLAW_PROXY_SECRET for trusted proxy header validation.
• New: Runtime JWT runtime_id claim; auth middleware validates X-1Claw-Runtime-Id matches the token (prevents cross-runtime replay).
• Fixed: OPA WASM evaluation uses wasmtime epoch interruption for reliable timeout enforcement.
• Fixed: Treasury wallet send double-conversion of value_wei.
• Fixed: Agent enrollment anti-spam — bounded cooldown map, sensitive target threshold.

Docs

• New: Policy Engine v2 guide, Policy language, Policy cookbooks.

Clients

• @1claw/sdk@0.48.2, @1claw/cli@0.48.2, @1claw/mcp@0.48.2, @1claw/openapi-spec@0.48.2
• Python SDK oneclaw@0.48.2, Go SDK v0.48.2

---

v0.48.1 — Client package alignment (2026-08-14)

Clients

• Changed: Submodule pointers aligned for npm/PyPI publish — SDK, CLI, MCP, OpenAPI spec, Python SDK (__version__ fix), Go SDK at 0.48.1.
• Changed: @1claw/wallet-react@0.4.2 — passkey tx digest binding for treasury send/swap.

---

v0.48.0 — Cedar/OPA Enforcement v2 (2026-08-14)

Policy backend

• New: GET/PATCH /v1/org/settings/policy-backend — configure Cedar/OPA backend (builtin, cedar, opa, builtin+cedar, builtin+opa), mode (shadow default or enforce), scope actions, and circuit breaker (fail_closed default).
• New: GET /v1/org/policy-shadow-report — divergence report when running advanced backends in shadow mode.

Contract ABIs

• New: POST/GET/DELETE /v1/org/contract-abis, GET /v1/org/contract-abis/{id} — org-scoped ABI registry for transaction decoding in policy evaluation.

Consensus / pending approvals

• New: consensus_trigger on access policies — structured conditions (value, chain, address, function selector, ERC-20 amount, intent type, always).
• New: POST/GET /v1/pending-approvals, approve/execute/cancel endpoints — multi-party approval workflow; sign/transactions return 202 when consensus matches.
• New webhook events: pending_approval.*, policy_backend.circuit_breaker_*.

Cedar/OPA

• Changed: Cedar and OPA policy responses include dynamic enforcement_status (shadow, enforce, inactive) from org backend config.

Clients

• @1claw/sdk@0.48.0, @1claw/cli@0.48.0, @1claw/mcp@0.48.0, @1claw/openapi-spec@0.48.0
• Python SDK oneclaw@0.48.0, Go SDK v0.48.0

---

v0.47.3 — Billing quotas: wallets, signatures, Free treasury (2026-08-13)

Quotas

• Changed: Dropped the 0.25% of transaction-value Intents fee. Signature overage is a flat per-signature charge (proxy_transaction_submit rates: Free $0.225, Pro $0.15, Team $0.075, Business $0.04) via prepaid credits or x402. Included signatures remain free up to the monthly quota.
• Changed: Business API calls/month raised to 1,000,000 (was 500,000).
• New: Unified wallet quota covering active treasury wallets, agent signing keys, smart accounts, and agents with an EOA. Free 10, Pro 10,000, Team 250,000, Business 1,000,000, Enterprise unlimited.
• New: Monthly signature quota (Free 100, Pro 20,000, Team 200,000, Business 1,000,000). Over quota is billed, not hard-blocked.
• Changed: Signing POSTs (POST /v1/agents/{id}/sign, /transactions, /transactions/sign) no longer consume the API Calls meter.

Treasury wallets

• Changed: Treasury wallet generate/import/rotate/send/swap are available on all tiers (no Pro+ gate). Counted against the wallet quota. Dashboard /treasury is no longer Pro-walled.

API

• Changed: GET /v1/billing/subscription usage now includes wallets ({ used, limit }) alongside requests and intent_transactions.

Quotas (runtime hours)

• Fixed: Runtime hour caps now match the pricing page: Pro 100h/mo (was 720h), Team 500h/mo (was 7,200h), Business 2,000h/mo (was 18,000h). Enforcement in tier_limits() was out of sync with customer-facing limits.

Pricing clarity

• Changed: Restored Pro wallet quota to 10,000 and signature quota to 20,000 (reverts interim 100/1,000 limits).
• Changed: Pricing page and docs now distinguish Execution Intents (Pro+, HTTP/GraphQL binding calls, hard monthly execution cap) from Intents API (Business+, on-chain signing, Signatures/mo meter).

Clients

• @1claw/sdk@0.47.3, @1claw/cli@0.47.2, @1claw/openapi-spec@0.47.3
• Python SDK oneclaw@0.47.3, Go SDK v0.47.3

---

v0.47.0 — Key Import, Policy Engine v2, Sub-Orgs & Portfolio (2026-08-13)

Key Import (BYOK)

• New: POST /v1/agents/{id}/signing-keys/{chain}/import — Import an existing private key as a signing key. Human-only, requires X-Auth-Confirm password re-authentication. Supports hex, base64, and WIF formats.
• New: POST /v1/treasury/wallets/{chain}/import — Import an existing private key as a treasury wallet. Human-only, requires X-Auth-Confirm.

Policy Engine v2 + Cedar + OPA

• New: Existing access policies now support effect ("allow" or "deny"), priority (higher wins), and attribute_conditions fields for fine-grained policy evaluation.
• New: Cedar policy engine (Team+ tier): POST/GET /v1/org/cedar-policies (CRUD), POST /v1/org/cedar-policies/test (dry-run evaluation). Declarative authorization via Cedar policy language.
• New: OPA policy engine (Business+ tier): POST/GET /v1/org/opa-policies (CRUD), POST /v1/org/opa-policies/test (dry-run evaluation). Rego-based policy evaluation with custom data documents.
• DB: Migration 179 (policy v2 columns: effect, priority, attribute_conditions + secret tags), migration 180 (cedar_policies and opa_policies tables).

Non-EVM Treasury Send

• Updated: POST /v1/treasury/wallets/{chain}/send now supports Bitcoin, Solana, XRP, Cardano, and Tron sends alongside EVM chains.
• Updated: Request body extended with token_mint, memo, destination_tag, fee_rate_sat_per_vbyte, xrpl_tx_json, fee_limit_sun, token_decimals, ttl for non-EVM chain-specific parameters.
• Note: POST /v1/treasury/wallets/{chain}/swap returns 400 for non-EVM chains (DEX aggregator is EVM-only).

Sub-Organizations

• New: Hierarchical organization management. Sub-orgs inherit or independently manage billing.
• New endpoints: POST/GET /v1/org/sub-orgs (create, list), GET/DELETE /v1/org/sub-orgs/{id} (get, archive), POST/DELETE /v1/org/sub-orgs/{id}/permissions (grant, revoke), POST /v1/org/sub-orgs/{id}/users (add user), POST /v1/org/sub-orgs/{id}/wallets/generate (generate wallets).
• Platform API: create_sub_org: bool on upsert_user enables platform apps to create sub-orgs for connected users.
• DB: Migration 181.

Portfolio

• New: GET /v1/portfolio — Unified balance aggregator across all wallet types (treasury wallets, signing keys, smart accounts). Query params: ?chains=ethereum,solana, ?include_tokens=true. Returns per-wallet balances with USD estimates.

Smart Account Import

• New: POST /v1/agents/{id}/smart-accounts/import — Import an existing Safe smart account. Accepts { chain, chain_id, safe_address, verify? }. Optionally verifies on-chain Safe ownership before import.

SDK / CLI / MCP

• SDK: client.signingKeys.importKey(), client.treasuryWallets.importWallet(), client.cedarPolicies.* (CRUD + test), client.opaPolicies.* (CRUD + test), client.subOrgs.* (full CRUD), client.portfolio.get(), client.agents.importSmartAccount(). Policy types updated with effect, priority, attribute_conditions.
• CLI: 1claw cedar-policy create|list|get|delete|test, 1claw opa-policy create|list|get|delete|test, 1claw sub-org create|list|get|archive|grant|revoke|add-user|wallets, 1claw portfolio, 1claw agent keys import, 1claw agent smart-account-import, 1claw treasury wallet import.
• MCP: import_signing_key, list_cedar_policies, test_cedar_policy, list_opa_policies, test_opa_policy, list_sub_orgs, create_sub_org, get_portfolio, import_smart_account tools.

Dashboard

• Updated: Policy create/list pages now show effect (allow/deny badge) and priority fields.
• Updated: Create policy form includes effect dropdown and priority input.

Clients

• @1claw/sdk@0.47.0, @1claw/cli@0.47.0, @1claw/mcp@0.47.0, @1claw/openapi-spec@0.47.0
• Python SDK oneclaw@0.47.0, Go SDK v0.47.0

---

v0.46.0 — Agent Delegation Framework (2026-08-12)

Agent-to-Agent Delegation

• New: Human-controlled agent-to-agent delegation framework. Agents cannot delegate to other agents without an explicit agent_delegations record created by a human.
• New: Three delegation modes: caller (delegate uses own credentials, default/most secure), target (delegate uses target agent's config), both (per-invocation choice).
• New: Security guardrails: tool allowlists/blocklists per delegation, daily rate limits (max_daily_delegations), recursive depth limits (max_depth 1–10 via X-Delegation-Depth header), expiration, self-delegation blocked (400).
• New: Chat enforcement — cross-agent POST /v1/agents/{id}/chat requires active, non-expired delegation from caller to target. Delegation engine validates tools, daily limits, and depth.
• New: agents.delegation_enabled BOOLEAN field — agents must have this enabled to participate in delegation.

Endpoints

• POST /v1/agents/{id}/delegations — Create delegation (human-only). Body: { delegate_id, delegation_mode, allowed_tools?, blocked_tools?, max_daily_delegations?, max_depth?, guardrails?, expires_at? }.
• GET /v1/agents/{id}/delegations — List delegations (human sees all; agent sees own).
• GET /v1/agents/{id}/delegations/effective — Agent-callable. Returns delegations where calling agent is the delegator (for runtime tool discovery).
• GET /v1/agents/{id}/delegations/{delegation_id} — Get delegation details.
• PATCH /v1/agents/{id}/delegations/{delegation_id} — Update delegation (human-only).
• DELETE /v1/agents/{id}/delegations/{delegation_id} — Revoke delegation (human-only).

Runtime Tools

• Updated: delegate_task tool now enforces delegation authorization — delegation-specific 403 errors returned for unauthorized cross-agent communication.
• Updated: list_my_sub_agents now includes delegation status per agent: { authorized, mode, allowed_tools, remaining_daily }.
• New: get_delegation_status tool — check which agents the caller is authorized to delegate to with tool/limit details.

SDK / CLI / MCP

• SDK: client.agents.createDelegation(), .listDelegations(), .getDelegation(), .updateDelegation(), .revokeDelegation(), .getEffectiveDelegations().
• MCP: list_delegations, create_delegation, get_effective_delegations tools.
• CLI: 1claw agent delegation create|list|get|update|revoke <agent-id>.

Dashboard

• New: Sub-agent creation wizard at /agents/sub-agent-wizard — 4-step flow with 6 role presets (Research, Image Gen, Treasury, Comms, Code, Custom). Configures capabilities, sets delegation rules with multi-parent support.
• New: Delegations tab on agent detail page — outbound (this agent delegates TO others) and inbound (others delegate TO this agent) tables with create, edit, revoke dialogs.
• New: Sub-Agents card on runtime detail page — "Create Sub-Agent" button, delegation status badges (green "Authorized" / gray "No Delegation"), "Authorize" quick-action.
• New: Sub-agent tag indicators on agents list page, "Create Sub-Agent" button.

Audit

• New audit events: agent.delegation.created, agent.delegation.updated, agent.delegation.revoked, agent.delegation.invoked, agent.delegation.blocked.

DB

• Migration 176: agent_delegations table with partial unique index on (delegator_id, delegate_id) WHERE is_active = true. RLS enabled.
• Migration 177: delegation_events table for daily rate limit tracking.
• agents.delegation_enabled BOOLEAN DEFAULT false.

Tests

• scripts/test-sub-agents-prod.sh (~55 assertions) — CRUD, enforcement, depth limits, rate limits, tool blocklists, revocation.
• scripts/test-delegation-security-prod.sh (~25 security assertions) — bidirectional isolation, expired delegations, self-delegation.

Clients

• @1claw/sdk@0.46.0, @1claw/cli@0.46.0, @1claw/mcp@0.46.0 updated with delegation types and methods.

---

v0.45.0 — Hermes-Native Channel Features, Sub-Agent Chat Fix, Image Gen Fallback (2026-08-12)

Added

• Hermes-Native Channel Features: Slash command router (12 commands), voice memo transcription (Telegram/Whisper), cross-platform conversation continuity via unified_conversation_id, automation→channel delivery, context-aware interruption, platform presence (is_home_platform, /sethome)
• Sub-Agent Chat Fix: Agents can now chat with any agent in the same organization (previously restricted to self-only)
• Shroud Image Gen Fallback: DALL-E image generation uses OPENAI_API_KEY env var fallback for non-chat endpoints
• Runtime API Keys UX: New dashboard component for configuring runtime API keys

Fixed

• LLM Billing Duplicate Fix: Subscription lookup now finds ALL non-cancelled subscriptions, preventing duplicate billing. Dashboard shows improved warning banner.

Changed

• DB migrations 174-175: New columns on agent_channels (slash_commands_enabled, voice_transcription_enabled, unified_conversation_id, auto_respond_in_progress, is_home_platform) and channel_messages (is_voice_message, voice_file_id, voice_duration_secs, transcription_status)
• New domain modules: slash_commands.rs, voice_transcription.rs, hermes_migration.rs

---

v0.46.0 — OAuth2 Refresh Tokens, Platform Marketplace, Security Hardening (2026-08-12)

OAuth2 Authorization Server

• New: Refresh token support — POST /v1/oauth/token returns refresh_token when offline_access scope is requested. Exchange via grant_type=refresh_token. DB: oauth_refresh_tokens table (migration 173).
• New: Token revocation — POST /v1/oauth/revoke revokes access or refresh tokens (RFC 7009).
• New: Consent revocation — DELETE /v1/oauth/consent/{app_slug} revokes all consent and tokens for an app (user-only).
• New: Scope-filtered UserInfo — GET /v1/oauth/userinfo now respects granted scopes (e.g. email scope required for email field).
• New: <SignInWith1Claw /> React component in @1claw/wallet-react for one-click OAuth integration.

Platform API

• New: max_connected_users field on platform apps — enforced limit on connected users per app.
• New: Platform marketplace — GET /v1/platform/marketplace lists approved apps with category, tags, screenshots. Dashboard at /marketplace.
• New: App stats — GET /v1/platform/apps/{id}/stats returns connected user count, bootstrap count, active connections.
• New: Platform webhook secret rotation — POST /v1/platform/apps/{id}/rotate-webhook-secret rotates the platform app delivery HMAC secret.
• New: 6 platform webhook events: platform.user.connected, platform.user.disconnected, platform.bootstrap.completed, platform.grant.created, platform.grant.revoked, platform.user.claimed.
• New: Platform rate limiting — per-app configurable max_requests_per_minute on platform API endpoints.
• New: Platform onboarding wizard — step-by-step flow at /platform/wizard for creating an app, template, and first user.
• Fixed: Multi-agent bootstrap — template specs with multiple agents now correctly provision all agents (was only creating the first).
• New: Delegation scopes for memory/chat — memory:read, memory:write, chat:read, chat:write added to platform delegation scope enforcement.

Runtime Chat

• Fixed: Anthropic tool deduplication — duplicate tool definitions no longer sent to Anthropic models.
• Improved: Graceful LLM fallback — runtime chat falls back to a simpler prompt when the model rejects the request.
• Improved: BYOK UX — LLM API key configuration now shows auto-suggested provider based on key prefix.

LLM Billing

• Fixed: Duplicate subscription detection — POST /v1/billing/llm-token-billing/subscribe detects and cleans up duplicate Stripe subscriptions. Dashboard shows warning banner when duplicates are detected.

wallet-react (v0.5.0)

• Fixed: 8 auth bugs: token refresh race, social login popup handling, cross-origin message validation, email OTP retry logic, passkey credential caching, session expiry redirect, PKCE state cleanup, consent page deep-link.
• New: Passwordless send via passkey — sendWithPasskey() method for transaction authorization without password.
• Improved: Social login popups — better popup handling for Google/Apple/Discord providers.
• New: CSS theming — theme prop accepts full CSS custom properties object for deep customization.
• New: Toast notifications — built-in toast system for transaction status updates.
• New: Skeleton loading — skeleton UI states for wallet and balance loading.

SDK (v0.46.0)

• New: auth.generatePKCE() — generates PKCE code verifier and challenge.
• New: auth.buildAuthorizeUrl() — builds OAuth authorize URL with PKCE parameters.
• New: auth.getUserInfo() — fetches UserInfo from OAuth access token.
• New: auth.revokeToken() — revokes an OAuth access or refresh token.
• New: auth.revokeConsent() — revokes OAuth consent for a specific app.
• New: platform.rotateWebhookSecret() — rotates webhook HMAC secret.
• New: platform.getAppStats() — fetches platform app statistics.
• New: platform.marketplace() — lists marketplace apps.

Security

• Fixed (TOCTOU): OAuth authorization code exchange uses atomic UPDATE ... RETURNING to prevent time-of-check-to-time-of-use race.
• Fixed (Chat authZ): POST /v1/agents/{id}/chat enforces org membership for users and same-org check for agent callers.
• Fixed (Discord replay): Discord OAuth state parameter is single-use (consumed on callback) to prevent replay attacks.
• Fixed (OAuth atomic): Authorization code creation and consent recording use a database transaction to prevent orphaned codes.
• Fixed (Channel allowlists): auto_respond_enabled must be true AND sender must be in sender_allowlist for auto-respond to trigger.

Dashboard

• Fixed: Template spec builder edit round-trip — editing an existing template now correctly loads the current spec.
• Improved: OAuth consent page UX — better error states, scope descriptions, app logo display.
• New: Grant page auth gate — /connect/{slug}/grant requires authentication (redirects to login).
• Improved: Mobile responsiveness — sidebar, tables, and cards responsive on mobile viewports.
• New: Marketplace page at /marketplace — browse approved platform apps.

Clients

• @1claw/sdk@0.46.0, @1claw/wallet-react@0.5.0, @1claw/mcp@0.46.0, @1claw/openapi-spec@0.46.0 updated.

---

2026-08

v0.45.0 — Runtime Tool Registry, Sub-Agent Framework (2026-08-11)

Runtime Tool Registry

• New: 12 tool modules in packages/runtime-base/templates/shared/tools/ provide runtime agents with structured capabilities:
  • image-gen.js — DALL-E image generation (requires shroud_enabled)
  • web-search.js — Web search via Brave/Tavily/SerpAPI
  • memory-tools.js — Agent memory CRUD (requires memory_enabled)
  • file-handler.js — Image analysis and URL reading
  • code-exec.js — Sandboxed code execution
  • google-tools.js — Google API integrations
  • github-tools.js — GitHub API tools
  • slack-tools.js — Slack messaging
  • social-tools.js — Social media tools
  • vault-tools.js — Direct vault secret access
  • notify-tools.js — Multi-channel notifications
  • sub-agents.js — Sub-agent framework (see below)
• New: Per-template tool configs — each runtime template (hermes, openclaw, openclaude) has a tools-config.js that enables/disables specific tools based on the template's use case.
• Dashboard: RuntimeToolsCard component on runtime detail page showing enabled/disabled tools per runtime.

Sub-Agent Framework

• New: 4 runtime-level tools for agent-to-agent collaboration:
  • discover_agents — Search the public agent directory for agents by capability
  • delegate_task — Send a task to another agent via chat and wait for response
  • list_my_sub_agents — List agents in the same org (org-scoped directory)
  • create_sub_task — Trigger automations on behalf of another agent
• Agent-to-agent communication uses POST /v1/agents/{id}/chat — agents can now call this endpoint on other agents within the same org.
• Dashboard: Sub-Agents tab on runtime detail page.

New Endpoints

• GET /v1/agents/org-directory — Authenticated org-scoped agent directory listing. Returns all agents in the caller's org with name, description, capabilities, and status. Used by the sub-agent list_my_sub_agents tool for agent discovery within an organization.

Shroud

• DALL-E bypass: Image generation requests routed through Shroud now bypass the Stripe AI Gateway. DALL-E has its own billing model and does not need metering through the gateway.

Dashboard

• RuntimeToolsCard component on runtime detail page — visual grid of enabled/disabled tools per runtime with tooltips showing requirements (e.g. "Requires shroud_enabled").
• Sub-Agents tab on runtime detail page — shows connected agents, delegation history, and task status.

Clients

• @1claw/sdk@0.45.0, @1claw/cli@0.45.0, @1claw/mcp@0.45.0, @1claw/openapi-spec@0.45.0 updated.

v0.44.0 — Security fixes, platform delegation enforcement, channels, chat (2026-08-11)

OAuth Connected Accounts

• New: Universal OAuth integration for AI agents — connect agents to external services (Google, GitHub, X/Twitter, LinkedIn, Slack, Discord, Notion, Microsoft, Salesforce, HubSpot) via human-approved OAuth flows.
• Provider registry seeded with 10 providers (migration 171). OAuth app credentials encrypted at rest (migration 172).
• Endpoints: GET /v1/oauth/providers, POST /v1/agents/{id}/oauth/connect, GET .../oauth/connections, POST .../oauth/disconnect/{bindingId}, credential CRUD.
• SDK OAuthConnectResource, MCP list_oauth_providers/list_oauth_connections, CLI 1claw oauth.
• Dashboard: ConnectedAccountsCard on agent detail page (Connections tab).

Security (C-1 Critical + 6 Medium + 8 Low)

• C-1 CRITICAL — Agent memory cross-org isolation (migration 166): Shared memory entries could collide across orgs due to missing org_id in the unique index. Fixed by adding org_id to the constraint.
• M-2 — Automation runs status CHECK (migration 167): Added awaiting_approval to the automation_runs status CHECK constraint.
• M-4 — Channel sender allowlist (migration 168): Added sender_allowlist and auto_respond_enabled columns to agent channels for restricting which sender IDs can trigger auto-respond.
• M-5 — Telegram dedup (migration 169): Track last_telegram_update_id per channel to prevent duplicate message processing.
• M-6 — Shared memory org validation: Cross-org shared memory access prevented.
• Low: Runtime chat rolling message cap, Cloud Run internal-only ingress, XFF bypass fix, agent token TTL reduced to 2h, step-up unlock prefix hardening, LLM billing gating improvements.

Platform API

• Delegation scope enforcement: delegation_scopes now enforced on 4 handler groups: secrets, policies, bindings, and discovery. Missing scope → 403.
• Disconnected connection rejection: Operations on disconnected platform connections rejected with 403.
• Bootstrap runtimes & automations: Template spec now supports runtimes and automations arrays. Bootstrap creates these resources and tracks IDs on the connection (runtime_ids, automation_ids — migration 170).
• Dashboard: Platform audit page, key rotation UI, connected apps grant management with expandable panels.

Agent Chat

• New: Chat conversations between humans and agents via Shroud LLM proxy. Persistent conversation history with SSE streaming.
• Endpoints: POST /v1/agents/{id}/chat, POST .../chat/unlock, GET .../chat/conversations, GET/DELETE .../chat/conversations/{id}.
• SDK client.chat.*, MCP send_chat_message, list_chat_conversations.

Messaging Channels

• New: Connect agents to Telegram, WhatsApp, and Discord for bi-directional messaging with auto-respond.
• Per-channel sender allowlists, WhatsApp HMAC verification, Telegram dedup.
• Image generation delivery (DALL-E images delivered inline on Telegram and dashboard chat).
• Endpoints: CRUD under /v1/agents/{id}/channels, webhook endpoints per platform.
• MCP create_channel, list_channels, send_channel_message.

Dashboard

• Fixed: Automations detail page crash.
• Improved: Assist NL mapping, automations wizard/assist UX, runtime chat code formatting.
• Template Spec Builder supports runtime and automation entries.

Clients

• @1claw/sdk, @1claw/cli, @1claw/mcp, @1claw/openapi-spec updated.

v0.43.4 — Automations v2: Workflow Engine, SDK ESM fix, Python SDK (2026-08-10)

Automations v2 — Workflow Engine

• New: 7 new step types — ai_generate (LLM text generation via Shroud), memory_get, memory_put, memory_search (agent memory CRUD), notify (webhook/slack/email notifications), approval_request (human-in-the-loop gate), condition (if/else branching with sub-steps).
• New: Template variable syntax — {{steps.<index_or_name>.<field>}} for referencing previous step outputs, {{webhook_payload.<path>}} for webhook trigger data. Applied recursively before step execution.
• New: Conditional execution — skip_if and run_if string expressions on any step (operators: ==, !=, contains, >, <, >=, <=, truthy).
• New: Cancel run endpoint — POST /v1/automations/{id}/runs/{run_id}/cancel (human-only; cancels running and awaiting_approval runs).
• New: Enriched list API — GET /v1/automations returns last_run_status, total_runs (30-day), success_rate (percentage), and agent_name.
• New: 10 marketing-ready presets — GET /v1/automations/presets (public): rotate-api-keys-weekly, daily-dca-buy, health-check-alert, database-sync, weekly-content-draft, lead-nurture-email, competitor-watch, sentiment-alert, campaign-report, monitor-balance.
• New: context JSONB column on automation_runs for step output persistence.
• DB: Migration 165 (workflow engine v2 — context column + index on automation_runs).

SDK 0.43.4 — ESM fix

• Fixed: ESM module resolution corrected for bundler-free environments (Node.js --conditions, Deno, Bun). Named exports now work correctly with import { createClient } from '@1claw/sdk'.

Runtime max_tokens fix

• Fixed: max_tokens parameter now correctly passed through to LLM providers in runtime chat and automation ai_generate steps.

Python SDK 0.43.4

• New: oneclaw Python SDK updated to 0.43.4 — automation support (client.automations.create/list/trigger), memory CRUD (client.memory.store/search/list), runtime management, and discovery.

Dashboard

• New: Automation create wizard includes preset gallery with one-click deployment.
• New: Enriched automation list shows last run status, success rate, and total runs.
• New: Cancel button on running automation detail page.
• New: Automations Assist page at /automations/assist with visual step editor.

Clients

• @1claw/sdk@0.43.4, @1claw/cli@0.43.4, @1claw/mcp@0.43.4, @1claw/openapi-spec@0.43.4, oneclaw (Python) 0.43.4.

v0.43.3 — Runtime Chat, Assist step editor, log security (2026-08-04)

Added

• Runtime Chat — POST /v1/runtimes/{id}/chat (SSE); Chat tab next to Shell for hermes/openclaw/openclaude; OpenAI-compatible in-container bridge.
• Automations Assist step editor — type-specific editable fields + selectors; Advanced JSON collapsed.
• Logs step-up unlock — POST /v1/runtimes/{id}/logs/unlock (password or passkey reauth, purpose runtime_logs, 15 min grant).

Security

• Runtime logs exclude/summarize GCP audit payloads and redact JWTs/API keys server-side.
• Agent JWTs mounted via Secret Manager secretKeyRef so CreateService audit logs do not embed plaintext tokens.
• When agent.shroud_enabled, runtimes enable sidecar/Shroud LLM path; automation swap/submit route signing through Shroud.

Clients

• @1claw/openapi-spec / @1claw/sdk / @1claw/cli 0.43.3; @1claw/agentkit 0.43.2; @1claw/plugin-elizaos 0.2.1.

v0.43.2 — Webhook automations, event triggers, runtime logs (2026-08-03)

Added

• Webhook automations — trigger_type: webhook returns one-time webhook_url + whk_ token on create. Public trigger: POST /v1/automations/{id}/webhook/{token}. Human-only rotation: POST /v1/automations/{id}/rotate-webhook-token.
• Event-trigger wiring — Automations with trigger_type: event and event_filter.event_type fire on secret.created/updated/rotated/deleted and policy.created/updated/deleted.
• Automations Assist — POST /v1/automations/assist/draft and /assist/session documented in OpenAPI; dashboard Assist flow + OpenClaude runtime template.
• Runtime logs API — GET /v1/runtimes/{id}/logs?tail=N returns { entries: [...] } (replaces legacy lines/since query params). SDK runtimes.logs(), MCP runtime_logs use tail.

Clients

• OpenAPI 2.31.0 / @1claw/openapi-spec@0.43.2, @1claw/sdk@0.43.2, @1claw/mcp@0.43.2.

v0.43.1 — Automations workflow_spec + runtime interactive shell (2026-08-03)

Fixed / clarified

• Automations create contract — POST /v1/automations requires workflow_spec (+ agent_id; cron_expr when trigger is cron). Dashboard maps legacy action_type UI fields onto workflow_spec. API accepts trigger_type: "schedule" as an alias for cron, and accepts workflow shapes as either a bare step array or { "steps": [...] }.
• Clients synced — OpenAPI 2.30.0 / @1claw/openapi-spec@0.43.1, @1claw/sdk@0.43.1 (runtimes.createShellSession), Go SDK (v0.43.0), Python SDK (oneclaw@0.43.3), CLI @1claw/cli@0.43.1, MCP @1claw/mcp@0.43.1 (io.github.1clawAI/1claw-mcp). Updated off the old /v1/agents/{id}/automations + action_type shapes. CLI README examples use --workflow / --cron.
• Runtime interactive shell — POST /v1/runtimes/{id}/shell/session (+ /shell/passkey/begin) documented in OpenAPI. Human-only step-up auth (password, TOTP, passkey, or reauth_token). Dashboard terminal uses binary PTY WebSocket; Vault auto-repairs Cloud Run invoker IAM (non-blocking on Connect to avoid gateway 504). Hermes/runtime images must include shroud-sidecar — rebuild templates after base updates; enabling shell while running triggers background reconcile / may still need stop/start.
• Manual automations — DB allows trigger_type: "manual"; create no longer 500s for manual workflows.
• Prod tests — scripts/test-automations-prod.sh exercises workflow_spec + schedule→cron alias; scripts/test-runtimes-prod.sh adds shell session auth/enablement guards.

v0.42.0 — Automations, Runtimes, Agent Memory, Discovery, and Platform enhancements (2026-08-01)

Added

• Agent Memory — Three-tier memory system (scratch, durable, semantic) for AI agents. Scratch is ephemeral and auto-cleared per session; durable persists across sessions; semantic enables vector similarity search via pgvector. All tiers encrypted at rest with envelope encryption. Endpoints: POST/GET/DELETE /v1/agents/{id}/memory, POST /v1/agents/{id}/memory/search. SDK client.memory.*, CLI 1claw memory, MCP tools memory_put/memory_get/memory_list/memory_search/delete_memory. Dashboard: Memory card on agent detail with tier tabs and search UI.
• Automations — Cron-scheduled, webhook-triggered, and event-driven automation workflows with multi-step pipelines and AI integration. Visual cron builder in the dashboard. Tier-gated: Free 2, Pro 10, Team 50, Business 200. Endpoints: POST/GET /v1/automations, GET/PATCH/DELETE /v1/automations/{id}, POST /v1/automations/{id}/trigger, GET /v1/automations/{id}/runs. SDK client.automations.*, CLI 1claw automation, MCP list_automations/trigger_automation. Dashboard pages at /automations, /automations/new, /automations/[id].
• Cloud Runtimes — Deploy AI agents in managed containers with resource presets: small (0.5 vCPU/512MB), medium (1 vCPU/1GB), large (2 vCPU/4GB), large-cc (4 vCPU/8GB confidential compute). Public URL hosting, idle auto-stop, log streaming, health monitoring. Endpoints: POST/GET /v1/runtimes, GET/PATCH/DELETE /v1/runtimes/{id}, start/stop/logs sub-routes. SDK client.runtimes.*, CLI 1claw runtime, MCP list_runtimes/manage_runtime/runtime_status/runtime_logs. Dashboard pages at /runtimes, /runtimes/new, /runtimes/[id].
• Agent Discovery — Public agent directory and platform marketplace. Agents can be made discoverable with capability cards showing A2A/MCP URLs, supported protocols, and pricing. Endpoints: GET /v1/agents/directory, GET /v1/agents/{agent_id}/card, POST /v1/agents/{agent_id}/discovery. SDK client.discovery.*, CLI 1claw directory, MCP search_directory. Dashboard: /directory public page, discovery card on agent detail.
• Platform Delegation — Platform apps can perform CRUD on connected user resources via X-Platform-Connection header. Scoped by delegation_enabled and delegation_scopes on platform apps. Operations attributed to the platform app in audit logs. DB: migration 151.
• OAuth2 Credential Bindings — Execution Intents bindings support OAuth2 credential type with authorization_code and client_credentials grant flows. Automatic token refresh before execution. DB: migration 150.
• New agent columns: llm_default_provider, llm_default_model (migration 143) for agent LLM defaults.
• New sidebar entries: Automations, Runtimes, and Directory pages added to dashboard sidebar navigation.
• DB migrations: 141 (automations), 142 (automation_runs), 143 (agent LLM defaults), 144 (runtimes), 145 (agent_memory_entries), 146 (agent_memory_vectors), 147 (runtime_hosting), 148 (agent_discovery), 149 (platform_listing), 150 (oauth2_credential_bindings), 151 (platform_delegation_scopes).

Changed

• Dashboard sidebar updated with new navigation items for Automations, Runtimes, and Directory.
• SDK types extended with memory, automation, runtime, and discovery interfaces.
• MCP server tool count increased from 50 to 62 tools.

---

2026-07

Payment Card Vault — human-in-the-loop approval (2026-07-17)

Card orders require human approval by default

• New: card_require_approval on agents (default true). When enabled, POST /v1/agents/{id}/cards/order returns 202 with status: awaiting_approval and approval_id — x402 payment runs only after a human approves.
• New: GET /v1/approvals/quick-decide — public one-click approve/deny from email (SHA-256 hashed, single-use tokens in approval_quick_tokens; 7-day TTL). Dashboard proxy: GET /api/approvals/quick-decide.
• New: Approval notifications — email with Approve/Deny CTAs; push notification dispatch to registered mobile devices.
• New: Auto-execution on POST /v1/approvals/{id}/decide when action == card_order (approved → pay + Laso; rejected → card.rejected webhook).
• New: Risk-tier step-up on approve (T2+ requires X-Auth-Confirm re-auth token; T3 passkey/TOTP).
• New: TOTP as re-auth method — POST /v1/auth/reauth/begin + complete with method: "totp".
• New: Webhook events approval.created, approval.decided, card.rejected.
• New: Card statuses awaiting_approval, rejected; approval_id on card responses.
• DB: migration 139 (card_require_approval, approval_quick_tokens, extended status CHECK).
• Clients: Dashboard approval detail card-order renderer, guardrails toggle, mobile card_order screen; SDK types updated.

Payment Card Vault — x402 card ordering (Laso) (2026-07-14)

Agents can order prepaid & gift cards, paid with USDC via x402, without ever seeing the PAN

• New: POST /v1/agents/{id}/cards/order — order a prepaid or gift card. Paid with an outbound x402 payment the Vault constructs and signs (EIP-3009 TransferWithAuthorization) using the agent's own Ethereum signing key on Base. Requires cards_enabled and an Idempotency-Key header. Available on all tiers (Free: $25/order, 5 cards/month; Pro: 50/month; Team: 200/month; Business+: unlimited). A 3% platform fee per order is debited from prepaid credits. Returns a masked card reference — never a PAN.
• New: Card lifecycle endpoints — GET /v1/cards, GET /v1/cards/{id} (masked to last4), POST /v1/cards/{id}/reveal (human X-Auth-Confirm re-auth, or per-card agent reveal policy; audit-logged), PATCH /v1/cards/{id} (reveal policy / void_after, human-only), POST /v1/cards/{id}/void (1Claw-level lock, forward-looking only), POST /v1/cards/{id}/refresh (rate-limited → clean 429 + Retry-After), POST /v1/cards/import (human-only, full encrypted storage with one-time-read CVV), POST /v1/cards/gift-cards/search.
• New: Ordering guardrails on agents — cards_enabled, card_max_order_usd, card_daily_limit_usd (enforced atomically over a rolling 24h window), card_payto_allowlist, card_reveal_enabled. These bound the purchase, not how a revealed card is later spent.
• New: Outbound x402 client (crypto/x402_client.rs) validates every 402 challenge before signing — payTo allowlist, Base network, exact requested amount, and the pinned Base USDC contract. The stored Laso bearer token is constrained in code to a hardcoded card-endpoint path allowlist (never /withdraw or /send-payment).
• New: card_monitor background worker (15s, advisory-lock leader election) — polls the issuer, fills last4/expiry/balance, stores gift-card redemption payloads as secrets, fires webhooks, auto-voids past void_after, and reconciles ordering-stuck rows as orphaned_payment.
• New: Webhook events card.ordered, card.ready, card.revealed, card.voided, card.depleted, card.orphaned_payment.
• Security: PCI-conscious reference mode (only the issuer card id + encrypted refresh token stored; PAN/CVV fetched just-in-time at reveal). Shroud's PII detector now Luhn-validates PANs and detects CVV/expiry patterns, blocking card data in LLM traffic; full-mode PANs are excluded from the admin secrets manifest.
• DB: migration 135 (extends secret_type with payment_card/gift_card), migration 136 (payment_cards table + agent guardrail columns).
• Clients: SDK client.cards.*, CLI 1claw card order|list|get|reveal|void|refresh|import, MCP order_card/order_gift_card/search_gift_cards/list_cards/get_card_status (reveal omitted from MCP), OpenAPI spec, and a Cards dashboard page + agent "Card Ordering Guardrails" card.

---

v0.41.2 — Overhead budget and transaction count limits (2026-07-13)

Anti-drain guardrails

• New: tx_max_per_day (INTEGER) on agents — daily transaction count cap (UTC calendar day). Prevents high-frequency drain attacks. Per-chain override via per_chain_guardrails.{chain}.max_per_day.
• New: tx_overhead_budget (JSONB) on agents — per-chain daily budget for non-value costs (rent, fees, energy) in native units. Prevents ATA rent drain (Solana), XRP reserve exhaustion, Tron energy drain, and fee storms. Format: {"solana": "0.5", "xrp": "100", "ethereum": "0.01"}.
• New: solana_ata_allowlist (TEXT[]) on agents — restricts which Solana wallet addresses may have Associated Token Accounts created. Prevents ATA rent drain attacks by limiting recipients.
• New: agent_overhead_ledger table (migration 127) — tracks per-chain overhead costs for budget enforcement.
• New: domain/overhead.rs — per-chain overhead cost estimation module covering EVM (gas), Solana (rent + priority fees), Bitcoin (fee rate), XRP (reserves), Cardano (min-ADA), and Tron (energy).
• New: Response fields tx_count_today and tx_overhead_today_by_chain in GET /v1/agents/{id} for dashboards and Shroud.
• New: per_chain_guardrails extended with max_per_day, overhead_budget, and max_ata_creates_per_day fields.
• Shroud: AgentTxGuardrails mirrors new fields; enforcement parity with Vault API.
• Dashboard: Transaction Guardrails card gains Max Transactions Per Day, Overhead Budget (JSON), and Solana ATA Allowlist fields. Summary badges for active limits.
• Clients: SDK (tx_max_per_day, tx_overhead_budget, solana_ata_allowlist, tx_count_today, tx_overhead_today_by_chain), CLI (--tx-max-per-day, --tx-overhead-budget, --solana-ata-allowlist), Python SDK, Go SDK, Mobile, and OpenAPI spec updated.

---

v0.41.1 — TEE enforcement toggles (2026-07-13)

Agent-level TEE enforcement (Pro+)

• New: intents_require_tee boolean on agents — when enabled, transaction sign/submit requests to api.1claw.co are rejected with 403. Agents must route through shroud.1claw.co where signing happens inside the hardware enclave.
• New: execution_require_tee boolean on agents — when enabled, execute requests to api.1claw.co are rejected AND all direct secret reads by the agent are blocked. Forces use of Execution Intents bindings through the TEE.
• New: X-1Claw-TEE-Origin HMAC verification module (vault/src/api/middleware/tee_origin.rs) — Shroud sets this header on proxied requests; Vault validates using shared ONECLAW_TEE_ORIGIN_SECRET.
• Changed: "Enable Intents API" toggle moved from the Overview tab to the Signing tab on agent detail page.
• Dashboard: Two new TEE enforcement toggles on the Signing tab with Pro+ tier badge, disabled states (dependent on base flags), and confirmation dialog warning about breaking changes.
• Migration 133: Adds intents_require_tee BOOLEAN DEFAULT false and execution_require_tee BOOLEAN DEFAULT false to agents table.
• JWT claims: intents_require_tee and execution_require_tee included in agent JWTs when true.
• Clients: SDK, CLI (--intents-require-tee, --execution-require-tee), Python SDK, Go SDK, and OpenAPI spec updated.

---

v0.41.0 — Live-pointer credential references for Execution Intents (2026-07-12)

Credential sources

• New: credential_source field on CreateBindingRequest and UpdateBindingRequest — a tagged union supporting two modes:
  • { type: "inline", value: {...} } — legacy behavior, credential copied into __agent-keys vault
  • { type: "vault_ref", vault_id: "...", path: "..." } — live pointer to an existing vault secret. The executor resolves the secret at execution time, so rotations in the source vault are reflected automatically without manual credential rotation.
• New: BindingResponse includes credential_source_type ("inline" | "vault_ref"), credential_vault_id, and credential_path so the UI can display how credentials are sourced.
• New: Dashboard binding form has a Manual / From Vault toggle — selecting "From Vault" lets users pick an existing vault secret; the binding references it directly (no duplication).
• New: Validation ensures the referenced vault belongs to the same org and the secret path exists.
• Migration 132: Adds credential_vault_id UUID (FK to vaults, ON DELETE SET NULL) and credential_path TEXT columns to agent_bindings.

Clients

• SDK: CredentialSource type exported; CreateBindingRequest and UpdateBindingRequest accept credential_source. Version bumped to @1claw/sdk@0.41.0.
• CLI: agent binding create --vault-ref <vault-id>:<path> flag. Version bumped to @1claw/cli@0.41.0.
• MCP: create_binding tool accepts credential_source parameter. Version bumped to @1claw/mcp@0.41.0.
• OpenAPI: CredentialSource schema added; binding request/response schemas updated. Version bumped to @1claw/openapi-spec@0.41.0.
• Python SDK: CredentialSource model, credential_source field on binding requests.
• Go SDK: CredentialSource struct, updated binding request/response types.

---

Execution Intents 2.0 — executor framework, real GraphQL, guardrail enforcement, credential lifecycle (2026-07-12)

Executor framework

• New: Trait-based executor framework (domain/execution/) with a shared ExecutionContext that centralizes SSRF validation, host/path allowlisting, credential loading, and timeout resolution — no executor can accidentally skip a guardrail. Replaces the previous single-file HTTP dispatch.
• New: Real GraphQL executor — POSTs { query, variables, operationName }, surfaces GraphQL errors[], and uses introspection for connectivity tests (previously GraphQL was an HTTP alias).

Guardrail enforcement

• New: Per-binding allowed_paths is now enforced at execute time (trailing-* wildcard supported); disallowed paths are recorded as denied.
• New: Agent-level execution_guardrails are enforced: allowed_hosts (strictest of binding + agent), allowed_binding_types (at execute, not just create), max_duration_ms (applied as the real client timeout), and max_requests_per_minute (per-agent rate limit).
• Changed: Connectivity test now runs through the same ExecutionContext as execute, so SSRF and host-allowlist checks apply to tests too.

Credential lifecycle & custody

• New: Explicit credential rotation endpoint — POST /v1/agents/{id}/bindings/{binding_id}/rotate-credential.
• New: credential_set boolean on binding responses reports whether a credential is stored, without ever exposing the value.
• Fixed: Binding delete now purges the stored credential (no orphaned secrets); secret_type unified to credential.

Execution surface & billing

• New: execution_surface on the execute response truthfully reports vault or tee (TEE only when a Shroud execution endpoint is configured); ONECLAW_EXECUTION_TEE_REQUIRE_SHROUD=true makes TEE requests 501 when no enclave endpoint is present, instead of silently running in Vault.
• Fixed: Only successful executions count toward the monthly execution quota; the TEE cost premium is charged as a delta over the base rate to avoid double-billing.

Clients & UI

• New: MCP tools create_binding, test_binding, list_executions, and generic execute_intent (joining execute_http and list_bindings).
• New: SDK client.bindings.rotateCredential(); OpenAPI updated with the rotate-credential path, credential_set, and execution_surface.
• New: Dashboard Execution Intents card rebuilt with tabs (Bindings / Execution Log / Playground), inline binding edit + is_active toggle, per-binding and per-agent guardrail editors, tier-aware type gating, and write-only credential UX.
• New: CLI @1claw/cli@0.40.1 — 1claw agent binding subcommands (create, list, get, update, delete, test, rotate-credential, execute, executions); --execution-intents and --execution-guardrails on agent create/update.
• New: Python SDK oneclaw@0.2.1 — bindings.rotate_credential(); Go SDK v0.40.1 — Bindings.RotateCredential() and credential_set on binding responses.
• New: Audit events for binding create/update/delete/rotate and every execution outcome (success / error / denied).

Vault 0.39.1 / Shroud 0.37.2 — dRPC managed RPC, Robinhood Chain, security hardening (2026-07-12)

dRPC Managed RPC Endpoints

• New: Automatic dRPC RPC fallback for 25 EVM chains when DRPC_API_KEY is configured. When a chain has no explicit rpc_url in the database, the Vault and Shroud dynamically construct a dRPC endpoint URL. Supported chains: Ethereum, Base, Optimism, Arbitrum, Polygon, Avalanche, BSC, zkSync Era, Linea, Scroll, Mantle, Blast, Gnosis, Fantom, Celo, Aurora, Metis, Moonbeam, Cronos, Sepolia, Holesky, Base Sepolia, Optimism Sepolia, Arbitrum Sepolia, Polygon Amoy.
• New: resolve_effective_rpc() shared helper in Vault consolidates RPC resolution: explicit DB URL → dRPC fallback → public testnet fallback.
• New: Shroud ChainRegistry expanded to 29 EVM chains with effective_rpc_url() method mirroring Vault's resolution logic.
• New: Numeric chain ID → dRPC reverse lookup via drpc_slug_for_chain_id() — enables dRPC support even when chains are referenced by numeric ID only.

Robinhood Chain Support

• New: Robinhood Chain (mainnet, chain ID 4663) and Robinhood Testnet (chain ID 46630) added to the chain registry.
• New: Native RPC endpoints configured: https://mainnet.robinhoodchain.com/rpc (mainnet) and https://testnet.robinhoodchain.com/rpc (testnet).
• New: Known tokens seeded: RBH (mainnet, 0xRBH...), USDC (mainnet), testRBH (testnet).
• New: resolve_chain_id() recognizes robinhood-chain, robinhood_chain, robinhood, robinhood-testnet, robinhood_testnet.
• New: signing_key_chain_for() maps robinhood-chain and robinhood-testnet to ethereum (secp256k1).
• New: Database migration 131_add_robinhood_chain.sql.

Security Hardening (July 11-12 Audit)

• Fixed (HIGH): Execution Intents cross-agent confused-deputy — all binding handlers (list_bindings, get_binding, execute, test_binding, list_execution_events) now enforce caller.id == agent_id ownership check. Previously, an agent with Execution Intents enabled could access another agent's bindings.
• Fixed (HIGH): X-Forwarded-For IP spoofing — changed from leftmost to rightmost XFF entry parsing for untrusted requests. GCP's Global Frontend appends the true client IP as the last entry; leftmost parsing was trusting attacker-controlled values.
• Fixed (MEDIUM): Platform-grant scope bypass — authorize_platform_grant enforced on delete_secret, get_secret_version, rotate_secret, and disable_version handlers. Previously, platform grants with allowed_paths restrictions were not checked on these operations.
• Fixed (MEDIUM): Execution events plaintext response bodies — response bodies are now truncated to 4KB, sensitive headers stripped, and sensitive patterns (API keys, tokens) redacted before persisting to execution_events. Field redactions_applied tracks sanitization.
• Fixed (LOW): SSRF trailing-dot bypass — validate_audience_url() and validate_redirect_uri() now strip trailing dots from hostnames before security checks (e.g., metadata.google.internal. no longer bypasses the blocklist).
• Fixed (LOW): Execution event caller misattribution — insert_execution_event now uses caller.id instead of agent_id from the URL for correct audit attribution.

Intents API Chain Parity

• Improved: resolve_chain_id() expanded from 10 to 30 chain names/aliases — all dRPC-supported networks are now resolvable by name in transaction requests.
• Improved: Shroud drpc_chain_slug() made case-insensitive for parity with Vault.
• Improved: Shroud seed_defaults() expanded to cover all 29 EVM chains with correct chain IDs, native currencies, and EIP-1559 support flags.

Infrastructure

• New: DRPC_API_KEY environment variable on Vault (Cloud Run) and Shroud (GKE). Configured via Terraform (infra/variables.tf), GitHub Actions secrets, and K8s secrets.
• New: scripts/test-drpc-connectivity.sh — verifies dRPC connectivity across 22 chains via eth_chainId calls.
• New: dRPC connectivity test integrated into run-production-tests.sh (auto-skipped when DRPC_API_KEY is not set).

---

API v2.26.0 / SDK 0.40.0 / Vault 0.39.0 / MCP 0.40.0 — Execution Intents (2026-07-10)

Execution Intents (Pro+)

• New: Execution Intents API — agents can make HTTP calls, database queries, and external service interactions through pre-configured bindings. Credentials are stored server-side in the __agent-keys vault and never exposed to agents.
• New: Binding types: HTTP, GraphQL (Pro tier), plus Postgres, MySQL, Redis, gRPC, SMTP, Cloud SDK, S3, Custom (Team+ tier). TEE execution mode available on Business+ for enhanced security.
• New: Per-binding guardrails: host allowlists, timeouts, authentication types (bearer, basic, header, query).
• New: Full execution audit trail via execution_events table with per-event cost tracking.
• New: CRUD endpoints under /v1/agents/{id}/bindings (human-only creation). Execute endpoint: POST /v1/agents/{id}/execute. Test endpoint: POST /v1/agents/{id}/bindings/{binding_id}/test.
• New: Agent field execution_intents_enabled (boolean, default false). JWT claim execution_intents_enabled gates access; middleware require_execution_intents enforces it.
• New: execution_guardrails JSONB on agents — per-agent execution guardrails (allowed hosts, max duration, rate limits).
• New: Tier-based billing: execution_intent (2¢ Pro → 0.5¢ Business) and execution_intent_tee (10¢ Pro → 2.5¢ Business) per execution. Monthly limits: Pro 1K, Team 10K, Business 50K, Enterprise unlimited.

SDK/CLI/MCP/Dashboard

• SDK: client.bindings.create(), .list(), .get(), .update(), .delete(), .test(), .execute(), .listExecutions().
• MCP: New execute_http and list_bindings tools.
• CLI: Execution intents support via SDK integration.
• Dashboard: ExecutionIntentsCard on agent detail page — toggle, binding list, create/test/delete.

Migrations

• 129_execution_intents.sql — agent_bindings and execution_events tables.

Version Bumps

• Vault API: 0.39.0
• SDK: 0.40.0
• MCP: 0.40.0
• CLI: 0.40.0
• OpenAPI: 0.40.0

---

API v2.25.0 / SDK 0.38.0 / Vault 0.38.0 / MCP 0.38.0 — Token guardrails, known tokens registry, per-chain guardrails (2026-07-05)

Added

• Token allowlist guardrail (tx_token_allowlist): Controls which token contracts/mints an agent can interact with. Applied to token_mint on non-EVM chains and ERC-20 contract addresses on EVM chains. Checked case-insensitively.
• Known tokens only (tx_known_tokens_only): When enabled, restricts agents to verified tokens in the known tokens registry. Unknown token contracts/mints are rejected with 403.
• XRP transaction type allowlist (xrpl_allowed_tx_types): Controls which XRPL transaction types are allowed when using xrpl_tx_json. Empty = all supported types. Unsupported types return 403.
• Per-chain guardrails (per_chain_guardrails): Chain-specific overrides for max_value, daily_limit, to_allowlist, and token_allowlist. Strictest of global and per-chain values wins.
• Per-chain daily spend tracking (tx_spent_today_by_chain): GET /v1/agents/{id} now returns per-chain daily spend in native units with correct decimals (e.g. { "ethereum": "0.5", "solana": "2.0" }). The canonical field is tx_spent_today / tx_spent_today_by_chain; the deprecated tx_spent_today_eth alias is still returned for backward compatibility.
• Known tokens registry: Public endpoints GET /v1/tokens (filterable by ?chain=) and GET /v1/chains/{chain}/tokens for listing verified tokens. Admin endpoints POST /v1/admin/tokens and DELETE /v1/admin/tokens/{id} for registry management.
• ERC-20 server-side builder: When token_mint is provided on EVM chains, the handler generates ERC-20 transfer(to, amount) calldata server-side — agents no longer need to construct calldata manually.
• Extended token balance: GET /v1/agents/{id}/signing-keys/{chain}/balance now accepts optional ?tokens= query param (comma-separated contract addresses/mints) to include specific ERC-20/SPL/TRC-20 token balances alongside native balance.
• Solana ATA auto-creation: SPL token transfers automatically create the recipient's Associated Token Account if it doesn't exist, adding a CreateAssociatedTokenAccount instruction before the transfer.
• Cardano native asset transfers: Multi-asset output support with min-ADA enforcement. token_mint is policy_id.asset_name hex.
• Memo support: Solana (Memo Program v2 instruction appended), XRP (Memos array in xrpl_tx_json), Tron (extra_data field).
• UTXO locking: Concurrent Bitcoin and Cardano transactions are serialized via the utxo_locks table to prevent double-spending the same UTXO. Locks auto-expire after 5 minutes.

Fixed

• Daily spend unit mismatch: Per-chain daily spend now uses correct native-unit decimals instead of ETH-equivalent conversion, which could under-count spend on high-decimal chains.
• XRP guardrail bypass: xrpl_tx_json transactions now enforce all agent guardrails (chains, allowlist, value caps, daily limits) — previously bypassed when using raw XRPL JSON.
• /sign EVM persistence: Transactions submitted via the unified POST /v1/agents/{id}/sign endpoint with intent_type: "transaction" are now correctly persisted for audit and daily-limit tracking.

Migrations

• 124_agent_token_guardrails.sql — tx_token_allowlist, tx_known_tokens_only, xrpl_allowed_tx_types, per_chain_guardrails columns on agents table.
• 125_known_tokens.sql — known_tokens table with unique index on (chain, contract_address).
• 126_utxo_locks.sql — utxo_locks table for concurrent UTXO transaction serialization.

SDK/CLI/Dashboard

• SDK: CreateAgentRequest, UpdateAgentRequest, and AgentResponse include all new guardrail fields. Token registry types added.
• CLI: New flags --tx-token-allowlist, --tx-known-tokens-only, --xrpl-allowed-tx-types, --per-chain-guardrails on agent create and agent update.
• Dashboard: Token allowlist editor, known-tokens-only toggle, per-chain guardrails visual editor, and XRPL transaction type multi-select on agent detail page. Token registry hook (use-token-registry.ts).

---

Vault 0.37.1 / Shroud 0.37.1 — Official Rust SDKs for Bitcoin & Solana signing (2026-07-04)

• Improved: Bitcoin transaction signing now uses the official rust-bitcoin crate (v0.32) instead of hand-rolled secp256k1 + BIP-143 logic. All recipient address types are supported: P2PKH, P2SH, P2WPKH, P2WSH, and P2TR (Taproot). Key generation, address derivation, and UTXO-based transaction construction use rust-bitcoin types end-to-end, eliminating custom serialization code.
• Improved: Solana transaction signing now uses the official solana-sdk crate (v4) instead of manual Ed25519 + compact message serialization. PDA derivation uses Pubkey::find_program_address (replacing the custom off-curve check with curve25519-dalek). SPL token transfers use proper Associated Token Account derivation. Key generation, address formatting, and transaction construction are fully type-safe.
• Improved: Shroud TEE signing mirrors all changes — both vault and shroud now use identical SDK-backed implementations for Bitcoin and Solana.
• Tests: Comprehensive unit tests added for both chains in both vault and shroud: key generation determinism, address derivation across networks (mainnet/testnet/signet), signing to all recipient address types, multi-UTXO inputs, dust change handling, invalid address rejection, SPL token transfers, shortvec encoding, and blockhash variation.
• Verified end-to-end: Live testnet transactions confirmed on all non-EVM chains — Solana Devnet (sign-only, submit/broadcast, unified sign), Bitcoin Signet (sign-only, submit/broadcast), Tron Shasta (sign-only, submit/broadcast), and Cardano Preprod (sign-only, submit/broadcast).
• Docs: Intents API guide updated with comprehensive testnet reference table including faucet links, external API dependencies, and network-specific address format notes for all 5 non-EVM chains.

API v2.24.0 / SDK 0.37.0 / Vault 0.37.0 / MCP 0.37.0 — Broad XRPL coverage (2026-07-03)

• New: 30+ XRPL transaction types via the xrpl_tx_json field on SubmitTransactionRequest, SignTransactionRequest, and SignIntentRequest. Pass a raw XRPL transaction JSON object and the server uses the xrpl-rust binary codec to encode and sign it. Account, Sequence, Fee, LastLedgerSequence, and SigningPubKey are auto-filled when absent. Supported types: Payment, TrustSet, OfferCreate, OfferCancel, AccountSet, AccountDelete, EscrowCreate/Finish/Cancel, PaymentChannelCreate/Fund/Claim, NFTokenMint/Burn/CreateOffer/AcceptOffer/CancelOffer, AMMCreate/Deposit/Withdraw/Bid/Delete/Vote, SetRegularKey, SignerListSet, DepositPreauth, CheckCreate/Cash/Cancel, TicketCreate, Clawback.
• New: xrpl-rust v1.1.0 crate added to both Vault and Shroud (TEE), replacing the hand-rolled Payment-only STObject serializer. The legacy to/value/destination_tag Payment path is preserved for backward compatibility.
• New: Unsupported XRPL transaction types are rejected with a descriptive error listing all supported types.
• SDK: xrpl_tx_json field added to SubmitTransactionRequest, SignTransactionRequest, and SignIntentRequest in the TypeScript SDK, Python SDK, and Go SDK.
• MCP: submit_transaction and sign_transaction tools accept xrpl_tx_json parameter.
• OpenAPI: xrpl_tx_json field added to all three transaction request schemas.
• Tests: test-nonevm-signing-prod.sh extended with TrustSet, AccountSet, unsupported type, and unified /sign OfferCreate tests. test-shroud-prod.sh gains XRP xrpl_tx_json TrustSet dispatch test and XRP Payment dispatch test.
• Dashboard: Intents page updated to highlight XRP's 30+ transaction type support.
• Examples: examples/non-evm-keys updated with TrustSet example via xrpl_tx_json.

API v2.23.0 / SDK 0.36.0 / Vault 0.36.0 / MCP 0.36.0 — Non-EVM transaction signing (2026-07-03)

• New: Full on-chain transaction signing + broadcast for Bitcoin, Solana, XRP, Cardano, and Tron through the Intents API (POST /v1/agents/{id}/transactions, POST .../transactions/sign, unified POST .../sign with intent_type: "transaction"). 1Claw dispatches by chain family, auto-fetches chain data (Bitcoin UTXOs/fee via mempool.space, Solana blockhash, XRP sequence, Cardano protocol params via Blockfrost, Tron ref block via TronGrid), signs in the HSM (or Shroud TEE), and broadcasts.
• New: Chain-specific optional fields on transaction requests: destination_tag (XRP), memo, fee_rate_sat_per_vbyte (Bitcoin), fee_limit_sun (Tron TRC-20), token_mint / token_decimals (Solana SPL + Tron TRC-20), ttl (Cardano). value is the human-readable major unit (BTC/SOL/XRP/ADA/TRX) as a decimal string.
• New: Chain registry migration adds chain_type column and seeds non-EVM mainnets + testnets (bitcoin-testnet, solana-devnet, xrp-testnet, cardano-preprod, tron-shasta, etc.).
• New: Shroud TEE parity — non-EVM signing inside confidential memory with the same family dispatch and guardrails as Vault API.
• Note: Tenderly simulate_first and /simulate endpoints remain EVM-only (no-op for non-EVM chains).
• Cardano: Requires server-side Blockfrost project id (BLOCKFROST_PROJECT_ID_PREPROD, BLOCKFROST_PROJECT_ID_MAINNET, or generic BLOCKFROST_PROJECT_ID).
• Examples: examples/non-evm-keys now includes npm run sign -- <chain> <to> <amount> for sign + broadcast demos.
• Tests: New scripts/test-nonevm-signing-prod.sh wired into run-production-tests.sh; Shroud prod tests assert non-EVM dispatch.
• SDK: SubmitTransactionRequest / SignTransactionRequest extended with non-EVM fields; OpenAPI spec updated.

API v2.22.0 / SDK 0.35.0 / Vault 0.35.0 — Platform resource grants (2026-07-03)

• New: Platform resource grants — users can grant platform apps access to specific vaults and agents via POST /v1/platform/connections/{id}/grant. Grants are per-vault with configurable allowed_paths and permissions. List active grants via GET .../grants, revoke individual grants via DELETE .../grants/{grant_id}.
• New: Dashboard grant page at /connect/{slug}/grant — vault/agent picker with checkboxes for selecting resources to share with a platform app. Linked from OAuth consent and claim flows.
• Enhanced: Connected Apps page (/settings/connected-apps) rewritten — now shows vault/agent counts per app, expandable "Resource Grants" panel with per-grant details, and individual revoke buttons with confirmation dialog.
• Fixed: GET /v1/platform/connected-apps response key changed from connected_apps to apps to match the SDK and dashboard expectations.
• SDK: New methods on PlatformResource: grantAccess(connectionId, data), listGrants(connectionId), revokeGrant(connectionId, grantId).

2026-06

API v2.20.1 / SDK 0.34.3 / CLI 0.36.4 — OAuth branding + redirect URI validation (2026-06-29)

• New: Platform apps can configure a logo_url for branding on OAuth login and consent pages. When a user visits the "Sign in with 1Claw" flow, the app's logo and name are shown. Set via Dashboard (Platform → app → Settings → App Branding) or PATCH /v1/platform/apps/{id}.
• New: Public branding endpoint GET /v1/platform/apps/by-slug/{slug}/branding — returns { name, logo_url, slug } without authentication.
• New: Dedicated validate_redirect_uri() function for OAuth redirect URIs allows http://localhost and http://127.0.0.1 per RFC 8252 §7.3 (native/dev clients). Cloud metadata and non-loopback private IPs remain blocked.
• Dashboard: Platform app detail page has a "Redirect URIs" editor in the Settings tab. Login and consent pages show app branding (logo + name) when the OAuth client_id query parameter is present.
• Docs: Updated Platform API guide with redirect URI management instructions and a warning that client_id must be the app slug (not UUID).

API v2.20.0 / SDK 0.34.2 / MCP 0.34.3 — raw digest signing + EIP-712 fixes (2026-06-26)

• New: Raw digest signing intent on POST /v1/agents/{id}/sign — intent_type: "eip712_digest" (alias "digest") signs a client-computed 32-byte hash directly and returns a 65-byte r‖s‖v signature that recovers to the agent's EOA. This unblocks ERC-1271 / ERC-7739 nested EIP-712 flows (e.g. Polymarket CLOB orders) where the canonical hash is computed client-side and must match the verifier exactly, which 1Claw's own typed_data recomputation would otherwise diverge from.
• Security: Raw digest signing is blind signing (no domain/transaction inspection, guardrails bypassed), so it is gated behind a new per-agent raw_signing_enabled flag — off by default, only a human can enable it (agents cannot self-enable), and every use is audit-logged as signing_key.raw_digest_sign. Surfaced as a toggle (with an explicit warning) on the dashboard agent detail page.
• Fixed: EIP-712 uintN/intN encoding for typed_data now uses arbitrary-precision integers — decimal strings that happened to be valid hex are no longer misparsed, and values larger than u128 are no longer silently encoded as zero. Negative intN values use correct two's-complement.
• New: Platform bootstrap templates accept provision_eoa: true per agent — generates a standalone secp256k1 EOA for the agent (returned as agent_evm_address in the bootstrap summary) so platform-provisioned agents can deploy/operate ERC-4337 smart accounts client-side without a Pro+ treasury-wallet flow.
• MCP: New sign_digest tool wraps the eip712_digest intent. SDK: signIntent accepts intent_type: "eip712_digest" + hash; AgentResponse/UpdateAgentRequest expose raw_signing_enabled.

CLI v0.36.2 — fix cloud-mode container startup + start/restart for init --docker (2026-06-25)

• Fixed: 1claw init --docker (cloud mode) started the container but the entrypoint exited immediately with ERROR: ONECLAW_AGENT_API_KEY is not set (cloud mode) and looped on restart. The container is designed never to receive the agent API key — the host daemon brokers credentials over the mounted Unix socket — so requiring the key directly was wrong for this flow. The entrypoint now detects the mounted daemon socket and brokers all credentials through it (cloud and local). A direct ONECLAW_AGENT_API_KEY is only required for standalone deploys with no daemon socket (e.g. Cloud Run via 1claw deploy).
• New: 1claw containers start <name> and 1claw containers restart <name>. start resumes a stopped container; if the container was removed (status absent), it is recreated from the saved run spec (re-checking the host port). restart restarts a running/stopped container or recreates an absent one. The init command now persists the container's run spec (image, env var names, mounts, labels — never secret values) to ~/.config/1claw/containers/{name}.json to enable this.
• Changed: The chat UI header no longer shows the ambiguous mode=cloud. It now shows runtime=docker (the container is always Docker) alongside vault=cloud|local — clarifying that "cloud/local" refers to where the agent's identity and secrets live (a 1Claw cloud account vs an offline local CLI vault), not the runtime. /info reflects the same.
• Changed: Base image org.1claw.base-version bumped so an existing 1claw/agent:stable is rebuilt with the corrected entrypoint and clarified labels automatically on the next init.

CLI v0.36.1 — robust port handling for init --docker (2026-06-25)

• Fixed: 1claw init --docker could fail with Bind for 0.0.0.0:3000 failed: port is already allocated even though the CLI's pre-check thought the port was free. The free-port check now binds 0.0.0.0 (matching how Docker publishes ports) instead of 127.0.0.1, so ports already held by another container are correctly detected.
• New: If the container still fails to start because the port is taken (a TOCTOU race, or a port held only inside the Docker VM), the CLI now automatically retries on the next free port — unless you pinned an explicit --port, in which case it fails with actionable guidance (1claw containers list, 1claw containers stop <name>, docker ps --filter publish=<port>).
• Reminder: manage running agent containers with 1claw containers list | info | stop | rm | logs; manage cloud agent identities with 1claw agent list | get | update | delete.

CLI v0.36.0 — chat LLM through Shroud (2026-06-25)

• New: In cloud mode, the 1claw init --docker chat UI is now wired to an LLM through Shroud. Messages route via the host daemon, which injects the X-Shroud-Agent-Key header (the container never sees the agent key); Shroud applies the agent's inspection/redaction policy before forwarding to the provider.
• New: Three provider-key sources, all keeping the key out of the container: 1Claw LLM Token Billing (Stripe AI Gateway — no key), 1Claw cloud vault (--llm-api-key, default --llm-key-store cloud, stored at providers/<provider>/api-key and auto-fetched by Shroud), and local CLI vault BYOK (--llm-api-key --llm-key-store local or --llm-api-key-secret <name> — the daemon injects X-Shroud-Api-Key). The provisioned agent now also gets a read policy on providers/* so cloud-vault keys resolve.
• New: --llm-provider (default openai), --llm-model (default per provider, e.g. gpt-4o-mini), --llm-api-key, --llm-key-store, and --llm-api-key-secret flags on init --docker. The daemon /proxy now supports injecting multiple secrets into one request.
• Fixed: The container chat UI reported mode=local even for cloud-provisioned agents — ONECLAW_LOCAL_VAULT=true was baked into the base image. Mode is now passed at run time; cloud agents correctly report mode=cloud. --local mode still has no LLM (no cloud agent → no Shroud credential).
• Changed: The base image carries an org.1claw.base-version label; init rebuilds a stale 1claw/agent:stable automatically when bundled assets change. CLI version 0.35.1 → 0.36.0.

CLI v0.35.1 — local vault recovery (2026-06-25)

• New: 1claw local destroy --force skips the confirmation prompt, and 1claw local reset is an alias for destroy. Neither requires the passphrase — this is the recovery path for a forgotten local-vault passphrase. Destroy now also stops any running daemon still holding the old vault and clears its stale socket/PID.
• Improved: 1claw init --docker --local validates an existing vault's passphrase before starting the daemon and, on mismatch, fails fast with explicit recovery instructions instead of a generic daemon-startup timeout. 1claw daemon start surfaces the same recovery guidance on "wrong passphrase or corrupted vault file".

CLI v0.35.0 — containerized agent runtime (2026-06-25)

• New: 1claw init --docker — provisions a secure agent runtime inside a Docker container in one command (1Claw MCP server + chat UI on port 3000). The container never receives the agent API key; the host daemon injects credentials over a read-only Unix-socket bind mount.
• New: Module system — --module=ampersend,onchain composes container extensions from bundled module.yaml manifests with dependency resolution, conflict detection, and topological layer ordering. Bundled modules: ampersend, onchain, langchain, elizaos, scaffold-agent. --list-modules prints the catalog.
• New: --local flag runs fully offline (no cloud account); the base image is built from bundled assets when not already present.
• New: 1claw containers list|info|stop|rm|logs — manage CLI-created agent containers (state stored in ~/.config/1claw/containers/{name}.json).
• New: 1claw publish — rebuild from base + modules, build from a custom Dockerfile, or snapshot a running container (--commit), then tag and push to a registry.
• New: 1claw eject — export the generated Dockerfile, module configs, and a docker-compose.yaml (daemon socket pre-wired) for manual control.
• New: 1claw deploy --google-cloud — generate Terraform (main.tf, variables.tf, outputs.tf) for Cloud Run with Secret Manager key injection; --apply runs terraform apply.
• Changed: CLI version bumped from 0.34.7 to 0.35.0. Added yaml dependency for module manifest parsing.

CLI v0.34.7 — LLM proxy, treasury proposals, unified signing (2026-06-22)

• New: 1claw proxy — local OpenAI-compatible proxy that routes LLM traffic through Shroud with full inspection, secret redaction, and optional LLM Token Billing. Auto-detects provider from model name. IDE setup snippets printed on startup.
• New: 1claw treasury proposal create|list|get|sign|execute|cancel — full multisig proposal lifecycle from CLI.
• New: 1claw agent sign — unified signing command for EIP-191, EIP-712, and all EIP-2718 transaction types (0–4).
• New: 1claw webhook create|list|get|update|delete — manage webhook endpoints from CLI.
• New: 1claw platform reissue-claim — reissue expired claim URLs without re-provisioning.
• New: 1claw treasury send and 1claw treasury swap — send native/ERC-20 tokens and swap via 0x from CLI.
• New: 1claw treasury balance — query native + ERC-20 token balances.
• New: DPoP support — ONECLAW_DPOP=true env var enables RFC 9449 proof-of-possession. Keypair persisted at ~/.config/1claw/dpop-key.json.
• Updated: MCP tools expanded to 37 tools (added platform_reissue_claim, platform_rotate_key, list_approvals, get_approval, request_approval, treasury_propose, treasury_sign_proposal, treasury_list_proposals, sign_digest).
• Updated: MCP auth simplified — ONECLAW_AGENT_API_KEY alone is sufficient (agent ID and vault auto-discovered via prefix lookup).
• Changed: CLI version bumped from 0.34.2 to 0.34.7. SDK 0.34.1. MCP 0.34.1.

Local Vault & Daemon (v0.34.2 — 2026-06-22)

Local encrypted vault:

• 1claw local init — create an AES-256-GCM encrypted vault with passphrase-derived key (PBKDF2, 100k iterations)
• 1claw local add/get/rm/list/status/destroy — full secret lifecycle without cloud connectivity
• 1claw local import <file> — import from .env files into the local vault
• 1claw local export — export as .env format
• 1claw local sync — push local secrets to cloud vault; --pull to pull from cloud
• File permissions hardened to 0600; safe to back up (encrypted at rest)

Local daemon & secret proxy:

• 1claw daemon start — starts a Unix socket daemon that holds decrypted secrets in memory
• 1claw daemon policy add <secret> --hosts <hosts> — per-secret host allowlist (fail-closed: no policy = no injection)
• 1claw daemon policy list/remove — manage policies
• Secret proxy: POST /proxy on the daemon socket injects secrets into HTTP requests per policy rules — the AI model never sees the raw secret value
• 1claw daemon status/stop — lifecycle management

MCP local mode:

• 1claw setup --local — configures AI clients to use the daemon instead of the cloud API
• MCP server (ONECLAW_LOCAL_VAULT=true) connects to daemon over Unix socket
• proxy_request MCP tool: AI model specifies secret name + URL, daemon injects credential per policy
• list_secrets tool shows secret names (never values) from the local vault

CLI DX & Homebrew (v0.34.1 — 2026-06-22)

New CLI commands:

• 1claw setup — auto-detect and configure AI clients (Claude Desktop, Cursor, VS Code, Zed, Windsurf, Claude Code) to use the 1Claw MCP server for runtime secret access
• 1claw import <file> — parse .env files and import secrets into a vault (supports --prefix, --dry-run, --force)
• env cache / env cache-clear / env cache-status — encrypted local secret cache for offline env run (AES-256-GCM, ~/.config/1claw/env-cache.enc)
• env run --no-cache — bypass local cache and always fetch from API

Homebrew tap:

• brew install 1clawAI/tap/oneclaw — install CLI via Homebrew
• brew install 1clawAI/tap/1claw-mcp — install MCP server via Homebrew
• Automated formula updates on npm publish via repository_dispatch

Version alignment:

• CLI bumped to 0.34.7 (latest)
• SDK at 0.34.1
• MCP at 0.34.1
• OpenAPI spec info.version bumped to 2.19.0

---

Security Hardening (v0.34.1 — 2026-06-21)

Fixed

• H-1/H-2 (HIGH): create_share now enforces vault-binding, scope access, and policy-engine read permission checks before sharing. Cross-org share recipients are validated to prevent cross-tenant secret egress.
• H-3 (HIGH): Treasury wallet swap path now enforces full spend policy (per-tx cap, daily limits, denylist, 10,000-ETH sanity cap) and records swaps to the daily send ledger.
• H1-R (HIGH): CAE (Continuous Access Evaluation) now properly revokes agent tokens on critical risk verdicts via revoke_all_for_agent, ensuring stolen agent JWTs are actually rejected by auth middleware.
• L-4: Single delete_agent endpoint now enforces platform_locked guard (parity with batch-delete).
• L-5: Batch-delete hardening — sanitized error messages (no raw DB errors), collapsed not-found/access-denied responses to prevent cross-tenant existence oracle.
• L-1/L-2: Nightly cleanup job now sweeps expired revoked_tokens, agent_active_tokens, and dpop_nonces tables to prevent unbounded growth.

---

Risk Engine + DPoP Token Binding (v0.34.0 — 2026-06-11)

Added

• Risk Engine Phase 1: Geo-velocity (impossible travel detection), first-seen ASN/country drift, honeytoken canary secrets
• Risk Engine Phase 2: DPoP token binding (RFC 9449), Continuous Access Evaluation (auto-revoke on critical)
• Dashboard: /security page with risk events feed and severity filtering
• Dashboard: /security/honeytokens page for canary secret management
• Dashboard: DPoP enforcement toggle in Security settings (off/warn/required)
• SDK: client.risk resource for risk events, verdicts, and honeytokens
• SDK/MCP/CLI: DPoPManager for proof-of-possession token binding
• API: GET/POST/DELETE /v1/risk/honeytokens, GET /v1/risk/events, GET /v1/risk/verdicts
• MaxMind GeoLite2 IP enrichment (City + ASN) for risk scoring
• Auth verdict gate: blocks login/token-exchange on high/critical risk score
• Honeytoken detection: silent critical verdict on canary secret read

Security

• Stolen JWTs are now non-replayable when DPoP is enabled (bound to client keypair)
• Critical risk verdicts immediately revoke all active sessions for the principal
• Impossible travel detection catches session replay from different geography
• ASN/country baseline drift flags credential stuffing from unfamiliar sources

Migrations

• 118_risk_engine_phase1.sql — risk_events, risk_verdicts, principal_baselines, honeytokens
• 119_dpop_and_cae.sql — jwt_bound_keys, dpop_nonces

---

Embedded Wallets: Email OTP, OAuth2, Spend Policies (v0.33.0)

• New: Email OTP login — Passwordless authentication for embedded wallet end-users via 6-digit email codes. POST /v1/auth/email-otp/send (rate-limited, 5-min expiry) and POST /v1/auth/email-otp/verify (returns JWT + auto-provisions treasury wallets on first login). Migration 113.
• New: Sign in with 1Claw — Full OAuth2 authorization code flow with PKCE; 1Claw acts as an OIDC provider for third-party apps. Endpoints: POST /v1/oauth/authorize (code grant), POST /v1/oauth/token (code exchange), GET /v1/oauth/userinfo. Dashboard consent page at /oauth/authorize. OIDC discovery updated to advertise authorization_endpoint, userinfo_endpoint, and PKCE (S256). Platform apps configure redirect_uris for OAuth client registration. Migration 114.
• New: Wallet spend policies — Per-app default and per-user override policies for treasury wallet sends and swaps. Controls: recipient to_allowlist, max_value_eth per-tx cap, daily_limit_eth, allowed_chains. Endpoints: POST/GET/PATCH/DELETE /v1/platform/apps/{app_id}/spend-policies. Enforced server-side before signing treasury wallet transactions. Migration 115.
• New: Embedded Wallets marketing page — Landing page at /embedded-wallets showcasing the platform for developers (feature grid, code snippets, integration steps).
• New: OAuth consent page — User consent UI at /oauth/authorize for third-party app authorization with scope display and approve/deny.
• SDK: Added sendEmailOtp(), verifyEmailOtp(), exchangeOAuthCode(), spend policy CRUD methods (createSpendPolicy, listSpendPolicies, updateSpendPolicy, deleteSpendPolicy).
• wallet-react: Added sendEmailOtp() and verifyEmailOtp() methods for passwordless login in the React widget.
• OpenAPI spec: Documented all new endpoints (email OTP, OAuth2 authorization/token/userinfo, spend policies).
• Docs: 2-minute embedded wallets quickstart guide at docs/guides/embedded-wallets-quickstart.
• Changed: OIDC discovery (/.well-known/openid-configuration) now advertises authorization_endpoint, userinfo_endpoint, and PKCE support (code_challenge_methods_supported: ["S256"]).

---

Bankr Dynamic Key Vending (Secret Engine)

• New: First-class "dynamic secrets" engine for Bankr. Store a long-lived partner key (bk_ptr_) in the secure zone; programmatically issue/revoke short-lived bk_usr_ wallet API keys for agents — scoped, TTL-bound, and automatically cleaned up.
• Endpoints: POST /v1/agents/{id}/bankr-keys/lease, GET /v1/agents/{id}/bankr-keys, DELETE /v1/agents/{id}/bankr-keys/{lease_id}.
• Lifecycle: Leases auto-revoke on agent deletion/deactivation. Nightly sweep cleans expired leases via Bankr DELETE.
• Shroud integration: When X-Shroud-Provider: bankr, Shroud auto-resolves the latest leased key for the agent. Falls back to static providers/bankr/api-key.
• SDK: client.agents.leaseBankrKey(), .listBankrKeys(), .revokeBankrKey().
• MCP: lease_bankr_key tool.
• CLI: 1claw agent bankr-key lease|list|revoke.
• Dashboard: Bankr Keys card on agent detail page (lease, list, revoke inline).
• Config: BANKR_PARTNER_KEY, BANKR_DEFAULT_WALLET_ID, BANKR_DEFAULT_LEASE_TTL_SECS.
• Security (v0.32.2): Leasing is deny-by-default — agents require explicit policy on agents/{id}/bankr/*. Agent lease responses and MCP lease_bankr_key output omit bk_usr_ keys (Shroud resolves server-side). Agent default TTL 15 min; recommend 5–15 min with revoke-after-task.

---

Shroud: Bankr LLM Gateway upstream

• New: Shroud provider bankr — route agent LLM traffic through Bankr LLM Gateway (https://llm.bankr.bot) with X-Shroud-Provider: bankr. Store bk_ keys at providers/bankr/api-key. Empty model allowlist (Bankr catalog is authoritative).
• Docs: Shroud supported models, Shroud guide, Ecosystem.

---

Security audit fixes — social login, treasury, webhooks, internal ledger (v0.24.1, SDK/OpenAPI 0.31.0)

• Fixed (CRITICAL): Social login Google/Apple tokens now validate OAuth audience and issuer (shared oauth_tokens module). Discord uses server-side authorization code exchange with oauth_redirect_uri (no raw access tokens in production).
• Fixed (CRITICAL): Removed email-based auto-linking on social login — existing email returns 409; users must sign in with their existing method first.
• Fixed (HIGH): Internal transfers require account ownership (from_account.user_id == caller.id).
• Fixed (HIGH): Internal transfers support Idempotency-Key replay protection (migration 110).
• Fixed (HIGH): Fiat webhooks in production require verified MoonPay signature (unsigned JSON rejected).
• Fixed (HIGH): Agents cannot supply client users/... signing paths; treasury mode=treasury only.
• Fixed (HIGH): Webhook PATCH URL updates run SSRF validation (validate_audience_url).
• Fixed (HIGH): Passkey tx-assert/complete validates origin; sign-count clone detection; optional tx_digest binding via X-Passkey-Tx-Digest.
• Fixed (MEDIUM): Treasury send sanity cap (10k ETH); proposal signer_address must match registered signer; auto_credit_account_id ownership check; internal transfer asset allowlist; ledger total is real count.
• Changed: Vault 0.24.1. @1claw/sdk, @1claw/cli, @1claw/mcp, @1claw/openapi-spec 0.31.0 (OpenAPI 2.17.0).

---

CDP parity Phases 2–4: deposits, fiat ramps, social login, internal ledger, embedded wallet (v0.24.0)

• New: Deposit destinations — POST/GET/PATCH /v1/deposit-destinations for unique inbound payment addresses per chain. deposit_destinations and deposit_events tables (migration 106). Webhook event deposit_destination.created.
• New: Fiat on/off ramps — POST /v1/fiat/onramp/session (Coinbase Onramp or MoonPay widget URL), POST /v1/fiat/offramp/initiate, POST /v1/fiat/webhooks (partner completion). Config: COINBASE_ONRAMP_APP_ID, MOONPAY_API_KEY, MOONPAY_SECRET_KEY.
• New: Social login — POST /v1/auth/social-login (public) accepts Google/Apple/Discord id_token, verifies JWKS, upserts user, auto-provisions Ethereum treasury wallet on signup. Migration 108 (users.social_provider, users.social_subject).
• New: Passkey transaction authorization — POST /v1/auth/passkeys/tx-assert/begin and .../complete return a short-lived passkey_token usable as X-Passkey-Token on treasury send (alternative to X-Auth-Confirm password).
• New: Internal accounts & ledger — POST/GET /v1/internal-accounts, POST /v1/internal-transfers, GET /v1/internal-accounts/{id}/ledger. Double-entry bookkeeping with SELECT FOR UPDATE balance checks (migration 107). Webhook internal_transfer.completed.
• New: @1claw/wallet-react v0.2.0 — <OneclawEmbeddedWallet /> with social login UI, Send/Swap/Receive/Buy views, passkey and fiat client methods.
• New: SDK resources — client.depositDestinations, client.internalAccounts, client.fiat.
• New: Dashboard hooks — use-deposit-destinations, use-internal-accounts, use-fiat.
• Changed: Vault version bumped to 0.24.0. SDK/CLI/OpenAPI spec bumped to 0.30.0.

---

CDP parity Phase 1: live webhooks, gasless treasury sends, wallet-react swap (v0.23.0)

• New: Webhook delivery wired end-to-end — dispatch_event() calls in treasury_wallets, policies, signing_keys, transactions, and treasury_proposals handlers. Background worker process_pending_deliveries runs every 5s. Events: wallet.transfer.sent, wallet.transfer.received, proposal.created/signed/executed/cancelled, agent.transaction.broadcast/signed, signing_key.rotated, policy.created/updated/deleted.
• New: Gasless treasury wallet sends — POST /v1/treasury/wallets/{chain}/send accepts gasless: true to wrap the send as an ERC-4337 UserOperation with Pimlico paymaster sponsorship. Response includes user_op_hash. Requires PIMLICO_API_KEY.
• New: @1claw/wallet-react v0.1.0 — added swap() client method, SwapParams/SwapResult types, swap exposed in context. <OneclawTreasuryWidget /> rebuilt with three views: Send, Swap, and Receive.
• New: Dashboard treasury WalletChainCard — inline balance with 30s auto-refresh, Send dialog (with gasless option), Swap dialog per chain. New hooks: useTreasuryWalletBalance, useSendFromWallet, useSwapFromWallet.
• Changed: Vault version bumped to 0.23.0.

---

2026-05

Security audit fixes (v0.22.1, 2026-05-30)

• Fixed (CRITICAL): Treasury signing authorization bypass — agents signing via Intents API in mode: "treasury" now require an active treasury_delegations entry with mode set to delegated or both. Previously, any agent with Intents API enabled could sign using treasury wallet keys without delegation verification.
• Fixed (H1): Delegation guardrails enforcement — per-delegation guardrails JSONB fields (to_allowlist, max_value_eth, allowed_chains) are now enforced during treasury-mode signing in the Intents API. Previously, delegation guardrails were stored but not checked, allowing agents to bypass spend caps and address restrictions on delegated treasury transactions.
• Fixed (H2): Webhook SSRF protection — webhook delivery dispatcher now validates destination URLs via validate_audience_url() (blocks private CIDRs, cloud metadata, .internal hosts, localhost) and disables HTTP redirect following to prevent SSRF via registered webhook endpoints.
• Fixed (H3): Account lockout on treasury send/swap — failed password re-authentication on POST /v1/treasury/wallets/{chain}/send and POST /v1/treasury/wallets/{chain}/swap now increments failed_login_attempts and triggers account lockout at 10 failures (matches existing behavior on export). Previously, send/swap brute-force did not trigger lockout.
• Fixed (M1): Treasury proposal sign_proposal authorization — POST /v1/treasury/{id}/proposals/{pid}/sign now verifies the caller is either a treasury signer or the proposal creator. Previously, any org member could submit signatures.
• Fixed (M2): Delegation mode filter for Intents API — only delegations with mode set to delegated or both are accepted for direct signing via POST /v1/agents/{id}/transactions with treasury_id. Owner-mode-only delegations are rejected (they must propose via the multisig pipeline).
• Changed: @1claw/wallet-react converted to a public git submodule (github.com/1clawAI/wallet-react, MIT license).
• Changed: Vault version bumped to 0.22.1.

Treasury wallet operations, webhooks, and gasless transactions (v0.22.0)

• New: GET /v1/treasury/wallets/{chain}/balance — query native token and ERC-20 token balances for a treasury wallet via RPC. Accepts optional ?tokens=0x... query param for ERC-20 addresses.
• New: POST /v1/treasury/wallets/{chain}/send — send native token or ERC-20 transfers from a treasury wallet. Human-only, requires password re-authentication via X-Auth-Confirm header. Audit-logged as treasury_wallet.send.
• New: POST /v1/treasury/wallets/{chain}/swap — DEX token swaps via 0x aggregator. Human-only with X-Auth-Confirm re-auth. Returns transaction hash and swap details. Requires ZERO_X_API_KEY env var.
• New: Webhook system — register HTTP endpoints to receive real-time event notifications. Full CRUD: POST /v1/webhooks (create, returns signing secret), GET /v1/webhooks (list), GET /v1/webhooks/{id} (get), PATCH /v1/webhooks/{id} (update), DELETE /v1/webhooks/{id} (delete). 12 event types: secret.created, secret.updated, secret.deleted, secret.accessed, agent.created, agent.deleted, policy.created, policy.updated, policy.deleted, transaction.submitted, transaction.signed, share.created. Deliveries use HMAC-SHA256 signatures (X-1Claw-Signature header) with 5 retries and exponential backoff. Database migration 105.
• New: GET /v1/agents/{id}/signing-keys/{chain}/balance — agents can query the native token balance of their signing key address.
• New: gasless: true flag on POST /v1/agents/{id}/transactions — enables gas sponsorship via Pimlico paymaster for ERC-4337 smart account transactions. When set, the handler requests sponsorship before signing the UserOperation.
• New: @1claw/wallet-react — embeddable React component package for Platform API apps. Components: <OneclawWalletProvider>, <OneclawTreasuryWidget>. Hooks: useOneclawWallet(). Supports wallet listing, balance display, and send operations.
• New: crypto/dex.rs module — 0x DEX aggregator client for swap quotes.
• New: domain/webhook_dispatcher.rs — background webhook delivery with retry logic.
• Changed: Vault version bumped to 0.22.0. SDK/CLI/MCP/OpenAPI all bumped to 0.28.0.

API key expiration and platform key rotation (v0.21.2)

• New: All three API key types (1ck_ human, ocv_ agent, plt_ platform) now support optional expiration via api_key_expires_at. Expired keys are rejected at authentication time with 401.
• New: POST /v1/platform/apps/{id}/rotate-key — rotate a platform app's API key with an optional new expiration date. Returns the new plt_ key (one-time).
• New: Agent create/update accepts api_key_expires_at (ISO 8601 datetime). Enforced during POST /v1/auth/agent-token exchange.
• New: Platform app create/update accepts api_key_expires_at. Enforced in auth middleware for plt_ Bearer tokens.
• New: Dashboard UI — KeyExpiryPicker component on agent create, platform app create, and API keys settings. Agent cards show expiry badges. Platform detail shows key expiration.
• New: CLI flags — --api-key-expires-at on agent create, agent update, platform create, platform update. New platform rotate-key <appId> command.
• New: MCP tool — platform_rotate_key with optional api_key_expires_at.
• New: Database migration 098 (agents.api_key_expires_at, platform_apps.api_key_expires_at, platform_apps.api_key_rotated_at).
• New: POST /v1/platform/connections/{id}/reissue-claim — reissue an expired claim URL for an existing connection without re-provisioning resources.
• Changed: OpenAPI spec v2.15.0. SDK/CLI/MCP all bumped to 0.27.0.

WebAuthn passkeys, email change, and agent approvals (v0.21.1)

• New: WebAuthn/FIDO2 passkey authentication — passwordless login and passkey management. Server-side P-256 ECDSA verification (p256 crate) with CBOR attestation parsing (ciborium crate).
• New: Passkey endpoints (public): POST /v1/auth/passkeys/assert/begin (start login), POST /v1/auth/passkeys/assert/complete (complete login → JWT).
• New: Passkey endpoints (authenticated): POST /v1/auth/passkeys/register/begin, POST /v1/auth/passkeys/register/complete, GET /v1/auth/passkeys (list), DELETE /v1/auth/passkeys/{id} (delete).
• New: Dashboard login page "Sign in with passkey" button. Settings → Security page has passkey management (register, list, delete).
• New: POST /v1/auth/set-password — allows platform-provisioned users (OIDC/Google, no existing password) to set their first password. Enables email/password login alongside existing auth methods.
• New: Email change flow — POST /v1/auth/change-email (sends 6-digit verification code to new email), POST /v1/auth/verify-email-change (completes change). One pending request per user, 15-minute expiry. Dashboard: Account settings email change dialog.
• New: POST /v1/approvals/request — agent-initiated approval requests for policy changes. Directed to the agent's creator (human). Dashboard approval inbox at /approvals and detail at /approvals/[id].
• New: Auto-execution of approved policy changes — when POST /v1/approvals/{id}/decide approves a policy_change action, the policy described in the approval summary is automatically created/updated.
• New: Database migration 097 (email_change_requests table).
• New: Dashboard hooks: use-approvals.ts (useApprovals, useApproval, useDecideApproval), use-passkeys.ts (usePasskeys, usePasskeySignIn, useRegisterPasskey, useDeletePasskey).
• New: lib/passkeys.ts — WebAuthn browser helpers (base64url encode/decode, credential creation/request options builders, attestation/assertion serialization).

Mobile companion app & approval queue (v0.21.0)

• New: Mobile companion app for iOS and Android (Expo/React Native, beta). Passkey authentication, biometric unlock, and push notifications.
• New: Device registration API — POST/GET/DELETE /v1/auth/devices for mobile device lifecycle, step-up challenge (POST .../challenge), WebAuthn attestation (POST .../attest), and push token registration (POST .../push-token).
• New: Approval queue — GET /v1/approvals (list with status filter), GET /v1/approvals/:id (details), POST /v1/approvals/:id/decide (approve/reject). Risk-tiered step-up authentication: routine actions require biometrics, critical/irreversible actions require passkey attestation.
• New: CLI commands — 1claw device list, 1claw device revoke, 1claw approval list, 1claw approval get, 1claw approval decide.
• New: MCP tools — list_approvals, get_approval for agent visibility into pending approvals.
• New: SDK resources — client.devices (list, revoke), client.approvals (list, get, decide), client.passkeys.
• New: OpenAPI spec v2.14.0 — 6 device endpoints, 3 approval endpoints, 11 new schemas, Approvals tag.
• New: Database migrations (092–096): user_devices, device_challenges, step_up_tokens, user_passkeys, approvals tables.
• Changed: Vault version bumped from 0.20.2 to 0.21.0. CLI 0.23.0. MCP 0.24.0. SDK types regenerated.

Security hardening round 3 (v0.20.2, 2026-05-14)

• Fixed (H-NEW-OIDC-SSRF): SSRF via Platform App oidc_jwks_url — validate_audience_url() wired into platform app create/update and inside resolve_oidc_subject() defense-in-depth. Prevents attacker-controlled JWKS URLs from reaching internal services.
• Fixed (H-NEW-DEK-REWRAP-RACE): Nightly DEK re-wrap race condition — added optimistic concurrency guard WHERE wrapped_dek = $old to UPDATE; skips on rows_affected == 0 to prevent races between concurrent re-wrap and secret-write operations.
• Fixed (M-NEW-IPV6-MAPPED): IPv4-mapped IPv6 bypass — is_private_or_reserved() now checks to_ipv4_mapped(), ULA fc00::/7, and link-local fe80::/10 to prevent IPv6 representation bypasses of private CIDR blocklists in audience/URL validation.
• Fixed (M-NEW-BUNDLER-OPEN): Bundler proxy unauthenticated — /api/bundler route now requires session cookie + per-IP rate limiting (20/min).
• Fixed (M-NEW-DEMO-UNAUTH): Demo vault/intents routes unauthenticated — /api/demo/vault and /api/demo/intents now require session cookie + per-IP rate limiting (10/min).
• Fixed (M-NEW-EXPORT-NO-LOCKOUT): Treasury wallet export no lockout — failed re-auth password now increments failed_login_attempts, triggers account lockout at 10 failures; successful re-auth resets the counter.
• Fixed (M-NEW-SIGNKEY-AGENT-UUID): Signing key path UUID binding — validate_signing_key_path now takes caller_agent_id and enforces UUID match on agents/{uuid}/ paths, preventing cross-agent key path traversal.
• Fixed (M-NEW-PLT-AUD-DISABLED): Platform audience not enforced — oidc_audience column added to platform_apps (migration 089). When set, enforced during JWT validation in resolve_oidc_subject().
• Fixed (L-NEW-FORWARDED-FOR): All demo/bundler routes now use x-vercel-forwarded-for instead of x-forwarded-for for reliable IP extraction on Vercel.
• Fixed (L-NEW-DEMO-AUTH-WEAK): Accepted risk — any non-empty session cookie passes auth check on demo routes, but combined with rate limiting this is acceptable for demo functionality.
• Changed: Vault version bumped from 0.20.1 to 0.20.2.

Platform API (v0.20.0)

• New: Platform API for developers building applications on top of 1Claw. Platform apps can provision users, vaults, agents, and policies on behalf of their end-users.
• New: plt_ prefixed API keys for platform app authentication. Resolved by auth middleware to CallerIdentity with principal_type: "platform".
• New: Bootstrap templates — declarative JSON specs that scaffold vault + agent + policies in a single API call (POST /v1/platform/connections/{id}/bootstrap).
• New: OIDC user provisioning — POST /v1/platform/users/upsert accepts a subject_token (JWT verified against the platform app's JWKS) or email to create-or-find end-users.
• New: Connected apps management — end-users can view and disconnect platform apps via GET/DELETE /v1/platform/connected-apps.
• New: Claim tokens (ct_ prefix) — one-time 10-minute tokens for end-users to claim bootstrapped resources.
• New: platform_locked flag on vaults and agents — prevents platform operators from accessing end-user secret values (custody guarantee).
• New: Three billing models: platform_pays (default), user_pays, hybrid. Per-resource payer override via vaults.billed_to_type and billed_to_id.
• New: Three auth modes: silent (no user interaction), user_signin (user must sign in), configurable (per-connection).
• New: Database tables: platform_apps, platform_templates, platform_user_connections, platform_user_grants, platform_claim_tokens (migrations 081–085). New columns on vaults, agents, access_policies, users, usage_events (migration 086).
• New: Dashboard pages at /platform — app management, template editor, connected users, bootstrap flow.
• New: SDK — client.platform.createApp(), .upsertUser(), .bootstrapUser(), .listConnectedApps().
• New: Platform audit events (platform.* actions) with dedicated query endpoint.

Security hardening round 2 (2026-05)

• New: Nonce-based Content Security Policy (CSP) — dashboard uses per-request nonces instead of 'unsafe-inline' for script tags.
• New: DEK re-wrap nightly job — automatically re-wraps data encryption keys using the latest KEK version, ensuring old key versions can be safely destroyed.
• Improved: OIDC federation audience URL validation now blocks cloud metadata endpoints (169.254.x.x, link-local) and private CIDR ranges.
• Improved: CORS explicit header allowlist — only documented request headers are accepted; unknown custom headers are rejected.
• Improved: MCP secret cache TTL and rate limiting — secrets fetched via the MCP server are no longer persisted beyond the session; rate limits added to prevent abuse.
• Improved: x402 payment proof cleanup — expired proofs are purged during the nightly credit expiry job.
• Improved: HTTP timeouts on all outbound RPC clients (KMS, Tenderly, chain RPC) to prevent hung connections.
• Improved: Demo Shroud endpoint rate limiting — prevents abuse of the public demo page.
• Improved: Platform handler audit events now include request_id for full request tracing.
• Fixed: Platform upsert_user now enforces org match — prevents cross-org user binding.
• Changed: KEK rotation period updated from 90 days to 365 days (NIST SP 800-57). Nightly KMS cleanup job destroys old key versions (keeps 2 most recent).
• Changed: MCP exfiltration protection default changed from warn to block.

Signing key auto-resolution and chain mapping (v0.19.2)

• Improved: Default signing_key_path now auto-resolves: if the agent has a per-chain signing key provisioned (via POST /v1/agents/:id/signing-keys), the handler uses agents/{id}/chains/{chain}/private_key; otherwise falls back to keys/{chain}-signer.
• Improved: Network names (e.g. sepolia, base, arbitrum) now map to canonical signing key chains (e.g. ethereum) via signing_key_chain_for(), so agents only need one Ethereum signing key regardless of which EVM network they transact on.
• Improved: validate_signing_key_path now also allows agents/{id}/chains/* paths (previously restricted to keys/*, wallets/*, agents/{id}/keys/*).
• Improved: Shroud default signing key path is now chain-aware (dynamically resolved to keys/{chain}-signer instead of hardcoded keys/default-signer).

Native multi-chain treasury wallets (v0.19)

• New: HSM-backed treasury wallet generation for human users across 6 chains: Ethereum (secp256k1), Bitcoin (secp256k1), Solana (Ed25519), XRP (Ed25519), Cardano (Ed25519), Tron (secp256k1).
• New: POST /v1/treasury/wallets/generate — generate wallets for specified chains (or all supported chains). Private keys stored in per-org __treasury-keys vault with auto-configured MPC custody.
• New: GET /v1/treasury/wallets — list all active wallets for the calling user.
• New: GET /v1/treasury/wallets/{chain} — get wallet for a specific chain.
• New: POST /v1/treasury/wallets/{chain}/export — export private key (audit-logged).
• New: POST /v1/treasury/wallets/{chain}/rotate — rotate wallet keypair.
• New: DELETE /v1/treasury/wallets/{chain} — deactivate wallet.
• New: MPC custody auto-configured per billing tier: XOR 2-of-2 for Pro/Team, Shamir 2-of-3 multi-HSM for Business/Enterprise.
• New: Dashboard wizard UI with QR codes for public addresses and key export.
• New: SDK — client.treasury.generateWallets(), .listWallets(), .getWallet(), .exportWallet(), .rotateWallet(), .deactivateWallet().
• New: CLI — 1claw treasury generate, list, get, export, rotate, deactivate.
• Changed: Treasury page no longer requires beta access — requires Pro+ subscription.
• Removed: Coinbase CDP embedded wallets replaced by native wallet generation.

Multi-chain signing keys (v0.18)

• New: Per-agent, per-chain signing keys for 6 blockchains: Ethereum (secp256k1), Bitcoin (secp256k1), Solana (Ed25519), XRP (Ed25519), Cardano (Ed25519), Tron (secp256k1).
• New: POST /v1/agents/{id}/signing-keys — provision an HSM-backed key for a chain. Returns public key and derived address. Private key stored in __agent-keys vault.
• New: POST /v1/agents/{id}/signing-keys/{chain}/rotate — rotate a chain's key (deactivates old version, creates new).
• New: DELETE /v1/agents/{id}/signing-keys/{chain} — deactivate a chain's key.
• New: Crypto modules — bitcoin.rs (secp256k1, P2WPKH bech32), solana.rs (Ed25519, Base58), xrp.rs (Ed25519, Base58Check), cardano.rs (Ed25519, bech32 enterprise), tron.rs (secp256k1, Base58Check).
• New: Dashboard — "Signing Keys" card on agent detail page with public keys, addresses, key version, and "Add Key" dialog.
• New: SDK — client.signingKeys.create(), .list(), .rotate(), .deactivate().
• New: CLI — 1claw agent signing-keys list, create --chain, rotate, delete.
• New: MCP tools — provision_signing_key, list_signing_keys.

Extended signing intents (v0.18)

• New: Unified POST /v1/agents/{id}/sign endpoint supporting three intent types:
  • personal_sign (EIP-191): Sign arbitrary messages. Requires message_signing_enabled on agent.
  • typed_data (EIP-712): Sign structured typed data (e.g. ERC-20 Permit). Enforces domain allowlist and deny-by-default for dangerous types (Permit, Permit2, etc.).
  • transaction: All EIP-2718 types — legacy (type 0), EIP-2930 access list (type 1), EIP-1559 (type 2), EIP-4844 blob (type 3), EIP-7702 (type 4).
• New: Agent guardrail fields — message_signing_enabled (boolean), eip712_default_policy ("deny"/"allow"), eip712_domain_allowlist (JSON array), signing_chains (text array).
• New: SDK — client.agents.sign(agentId, { intent_type, chain, ... }).
• New: CLI — 1claw agent sign.
• New: MCP tools — sign_message (EIP-191), sign_typed_data (EIP-712).
• New: Multi-chain keys example, EVM signing example, Agentic TX example, Non-EVM keys example.

Scaling & performance (v0.17)

• New: DEK cache — 60s TTL, 1000-entry DashMap, cuts KMS unwrap calls ~80%.
• New: Usage metering batching — in-memory buffer, batch INSERT every 5s/100 events.
• New: Distributed rate limiting — two-layer: in-memory L1 + optional Redis L2.
• New: Shroud nonce manager — DB-backed via Vault's POST /v1/admin/nonces/reserve.
• New: Cron job leader election via pg_try_advisory_lock.
• New: Quota header caching — DashMap 30s TTL per org.
• New: Manifest endpoint ETag/304 + ?since= incremental query.
• New: Daily spend partial composite index on transactions table.

---

2026-04

Agent self-enrollment: link-only and approval_url

• Updated: POST /v1/agents/enroll — human_email is optional. With email, a pending enrollment is created and Allow/Deny links are sent; the JSON response may include approval_url as a fallback if email is delayed. Name only creates a link-only pending enrollment; the response includes approval_url for the human to open while signed in to approve into their org.
• Updated: Database migration allows nullable org/user/email on pending_agent_enrollments for link-only rows; global cap on link-only pendings via ONECLAW_MAX_LINK_ONLY_PENDING_ENROLLMENTS (default 100).
• Updated: CLI agent enroll — --email is optional; prints approval_url when returned.
• Docs: Quickstart for agents, Agent self-onboarding, Give an agent access, OpenClaw.

MPC Secret Storage

• New: Multi-Party Computation (MPC) secret storage — split secret DEKs across multiple HSM providers so no single provider holds the complete key. Three custody modes: 2of2_client_custody (XOR split, client holds one share), 2of3_multi_hsm (Shamir 2-of-3 across GCP KMS + AWS KMS + Azure Key Vault, fully server-side), 2of3_client_custody (Shamir 2-of-3 with client share).
• New: POST /v1/vaults/{id}/mpc — enable MPC on a vault (user-only, Business/Enterprise tiers).
• New: client_share returned in SecretCreatedResponse for client custody modes. Must be stored securely — only returned once. Required via X-Client-Share header on read.
• New: Crypto modules — mpc_provider.rs (orchestrates split/reconstruct), shamir.rs (Shamir secret sharing over GF(256)), xor_split.rs (XOR 2-of-2), hsm_aws.rs (AWS KMS CryptoProvider), hsm_azure.rs (Azure Key Vault CryptoProvider).
• New: Database tables vault_mpc_keks and secret_dek_shares (migration 063).
• New: MPC guide in documentation.

GDPR Data Export

• New: POST /v1/auth/export-data — authenticated endpoint that returns a JSON archive of the calling user's personal data (profile, org membership, vaults, agents, policies, audit events, shares, billing). For GDPR data portability compliance.
• Updated: DELETE /v1/auth/me already handles account deletion with cascade cleanup (right-to-erasure).
• Updated: Compliance documentation now covers GDPR support.

Security hardening (2026-04-15)

• New: Agent token auto-revocation on policy changes — when an access policy targeting an agent is created, updated, or deleted, all of that agent's active JWTs are automatically revoked via the agent_active_tokens table (migration 066). The agent must re-exchange credentials to get a fresh token with updated scopes. Eliminates stale-scope window.
• New: KMS key rotation — GCP KMS vault KEKs are now created with a 90-day automatic rotation schedule and next_rotation_time. Existing ciphertext remains decryptable (KMS retains all versions).
• New: KMS CRC32C verification — all wrap_dek, unwrap_dek, and sign KMS operations now send CRC32C of input data and verify response CRC32C. Detects in-transit corruption or tampering. Added crc32c and prost-types crates.
• New: Audit insert hardening — migration 067 creates a restricted vault_app database role (no BYPASSRLS) and a SECURITY DEFINER function insert_audit_event. Direct INSERT on audit_events is revoked from vault_app, preventing log fabrication from compromised connections.
• Fixed: Shroud user-supplied blocked_patterns compiled via RegexBuilder with 256KiB size limit (ReDoS protection).
• Fixed: x402 facilitator verify now passes actual atomic USDC amounts. Settlement moved before broadcast in submit_transaction.

---

2026-03

Live demo

• New: Interactive demo page at 1claw.co/demo — three panels (Vault secret retrieval, Shroud prompt injection + secret redaction, Intents TEE transaction signing) with preset buttons, no signup required.

Onboarding wizard improvements

• Updated: Agent wizard is now 4 steps: register → save credentials → grant vault access (creates read policy) → connection snippets. Ensures agents don't start with zero access.
• Updated: Vault wizard is now 4 steps: create vault → store secret → grant agent access (creates read policy) → next steps.
• New: .env import on vault detail page — paste a .env file to bulk-create secrets with configurable path prefix.

Google OAuth JWKS

• Updated: POST /v1/auth/google now verifies the Google ID token locally via Google's JWKS (RS256 signature, audience, issuer, expiry). Replaces the previous tokeninfo endpoint call. More reliable (no URL length limits).

SSO (WorkOS)

• New: WorkOS SAML/OIDC SSO — GET /v1/auth/sso/authorize, callback handler, "Sign in with SSO" button on login page.

Security fixes (2026-03-16 audit)

• Fixed (C-3): Dashboard auth bypass — PUBLIC_PAGES prefix match for "/" matched all paths. Now uses exact match.
• Fixed (C-4): MFA token replay — MFA challenge tokens are now single-use (jti revoked after verification).
• Fixed (C-5): Cross-vault IDOR — agent JWTs with empty vault_ids no longer grant unrestricted access; vault IDs are derived from access policies.
• Fixed (H-19): Ed25519 SPKI DER parsing uses proper ASN.1 validation instead of a heuristic.
• New: signing_key_path validation restricts Intents API key paths to keys/*, wallets/*, agents/{id}/keys/*, or agents/{id}/chains/*.
• New: Shroud strips sensitive headers (authorization, cookies, IP headers) before forwarding to upstream LLM providers.

x402 marketplace compatibility

• Updated: 402 Payment Required response body now aligns with docs.g402.ai and x402scan: x402Version, accepts[] with maxAmountRequired (atomic units), resource (full URL), payTo, maxTimeoutSeconds, asset, description, mimeType. Enables registration on x402 marketplaces.
• Updated: On paid routes, x402 middleware runs before auth so unauthenticated requests receive 402 (with payment details) instead of 401. Scanners and buyers can discover and pay without a token.
• New: Optional x402.asset (DB/API) and X402_ASSET env — default is Base USDC. Used in 402 accepts[].asset.
• Updated: SDK PaymentAccept and auto-pay logic support the new 402 shape; maxAmountRequired (atomic) with fallback to legacy price (USD). Custom X402Signer implementations should use maxAmountRequired and asset.
• Updated: Dashboard proxy passes discovery paths (/openapi.json, /.well-known/x402) through without /v1 prefix so vault discovery routes are reachable at api.1claw.co.

2026-02

Tenderly Transaction Simulation

• New: POST /v1/agents/:agent_id/transactions/simulate — pre-flight simulation of EVM transactions via Tenderly. Returns balance changes, gas estimates, decoded errors, and a Tenderly dashboard deep-link. No signing or broadcasting occurs.
• New: POST /v1/agents/:agent_id/transactions/simulate-bundle — simulate multiple sequential transactions (e.g. approve + swap).
• New: simulate_first flag on POST /v1/agents/:agent_id/transactions — runs a Tenderly simulation before signing. If the simulation reverts, returns HTTP 422 and does not sign. Org admins can enforce this as mandatory via the intents_api.require_simulation setting.
• New: EIP-1559 (Type 2) transaction signing — set max_fee_per_gas and max_priority_fee_per_gas instead of legacy gas_price.
• New: Automatic nonce resolution via eth_getTransactionCount RPC when nonce is omitted.
• New: Address derivation from private key (secp256k1) — the simulation endpoint resolves the from address without exposing the key.
• New: simulate_transaction MCP tool and simulate_first argument on the submit_transaction MCP tool (defaults to true).
• New: simulateTransaction() and simulateBundle() methods in the TypeScript SDK.
• New: Dashboard Transaction Builder on the agent detail page — simulate, review balance changes, then confirm and send.
• New: Transaction history table on the agent detail page with simulation status badges and tx hash copy.

Transaction replay protection & response hardening

• New: Idempotency-Key header on POST /v1/agents/:agent_id/transactions — duplicate requests with the same key within 24 hours return the cached response (200) instead of signing and broadcasting again. In-progress duplicates return 409 Conflict.
• New: Server-side nonce serialization — when nonce is omitted, the server atomically reserves the next nonce per agent+chain+address via SELECT FOR UPDATE locking, preventing nonce collisions between concurrent requests.
• New: signed_tx redacted by default — GET transaction endpoints omit the raw signed transaction hex. Pass ?include_signed_tx=true to include it. The initial POST submission always returns it.
• New: transaction_idempotency and nonce_tracker database tables (migrations 034, 035).
• New: Nightly cleanup of expired idempotency keys (>48h) in the existing credit expiry background job.
• Updated: SDK submitTransaction() auto-generates an Idempotency-Key header (UUID). Callers can override via options.idempotencyKey.
• Updated: MCP submit_transaction tool auto-generates an Idempotency-Key header.
• Updated: OpenAPI spec documents Idempotency-Key header and include_signed_tx query parameter.

Admin user management

• New: DELETE /v1/admin/users/:user_id — platform admins can delete users. Cascades: delete share links created by the user, clear agents.created_by, then delete the user (device_auth_codes and user_api_keys CASCADE in DB). Cannot delete self or the last owner of the platform org.
• New: scripts/cleanup-test-users.sh — removes test users by display name. Auth via ONECLAW_TOKEN or ADMIN_EMAIL + ADMIN_PASSWORD. Use --dry-run to list only.

Security audit hardening

• New: Per-agent transaction guardrails — tx_allowed_chains, tx_to_allowlist, tx_max_value_eth, tx_daily_limit_eth enforced before signing.
• New: Audit hash chain — each event stores prev_event_id and SHA-256 integrity_hash for tamper detection.
• New: x402 payment replay protection — payment proofs deduplicated via SHA-256 before facilitator verification.
• New: Authorization enforcement on delete_secret, list_secrets, and list_versions (policy check, not just org membership).
• Improved: CORS defaults to https://1claw.co in production (no more permissive Any fallback).
• Improved: CSP removes unsafe-inline and unsafe-eval from script-src.
• Improved: Global rate limiting middleware applied to all API routes.
• Improved: Dependency overrides for minimatch, ajv, hono to address known CVEs.

Dashboard UX — CopyableId

• New: One-click copy for every UUID, path, and identifier across the dashboard. Vault IDs, agent IDs, principal IDs, audit actor/resource IDs, API key prefixes, secret paths, and user/org IDs in the sidebar — all clickable with tooltip confirmation.

Quota exemption for platform admin orgs

• New: CallerIdentity.quota_exempt flag resolved at authentication time. Platform admin org (and its agents) bypasses all billing checks. Cleaner than per-route overrides — single source of truth in auth middleware.

Policy UI improvements

• New: Vault selector dropdown on Create Access Policy page — pick any vault, not just the one in the URL.
• New: Agent principal picker — select from existing agents or type a custom agent ID.
• New: Edit policy dialog — update permissions, conditions (JSON), and expiry on existing policies.
• New: Delete policy from the policies list page.

Agent integration guide

• New: Agent detail page in the dashboard now includes a tabbed integration guide with copy-paste code snippets for TypeScript SDK, Python, curl, and MCP configuration.

PolyForm Noncommercial License

• All repositories now include the PolyForm Noncommercial License 1.0.0.

Organization migration

• All repositories moved to the 1clawAI GitHub organization.

Email notifications

• New: Transactional emails via Resend for account and security events.
• Welcome email on signup (email/password and Google OAuth).
• Share invite email when a secret is shared by email.
• Share access notification to the creator when a shared secret is accessed.
• Password change confirmation email.
• API key creation notification email.
• Emails are fire-and-forget (non-blocking) and silently skipped when no RESEND_API_KEY is configured.

Sharing & invite-by-email

• New: external_email share type — share secrets with users who don't have accounts yet.
• New: Claim-on-login — pending email shares are automatically claimed when the recipient signs up or logs in.
• New: Share access notifications — creators are emailed each time a shared secret is accessed.
• New: POST /v1/auth/signup — self-service account registration via email/password.

SDK rewrite (@1claw/sdk v0.2.0)

• New: Full API parity — typed methods for all 42+ REST API endpoints.
• Resource modules: vault, secrets, access, agents, sharing, auth, apiKeys, billing, audit, org.
• createClient() factory with auto-authentication (API key or agent credentials).
• { data, error, meta } response envelope on every method.
• Typed error hierarchy: AuthError, PaymentRequiredError, NotFoundError, RateLimitError, etc.
• x402 auto-payment support with configurable maxAutoPayUsd.
• MCP tool layer: McpHandler and getMcpToolDefinitions() for AI agent frameworks.
• auth.signup() for programmatic account creation.
• sharing.create() with email support for invite-by-email.

Examples repository

• New: examples/basic/ — TypeScript scripts for vault CRUD, secrets, billing, signup, and email sharing.
• New: examples/nextjs-agent-secret/ — Next.js 14 app with Claude AI agent accessing vault secrets.

MCP server (@1claw/mcp)

• New: MCP server for AI agent access to secrets via the Model Context Protocol.
• 7 tools: list_secrets, get_secret, put_secret, delete_secret, describe_secret, rotate_and_store, get_env_bundle.
• Browsable vault://secrets resource.
• Dual transport: Local stdio mode (Claude Desktop, Cursor) and hosted HTTP streaming mode (mcp.1claw.co).
• Per-session authentication in hosted mode — each connection gets its own vault client.
• Auto-deploy to Cloud Run via GitHub Actions.

Billing & usage tracking

• New: Usage tracking middleware records every authenticated API request.
• New: Free tier — 1,000 requests/month per organization.
• New: x402 Payment Required responses when free tier is exhausted, with on-chain payment on Base (EIP-155:8453).
• New: Billing API — GET /v1/billing/usage (summary) and GET /v1/billing/history (event log).
• Unified billing across dashboard, SDK, and MCP — all count against the same quota.

Vault API

• Added POST /v1/agents/:agent_id/rotate-key endpoint for agent key rotation.
• Added GET /v1/billing/usage and GET /v1/billing/history endpoints.
• Usage middleware tracks method, endpoint, principal, status code, and price per request.
• x402 middleware enforces free tier limits and returns payment-required responses.

Infrastructure

• Cloud Run deployment for MCP server (oneclaw-mcp).
• Terraform resources for MCP service and domain mapping.
• GitHub Actions workflow for MCP auto-deploy.
• CI pipeline expanded: MCP type check, build, Docker image build and Trivy scan.

Documentation

• New: Full MCP documentation section (overview, setup, tool reference, security, deployment).
• New: Billing & usage guide.
• New: Deploying updates guide.
• Updated intro, MCP integration guide, and changelog.
• Updated llms.txt and llms-full.txt with MCP and billing content.

Initial release (2026-02 early)

• Vault API: vaults, secrets (CRUD + versioning), policies, agents, sharing, audit log, org management.
• Human auth: email/password, Google OAuth, personal API keys (1ck_).
• Agent auth: agent API keys (ocv_) exchanged for short-lived JWTs.
• Envelope encryption with Cloud KMS (or SoftHSM for local dev).
• Dashboard: Next.js with full secret management UI.
• TypeScript SDK (@1claw/sdk).
• Docusaurus docs site.
• Terraform infrastructure (Supabase, GCP, Vercel).