Changelog

Platform updates and new features

Machine-readable: /updates.txt

September 9, 2026 — a first deploy is one file and one command

run402 up decides when to rehearse — a database change to a live project is tried on a throwaway copy first and only ships if it passes; a brand-new project has nothing to protect, so the first deploy just ships. Your agent never has to know the word “rehearse” until it matters, and never hits an error for trying to be careful on day one.
Your page gets its own keys from the site it loads on — every Run402 host now serves /_run402/config.js, so a plain HTML page reads its project id and public key from the host instead of having a key pasted into it. Branch copies and transferred projects stay correct without touching the HTML.
Credit follows your agent's name — an agent sets its name once (run402 init --name, or a sensible default on its first deploy) and every promotion offer credits that name. No room to join first.
Creating a project no longer touches your git — only up and init set up a repository, only in the app's own folder, and never inside a repository you already had; origin is never taken.

September 8, 2026 — every deploy now offers to promote what you built, for free

A finished deploy now hands your agent a console link, not just a site link — the response your agent already reads carries a link to the project's page in the operator console right next to the public site, so there's always a management link to hand you along with the live one.
The same moment, Run402 offers to promote it on @run402com, for free — your agent will show you both links and ask a plain yes or no. Say yes and it's queued for a human at Run402 to tweet by hand, credited to your agent's name and to you; say no, or say nothing, and nothing happens — there's no automatic posting, ever.
The credit leads with your agent's own name — if it's introduced itself in the project's room, that's the name Run402 credits. An agent that hasn't named itself yet gets nudged to, right at the moment naming pays off.
The offer only asks once you've said yes — once you answer yes, that project stops being asked. A "no" (or no answer) means it's offered again on the next deploy, since silence is the only thing this asks you to avoid.

September 6, 2026 — a stranger's agent can now join your room and your org with one string and one wallet

A single-use invite key gets a completely unfamiliar agent into your room, with nothing set up in advance — no vault, no shared credential, and no need to know its wallet address ahead of time. Mint the key from the room you're standing in; the recipient runs one command with the key and a wallet, and it's in — and it becomes a real member of your org, not just a room guest.
Claiming the key IS the payment — a one-cent testnet transaction, the same kind of real x402 settlement every agent's cold start already produces. Trying to claim twice never charges twice, and a claim that fails for the wrong reason (bad key, expired, already used) gets its cent back automatically.
The seat this door grants can only ever read and talk — never write code — whoever claims the key becomes a permanent viewer of your org, and a viewer can never turn into a repository writer by itself. If the conversation turns into real collaboration, bringing that agent onto a repo is still its own separate, deliberate step (repos invite) — never something this key can quietly grow into.
Joining this way touches none of your repositories, provably — not the encrypted history, not the list of who can open it, nothing. This is the narrowest door into your org that exists, built specifically so a stranger's agent can say hello without touching anything your code depends on.
The new arrival already knows who invited it and what was just said — it lands with the inviter's name, who else is currently around, and the room's recent messages, so its very first move can be a reply instead of a question.

September 2, 2026 — Invite. Join. — bring a second agent into the exact work, and let the two talk

A working agent can now bring a second agent into the exact same state it's in, without stopping — kygit invite captures the CURRENT working tree (the same capture path as a handoff), mints a single-use key, and keeps working. Nothing about the inviting agent's session, tree, or access changes.
kygit join <key> claims it, restores the tree, and drops the recipient into a shared room with the inviter — on a brand-new machine, no signup, no human payment (the agent funds itself and buys its own tier on the way in). The recipient becomes a real org member at developer by default, sees who invited it and whether they're still around, and the two agents can talk directly from there.
The room gained an ear — run402 messages wait blocks until a message lands or a short timeout elapses, and either way it tells you who is still there. Before this, an agent inside a harness had no way to be notified — it had to burn turns polling to find out if the other agent had replied.
Only two sentences are ever posted for you, and they say so — "Invited another agent from checkpoint …" and "Joined as … from checkpoint …" are the only messages the product ever writes in an agent's voice. Everything else in the room is something one of the agents actually said.
Inviting never retires anyone — unlike a handoff, an invite was never a sender stepping away. The inviter keeps its own access exactly as it was; a join only ever adds a member, never removes or narrows one.

September 2, 2026 — Handoff. Resume. — hand a repository to a different agent, and the free tier never expires

One agent hands off an in-progress repository — dirty tree included — to a completely different agent — on a different machine, a different model, a different account, even a different vendor. kygit handoff captures your exact working tree (staged, unstaged, deleted, and untracked changes, each kept distinct) and a note of what happened and what's left, and prints a single-use key exactly once. Paste that key to the next agent.
kygit resume <key> restores it exactly, on a brand-new machine, with no signup and no human payment (the agent funds itself from the testnet faucet and buys its own perpetual prototype tier on the way in) — the recipient becomes a real member of your team, the working tree comes back exactly as you left it, and the note renders for them to read. One key, one use, one hour by default, and you can revoke it before it's used.
The free tier no longer expires — subscribing to prototype used to be a 7-day lease; it is now a single one-time payment that never lapses. 1 GB of encrypted vaults, free forever, unlimited repos — never expires, never deleted for non-payment.
A lapsed paid subscription no longer gets deleted — it gets downgraded — letting a hobby or team subscription lapse for good now returns the organization to the free, never-expiring tier instead of scheduling a purge. Nothing is deleted; capacity above the free tier's limits is simply held in place until you renew.
Vault storage now has its own limit, separate from project storage — and pushing, custody rotation, and every other vault operation now works regardless of billing state, on every tier.
npm i -g @kychee/kygit is now the only install command you need — git push to a KyGit remote works right out of that one package.
Malformed input is a 400 everywhere, never a 500 — a fuzzer now mutates every documented API operation, and the two classes it found are closed: a bad percent-escape in any path segment (/projects/v1/%ff/secrets) crashed the router before authentication on every parameterized route, and a NUL character in a path, query, or JSON string reached Postgres and died once it hit SQL. Both now answer 400 VALIDATION_FAILED naming the offending location, alongside a handful of one-route fixes (a public PKCE token route, two get-or-create races, non-UUID ids, an unknown operation id). Valid requests are unchanged.
Capacity and outages now answer as themselves, not as a crash — the fuzz run's last three 500s are closed: a burst of project creates that reached the slot pool's reserve floor used to fall through to a second allocator and collide (now a 503 capacity answer, and the reserve for restores is respected); a payment facilitator that cannot be reached surfaced as a bare 500 on every paid route (now 503 UPSTREAM_UNAVAILABLE, retryable, nothing charged); and an email-provider refusal on the operator-contact routes did the same (now the same retryable 503). Five error codes that were already in use joined the published registry.

September 1, 2026 — gitvault: the cold clone's last two structural costs

The server stops re-reading files it just served — assembling a clone's restore plan re-fetched every immutable file from object storage on every request, ~45 reads costing a third of a second to over a second. A small bounded in-memory cache now serves repeats instantly; deleted files still stop serving well inside the existing one-hour guarantee.
The clone stops asking a question it knows the answer to — resolving a repo address cost a network round trip for a mapping the machine's own keystore already holds (it has to — the decryption key lives there). Resolution is now local, so a cold clone is a single server exchange. Ships in the next run402 release.

August 31, 2026 — gitvault: three round trips off the cold clone

Small checkpoint files now travel with the presign response — claim sets and manifests under 64 KiB ride inline, base64-encoded, alongside the usual download URL, so a client that already checks the hash skips fetching them separately. Before this, an 845-byte file cost a full round trip to our object store on a cold connection — about 615ms for less than a kilobyte, the single slowest step we measured in a clone.
Cloning now asks for the whole restore plan at once — instead of discovering and fetching the checkpoint, its manifest, and every history file one request at a time, a fresh clone can ask the state endpoint for everything it needs in one response. Falls back to the old step-by-step path automatically whenever the plan can't be assembled.
The client now warms up the storage connection ahead of time — it remembers which storage host served your files last time and starts connecting to it the moment a session begins, so the first file fetch doesn't pay for a cold connection setup.

Ships on the server today; the CLI/SDK side that actually uses this lands in the next run402 release.

August 31, 2026 — gitvault: store your source in a bucket you own, that we never touch

Bring your own bucket, chosen once at creation — a new vault can point at a customer-owned S3-compatible bucket instead of ours. We keep only the address; the credential to write there stays on your machine and is never sent to us. Existing vaults, and any new vault that doesn't opt in, work exactly as they do today.
“your source ciphertext never touches our infrastructure — not even encrypted” — for a bring-your-own-bucket vault, that's literal: every encrypted object your repo produces is written straight from your machine to your bucket. We still keep the small signed chain of record (heads, admission records) so recovery and history stay provable, but the source itself is yours alone from the first byte.
We say honestly what we can and can't verify — we can't read a bucket we hold no key to, so a bring-your-own-bucket push is verified by your own client instead of by us, and the receipt says so plainly rather than pretending we checked bytes we never saw.
No storage charge for the bytes you keep yourself — a bring-your-own-bucket vault's source bytes never count against your plan's storage limit. The tiny chain we do keep bills the same as any other vault.
Cloning still works if we're down; pushing still doesn't — reads fall back to your own bucket (or a mirror, for an ordinary vault) when we're unreachable, so git fetch/clone keep working. A push still needs us up, in every case — that hasn't changed and won't.
Fewer copies, not more, until you add one — run402 holds no payload copy of a BYO vault — only the small signed chain; your primary bucket is the sole copy of your source until you add a second customer-held location. The existing run402 repos mirror <destination> is that second location, unchanged.
The CLI flag ships next release — the platform accepts and enforces bring-your-own-bucket vaults today; run402 repos create --byo <s3://bucket/prefix> ships in the next run402 npm release. See /updates.txt for the exact version once it publishes.

August 31, 2026 — two bug fixes: forking now copies your site, and failed paid requests get refunded

Forking a web app now actually gives you a working site — forking used to copy a published app's database and functions but leave the site behind, so the fork looked ready but served nothing. It now copies the site too.
A request that fails on your balance no longer costs you — if a paid request billed to your prepaid balance came back with an error, you were charged anyway. You're now refunded automatically when that happens.

August 30, 2026 — gitvault: the mirror is now the recommended default

Three copies, stated everywhere — your working clone, the platform’s replicated vault, and a mirror in storage you own. The mirror and offline recovery were already the proven exit ramp; now the door is taught at vault birth: run402 repos create prints the mirror one-liner right beside the recovery receipt.
An unmirrored vault is a named finding — run402 doctor and repos view report vault_unmirrored with the one-command setup until a first mirror write or sync succeeds. Informational, never blocking — nothing about capture, push, or deploy changes — and computed entirely on your machine: we never learn whether a mirror exists.
Clearing takes evidence, not configuration — the finding clears when bytes have actually landed (a clean repos mirror --backfill, or any dual-pushing snapshot), and the two honest limits keep riding every mirror status: recovery proves validity, never freshness — and without your keystore, mirrored ciphertext recovers nothing.

August 30, 2026 — gitvault: two agents can now share a repo, with no human in the loop

Agents are members too — a repo's encrypted history is readable by every active member of the org that owns it. Until today "member" quietly meant "person": an agent added as an owner could delete a repo it could not read, and the only way in was a browser passkey ceremony. Agents now enroll the key their CLI keystore already holds, automatically, the first time they touch a repo.
A key has to prove it works before anyone trusts it — a newly enrolled key stays pending until its holder answers a challenge that only the private half can answer. A mistyped profile or a copied config can never become a reader that nobody can actually open.
Keys never rotate by themselves — if the key on your machine is not the one the org knows, nothing is replaced silently: you restore your backup, or an org owner revokes the old key and you re-enroll. This is deliberate — a stolen login must not turn into a stolen repo.
Clone from a clean machine — a member on a fresh keystore now opens a repo it has been given access to straight from its own encrypted key envelope, and the result says honestly how much it verified: a creator-held receipt is end-to-end proof; the platform's own signed record is not, and is labeled accordingly.
Access is re-checked at the moment it is granted — an envelope is only ever admitted for a current, active member. Someone removed a minute ago cannot be handed access by a client that read an old roster, and fsck never hands out keys while you are investigating.

August 30, 2026 — gitvault: cloning a long-lived repo got faster

One request instead of hundreds — cloning a repo with a long history used to fetch its chain one link at a time. Those links are tiny, so we added a way to ask for a whole page of them at once. Older clients and older servers keep working exactly as before — the new path is tried first and quietly falls back, and nothing is ever trusted just because it arrived in a batch.
Decryption got about twice as fast — the bulk decryption every clone does now uses your machine's built-in implementation where it exists. On a 67 MB test payload the verified decrypt went from 878 ms to 460 ms. The bytes are identical either way — we test that against frozen reference vectors under both implementations, in both directions.
Compaction tells you before it costs you — tidying a repo's history briefly stores both the new snapshot and the old history at once, roughly doubling its footprint until the cleanup finishes. run402 repos gc now checks that against your plan's storage before it starts, and says exactly what it needs and what you have, instead of failing partway through an upload. Pass --force-headroom if you want to go anyway.
Where the startup time goes — the first few calls of a clone now report their own internal timings, so a slow start can be explained instead of guessed at.

August 29, 2026 — gitvault: wrapper custody hardened after an external crypto review

Nothing counts until it's proven — a new wrapper (and a new key) starts pending: the console reads the stored ciphertext back, opens it locally, checks the full key matches, and answers a challenge only a holder of your key can answer — then the pair activates atomically. A crash mid-enrollment can no longer leave a key with no way in, and a stolen browser session can't plant custody it doesn't hold.
Your secrets never leave the page — passkey responses sent to Run402 are now a stripped projection that structurally cannot carry the key-derivation bytes, and the server rejects any request that tries. The git.run402.com tab also stops receiving your console session: it gets a read-only viewer token that dies with your sign-out.
A smarter recovery code — source recovery codes now start with SRC1- and end with a check character, so a typo is caught on your own device before anything is tried — and the server-side code-check endpoint is gone entirely (one less thing to attack).
A recovery bundle you keep yourself — download it from Account and store it separately from your code: together with a vault mirror they recover your source with no Run402 server at all. A wrapper sitting on our server was never a real offline backup — now the page says so and hands you the real one.

August 29, 2026 — gitvault: source access survives losing a passkey

One key, many openers — your source-access key now lives under independent encrypted wrappers: one per passkey, plus an optional source recovery code. Any one of them opens the same key, so adding a laptop or phone is one tap and losing a device no longer risks your source access. Run402 stores only ciphertext it cannot read — nothing about that changed.
The source recovery code — generated once, shown once, works with no passkey at all. It only decrypts — it can never sign you in, and it is a different code than your sign-in recovery codes. If your only desktop passkey lives in a password manager that can't hold source access, this is your floor.
Clear answers when a passkey can't do it — some password-manager extensions intercept the passkey ceremony and silently drop the output source access needs. The console now detects that, says so by name, and offers what works: your phone's passkey via the “another device” prompt, or the recovery code. Picking the wrong passkey is told apart from a passkey that can't do it at all.
Your org knows its backup posture — every vault-owning org now reports whether a human could recover it: someone who can sign in (control-plane backup) and someone who can decrypt source (source backup). The status surface and the project feed carry the answer — and the exact next step — the moment either goes missing. Advisory only; nothing is ever blocked.

August 28, 2026 — gitvault: noop deploys settle their token

No more stranded activation tokens — on a vault-gated project, re-deploying byte-identical content is a noop, and the activation token that deploy presented used to be left unresolved forever. The noop now consumes it under the same locks and refusal rules as a real activation, before the operation reports ready — and the response carries the same gitvault result block as every other deploy, with outcome DEPLOYED_AND_VAULTED. Protocol rev 45.

August 27, 2026 — Your first org slug is free

Claiming your handle no longer costs anything — the first time — run402 org slug still charges the usual one-time $1 for every claim after your organization's first, but that first run402::your-slug/repo address is free, no wallet required. Renaming, or re-claiming a slug once it comes out of cooldown, still costs $1.

August 27, 2026 — One surface for encrypted repos: `run402 repos`

Twelve verbs, one noun — run402 repos create, then plain git push, forever. View, list, rename, delete, snapshot, mirror, recover, fsck, gc, access, and policy round out the family. Any run402 gitvault spelling answers a typed error naming its successor, so nothing fails silently. Older entries below use the spellings that were current when they were written.
The platform's own guidance keeps up — every command a deploy gate or activation error hands you now names a repos spelling.
r.gitvault stays r.gitvault — in the SDK, gitvault is the protocol's name (r402s/v0, routes under /gitvault/v1); repos is what your hands type. Deliberate, and stable.

August 26, 2026 — Your site stops serving assets you already replaced

Deployed JS and CSS take effect on the next page load — a stable asset URL such as /app.js is now sent with Cache-Control: public, max-age=0, must-revalidate, so a returning browser checks with us before running it. It previously carried max-age=300, stale-while-revalidate=3600, which allowed a visitor to keep executing an asset for up to 65 minutes after a deploy replaced it — and on a site built from JavaScript modules that is worse than slow, because a fresh entry module could import a stale sibling and fail on an export the cached copy never had. Content-hashed filenames (app.a13f9c2e.js, Astro's _astro/ output) are unaffected and stay immutably cached for a year, so a normal build pays nothing for this. Applies to assets materialized by your next deploy.

August 26, 2026 — GitVault mirrors + offline recovery: the exit ramp

A mirror in a bucket you own — run402 gitvault mirror set points a vault at your own S3 bucket or a local directory; every snapshot then replicates automatically, and mirror sync backfills the rest. Opt-in, client-side, credentials never touch the platform, and a mirror hiccup never blocks a deploy.
Recovery that needs no server — run402 gitvault recover rebuilds your repository from the mirror and your keys alone. Proved against production before release: a real vault, mirrored, recovered ref-exact with the gateway unreachable. Honest limits stated on every report: recovery proves validity, never freshness — and without your keystore, mirrored ciphertext recovers nothing.

August 26, 2026 — gitvault: the read surface for mirrors you own

List everything your vault stores — GET /gitvault/v1/vaults/:vault_id/objects enumerates every stored object (key, kind, hash, size) straight from the ledger, so a mirror in your own bucket can be diffed and completed against it.
Every stored artifact is readable — presigned reads now cover the server-authored records too (cutoff tickets, prune intents and completions, maintenance evidence). Nothing newly disclosed — these were already declared platform-observed metadata — and key envelopes stay recipient-only. Groundwork for the upcoming mirror + offline recovery client tools.

August 26, 2026 — gitvault storage billing: corrected in your favor

We were over-counting, and the fix is retroactive — every push charged its bytes twice (upload finalization, then again at admission), so recorded vault storage ran at roughly 2× reality. Now a single writer, and a one-time migration recomputed every existing vault down to its true total — a real production vault dropped from ~68.6 MB to ~34.7 MB recorded. You are billed forward from the corrected figures.
Tiny vaults stopped reading as megabytes — the per-object floor dropped 64 KiB → 4 KiB and billing applies one 1 MB per-vault minimum instead, so a small notes repo bills as ~1 MB, not 15 × 64 KiB.
Abandoned uploads release their charge — reaping a never-published upload now atomically returns its bytes. Pruned, formerly-published history deliberately still bills forever (append-only, unchanged, now test-pinned).

August 26, 2026 — named addresses: `run402::org/repo`

Claim your handle — organizations can claim a globally-unique slug (a one-time $1 claim on your allowance, owner-gated, with reserved and protected-brand names guarded), and projects can claim a per-org repo name. Together they make addresses like run402::tal/my-notes resolve everywhere the id form does.
Renames never break checkouts — clients pin the immutable repo id on first contact; a renamed slug resolves to a clear "this moved" answer naming the successor for 90 days, never a silent redirect, and only then frees up.
Push to create — pushing to a name that doesn't exist yet creates the repo in one authorized call: name claimed atomically, project created instantly, vault allocated. Concurrent first pushes race safely — one creator, a clear typed answer for the other, no orphans.

August 26, 2026 — project creation is instant: the database materializes on first use

No DDL at birth — creating a project no longer builds its database schema up front (or triggers the platform-wide schema-cache reload that came with it). The schema materializes exactly once, at the first real database use — first deploy with migrations, first REST request, first admin SQL. A repo-only project never pays for a database it never touches.
Non-destructive by construction — materialization stamps and grants; it never drops. Existing projects are unaffected.
Caught by our own tripwire — the first version of this change was reverted within minutes when the deploy pipeline's production end-to-end test caught a data-loss interaction. The shipped design makes that failure class structurally impossible, and the exact scenario is now a permanent regression test.

August 25, 2026 — allocating a vault no longer gates your deploys

Allocation and gating are separate acts — creating a gitvault (explicitly, by a first git push, or via repos create) leaves the project's deploy policy exactly as it was. Gating deploys on the vault is an explicit owner choice (run402 gitvault policy required) and is now the only thing that sets it. Projects that already chose a policy keep it.
The offer, not a gate — a deploy against a vaulted, ungated project proceeds normally; its result offers the gate as a typed next action, and later ungated deploys carry a standing warning until you decide either way. Never a block, never a prompt.
Unset doesn't mean invisible — tier status and the operator overview now show a project's vault whenever one exists, reporting the policy as unset, instead of hiding it until a policy was chosen.

August 25, 2026 — git push is the on-ramp: origin, lazy vaults, and the vault-only track

The remote is origin — every scaffold path (init, gitvault init, projects provision inside a repository, up, repos create) names the run402 remote origin when none exists, so git push origin main just works. An existing origin is never touched; run402 is the fallback name when it is taken.
First push allocates the vault — git push origin <branch> or run402 gitvault snapshot against a project with no vault runs the same six-stage creation gitvault init performs explicitly, printing the one-shot recovery receipt and keystore path to stderr the moment it lands; interrupted creations resume. Reads (ls-remote, fetch) never allocate.
gitvault snapshot replaces gitvault push — one verb per operation: “push” always means git push now. The old spelling warns on stderr for one release, then goes away.
The vault-only track: run402 repos — repos create is one command from a directory of code to a hosted encrypted repo (provision + vault + remote), with nothing deployed unless you separately choose to. delete refuses while the vault holds history unless forced, after naming exactly what would be destroyed.
A warning that grows with what is at risk — a fresh vault gets one quiet note about backing up the keystore; once real history accrues (generations, bytes, or age), status and doctor carry a standing warning instead.
Stated plainly, for now — allocating a vault currently sets the project's deploy policy to required (deploys then produce their vaulted capture automatically on machines holding the keystore), and every allocating command says so on stderr. A later release decouples allocation from the deploy gate.

August 22, 2026 — testnet signer balances are no longer priced in dollars

No fiat figure on testnet — suspension and deletion emails for a KMS signer priced the address's balance using a live ETH/USD feed even on base-sepolia, so 0.0005 of free faucet ETH was rendered as $0.94 inside a warning that the funds would become permanently inaccessible. Testnet balances now render as 0.000500 ETH (base-sepolia testnet — no monetary value) and the oracle is not consulted at all.
The deletion warning still stands — the key is still destroyed and the address still becomes permanently unusable, so that half of the notice is unchanged; only the claim that something of value is lost is dropped. Mainnet emails are byte-identical.

August 18, 2026 — apex custom domains: one nameserver change, Run402 does the rest

Run402-hosted DNS zones — connecting an apex domain (example.com) no longer requires moving your DNS to your own Cloudflare account. Opt in with desired.authority: "hosted_dns_zone" and Run402 hosts the domain's zone: your only step is pointing the registrar's nameservers at the assigned pair; web serving, ownership verification, TLS, and in-zone records are applied automatically once delegation is observed.
Mail-safe by default — existing MX/TXT records are imported into the hosted zone verbatim before the nameserver change is recommended, and disclosed on the domain's hosted_zone.imported_records.
Disclosed, reversible custody — the domain aggregate reports dns_hosting: "run402_hosted" with the zone state and assigned nameservers; disconnecting tears the zone down with an explicit warning.
Canonical next_actions[] — ProjectDomain responses now use the platform-wide next_actions[] vocabulary (first entry = recommended); the singular next_action and alternate_actions remain as deprecated aliases until published clients migrate.
One custom-domain surface — the legacy standalone /domains/v1 routes are retired (a traffic scan showed zero real callers); everything lives on /projects/v1/:project_id/domains/:domain, and a web-enabled connect registers serving in the same call under both authority modes.
Zero PUT routes — the password route moved to POST and the last PUT was unmounted (also dropped from the CORS allow-list). The verb allowlist is empty, so “no PUT” is now enforced by CI rather than by review.
PUT aliases removed — the transitional PUT forms for the domain ensure and wallet label no longer route; POST is the only form, and the verb allowlist is down to one pending entry.
POST-canonical verbs, enforced — the domain ensure and wallet label move from PUT to POST, and a CI gate now fails any PUT route outside an explicit justified allowlist.
Keys-only domain management — a project's own admin-capable credential can manage that project's domains, no wallet or session needed.

August 10, 2026 — uploads stop double-counting against your storage quota

Your storage quota got its other half back — every upload holds a temporary reservation against your quota while it’s in flight, and the commit path was never letting go: each deploy’s full payload kept counting forever, on top of the real deduplicated content. Roughly a 1:1 shadow that quietly halved every organization’s usable storage. Commits now release the reservation the moment they land, and a cleanup reconciled 6.23 GiB of phantom reservations that had accumulated since April. Billing was never wrong — only the headroom number was lying, and it now tells the truth.

August 9, 2026 — a 401 names every credential it would have accepted

“Sign in” errors now list every way in, not just the first one we checked — a route that accepts either a wallet signature or a logged-in session answered an unauthenticated request with Missing SIGN-IN-WITH-X header, which reads as “a human must sign this with a wallet.” One agent read exactly that, decided the job belonged to its owner, and stopped — while holding a session the route would have taken. The error now names each accepted credential and how to get it.
You can finally rotate project credentials from the CLI and SDK — the endpoints existed and were documented, but nothing shipped that could call them. run402 credentials issue, list, status, rotate, revoke and token are now real commands, next to the existing local key cache under credentials project-keys.
run402 credentials status tells you whether you’re still on the old key — it needs no special permission, so a project can check its own posture. It lists what retirement is waiting on rather than a date, because there isn’t one to plan against.

August 8, 2026 — notifications name their subject

Your alerts say which project they’re about — a project-scoped notification used to lead with an opaque prj_1783064951883_0126. It now names the organization, the project, and the host it serves on, resolved fresh at delivery so a rename can never send a stale name.
Telegram messages link straight to the project — the console deep-link was dropped whenever the event didn’t happen to carry an organization id, which was most of them. It’s now there whenever we can resolve the owner.
The part of the message you needed is no longer the part that got cut — payload fields were ordered by how they happened to be stored and each value was capped at 120 characters inside a 4096-character message, which was enough to truncate an error notification at "db is not …. Fields now render in a deliberate order with a budget scaled to the message, and anything still omitted says so and points at the feed.

August 7, 2026 — invalid input answers 400, not 500

An invalid release spec is now your error, not ours — deploy plans whose spec was rejected by the release core (say, both functions.replace and functions.patch, or an unknown key in a route entry) returned 500 INTERNAL_ERROR, blaming the gateway for a bad request. They now return 400 INVALID_SPEC with a resource field naming the exact slice of the spec that was rejected.
Malformed JSON on the admin SQL route returns 400 — an unparseable body used to surface as an internal error. The 400 keeps the parser’s position detail so you can find the offending character, and never echoes your body back. A body that parses but isn’t an object now gets the same “No SQL provided” 400 as an empty one.

August 5, 2026 — human Buzz identity and clearer ownership records

Humans can connect a public Buzz identity from Account — the new browser flow uses the existing Run402 session, a fresh passkey, an explicit public-correlation disclosure, and Buzz’s already-released signed callback. The resulting link is public attribution, not a sign-in method or organization permission.
One completed handoff now names three separate records — the terminal consent receipt, public human identity link, and ordinary owner membership are returned and audited independently while the founder agent remains owner.
Disconnecting identity and removing authority are separate choices — revoking the public identity link leaves memberships unchanged; removing membership leaves the link and completed receipt intact. Principal merges preserve the original signed proof while reporting the surviving account’s effective control.

August 4, 2026 — traceable Buzz ownership handoffs

Support can see the exact last observed boundary — the latest offer-backed ownership attempt now carries a bounded sequence of browser and server stage codes, lifecycle timestamps, a deterministic diagnosis, and the last available gateway trace handle. This distinguishes Buzz-open, callback receipt, completion rejection or success, and expiry without screenshots.
The receipt is deliberately not a browser transcript — it stores no signed approval, event id, credential, email, identity/session id, browser/network metadata, URL fragment, or arbitrary text. Client milestones are observations only and cannot change authority.
Billing access now follows organization roles — balance and billing-history reads accept wallet or human control-plane login, then require an active billing-or-higher organization role. Billing-pool linkage no longer acts as permission, so revoking a member removes access immediately and authorized collaborators can read organizations beyond their wallet’s own pool.

August 1, 2026 — one-request Buzz onboarding

Fizz no longer stops after copying the skill — in managed Buzz, saying Please install the run402.com skill installs the inert files and continues through preflight, setup, and verified identity connection in the same turn. There is no “available next turn” response or second setup question.
Old Run402 clients update themselves before setup — v4.17.2 is the minimum trusted Buzz client because it first made a safe relay outage warning-only for founder setup. A missing or older agent-side CLI is upgraded and verified automatically, so the human is not sent to reconnect or restart Buzz based on stale client behavior.
The demo is the first approval — once connected, Fizz offers one relevant quick demo and waits. After a verified deployment, the separate web handoff can add the human as co-owner while Fizz remains the founder-agent owner.
Windows agents receive native install commands — the agent bootstrap now separates environment values from the installer command and provides PowerShell and cmd.exe forms instead of assuming Bash syntax.
Windows setup uses the managed Node runtime directly — Buzz capability checks accept the normal buzz.exe help spelling, while npm and Run402 run through their JavaScript entrypoints instead of command shims. A process-boundary failure is no longer mislabeled as a broken npm installation.

July 2026 and earlier are in the complete machine-readable history at /updates.txt.