# Kindgi 0.3.0 > What's new, fixed and changed in Kindgi 0.3.0, and the steps to upgrade to it from 0.2.0. Released October 30, 2026. For the docs of this version, see [docs.kindgi.com/v0.3.0](https://docs.kindgi.com/v0.3.0/). ## Security fixes - **Revoking an API key now always ends the console sessions it opened:** a session someone opened by signing in with an API key was ended when the key was revoked, but if ending it failed, the session went on. Now every request on such a session checks its key. Once the key is revoked or gone, the next request is refused with `401 auth-revoked`, "The API key this session was opened with is revoked: sign in again". If the key can't be read, the request fails: it never counts as a live key. Revoking a key that's already revoked ends any session it left ([Sessions](https://docs.kindgi.com/v0.5.0/guides/sso/sessions.md#signing-out)). - **A tenant id given in upper case is one tenant.** Before this release, `KINDGI_TENANT_ID` was kept as you gave it, while the database, a key and a console session hand the id back in lower case. Where the two met, a runtime whose id was set in upper case read its tenant as two. An identity provider registered through a key or the console wasn't offered for its domains, and GitHub and the emailed link weren't refused there, on a domain you verified too. When the deployment's API token changed, console sessions of the earlier token could stay signed in: with `KINDGI_SEED_USER_ID` keeping the user, they weren't ended, and during a rolling update a session opened through a replica still on the earlier token was accepted. A start stopped with providers registered in both spellings, or with `KINDGI_AUTH_VERIFIED_DOMAINS` naming the tenant by its id. A retention purge or an erasure of files kept with a run could stop, the deployment's API token couldn't read those files when a key wrote them, and a replay of the erasures didn't find the tenant. Each of these now compares the id in any case. An id in lower case, the usual form, was never affected. - **A database error no longer puts a query's SQL or its values in a run's failure, a fire's detail or a log line.** A database failure inside a flow's step, a schedule's dispatch, an eval run, the authorization queue or a background job could put the query's SQL and the values bound to it in the run's failure message, the fire's detail, the stored error or the log line. It now says what failed and its SQLSTATE, such as `invalid input for its type (22P02)`. Any other error keeps its own text, and a network failure says what it means first, such as `connection refused (connect ECONNREFUSED …)`. - **A read of the database that fails no longer weakens a check.** When such a read failed, a turn could run without a guardrail it couldn't read, a secret could be read from a wider scope than the one that named it, a webhook's new signing secret could be made over one that was there, and a delivery could be signed without the previous secret. Each of these now fails instead. - **A pausing pack tool's errors no longer keep its link's token.** A failing pack tool's error was cleared of the call's secrets and connection tokens, but not of the link a pausing tool is given, so an error that repeated the link or its token kept it in the tool's result, the run's events and the server's log. The token in the link is now cleared from the error too, and the rest of the link, the server's address, stays ([Wait for another system](https://docs.kindgi.com/v0.5.0/guides/tools/wait-for-another-system.md)). - **A file kept in the runtime never opens as a page of the runtime's own address.** A browser that opens an artifact's download saves it as a file, so nothing an uploader stored runs where the console is signed in. A stored type that isn't a well-formed media type is served as `application/octet-stream`; one with a line break in it made the download fail. - **An upper-case seed user id matches its memberships and roles.** Before this release, `KINDGI_SEED_USER_ID` was the only user id that could be in upper case, while memberships and the reviewer roster hand ids back in lower case. Where the two met, that person could, as a reviewer, approve their own requests where a second person's approval is required. They couldn't see or decide an approval addressed to them, and as the only reviewer they couldn't approve an Improve run's suggested change they had asked for. Their grants showed no projects, teams or reviewer role. Where a user id kept as given meets one read back in lower case, the two now match whatever the case. Removing a person whose id is in upper case, while a person with the same id in lower case exists, leaves that person the project and team memberships and the reviewer roster entry. With an authorization store, it also gives them each membership's role where they hold none on that project or team. The removal's audit entry names each one (`grantsGivenToTwin`). - **A stored file changed outside the runtime is no longer served as the one kept.** The runtime keeps each artifact's sha256 and size, and now checks the bytes against them as they're read. A download of a file that was changed or swapped in its store stops before the end, and the runtime logs an error, `Artifact 's stored bytes aren't the ones put; the read was stopped`, with the file's place in the store and both hashes, never its content. Files nobody changed download as before. ## New - **The console's project Dashboard shows the runtime's health as a button.** The **Kindgi Core** card's status is a button in its colour: **Running**, **Not answering**, **Can't reach its database** or **Unknown**. It opens what the status means and which runtime answers: its address, its version, whether it runs in development mode, and whether it serves one tenant or many. A line under it names the runtime and its version, such as `localhost:4000 · 0.3.0`. When the console is from another release, the line ends with the console's release, in the warning colour. - **`kindgi agents promote --wait` waits for the reviewer.** When the release gate policy asks for an approval, it names the approval and the command that approves it, then waits until a reviewer decides: an hour, or the time `--wait=30m` gives. It exits 0 once the version is pinned, and 3 when the approval is rejected or expires, when it's approved but something its check measured changed first (promote it again), or when the wait runs out. Ctrl-C stops the wait, not the request. `kindgi promote --make-live --wait` waits the same way for the versions a promotion carries ([Release an agent version](https://docs.kindgi.com/v0.5.0/guides/improve/release-an-agent-version.md#pin-through-the-release-gate)). - **Every pin that covers a project, in one read.** `GET /v1/projects//pinned-versions` lists every agent's pins that cover a project: the tenant's, the project's org's, the project's own and its segments'. It shows only the agents and versions you can read, so page on `nextCursor`, not on the count. In the TypeScript client it's `projects.pinnedVersions.list`, and in the Python client `projects.pinned_versions.list` ([Live versions reference](https://docs.kindgi.com/v0.5.0/guides/improve/pinned-versions-reference.md#every-pin-that-covers-a-project)). - **Flows and tools have pinned versions, as agents have live versions.** A pin says which version is in use in a project, an org or the whole tenant when nothing names one, so a new version can be published and tried without going into use where a pin covers. A run that names no flow version takes the version pinned for its project, else the newest the project reaches, and records which (`flowVersionVia`, `flowPinnedScope`). An agent or flow version made in a project a tool's pin covers locks that tool at the pinned version. The clients pin, move, unpin and read a pin's history (`flows.pinned`, `tools.pinned`), and a pinned version can't be unregistered: it answers `409 flow-version-pinned` or `409 tool-version-pinned`, naming the pins. `kindgi promote --make-live` also pins each flow version it carries in the target project, and prints them under "Flows pinned in". `kindgi exports create` writes each flow's and tool's pins and their changes ([Pin a flow's version](https://docs.kindgi.com/v0.5.0/guides/flows/pin-a-flow-version.md), [A pin holds a tool at a version](https://docs.kindgi.com/v0.5.0/guides/agents/agent-and-tool-versions.md#a-pin-holds-a-tool-at-a-version)). - **Each change to a trigger makes a version of it, and a run names the version it used.** Registering a schedule, webhook or mail trigger makes its version 1. A change that alters it makes the next, and so does a take-over to another owner; pausing, resuming or removing it makes none. A version never changes. A run uses the trigger's newest version when it starts and keeps it, so a change reaches the next run that starts, never one already going. `GET /v1/schedules/{triggerId}/versions` pages a schedule's versions, newest first, and `…/versions/{version}` reads one (`schedules.versions` and `getVersion` in the TypeScript client, `list_versions` and `get_version` in Python), and the same for `/v1/webhooks` and `/v1/mail-triggers`. A trigger, a fire and a run's `trigger` name their `version`. In the CLI, `kindgi schedules`, `kindgi webhooks` and `kindgi mail-triggers` take `versions ` and `get `, and `list --table` has a `VERSION` column. `kindgi exports create` writes each trigger's versions. A trigger from before 0.3.0 has its first version at its next change or its first fire. Its versions keep every input it has had, so a secret pasted into one stays in an earlier version after you edit it out: rotate it ([Run on a schedule](https://docs.kindgi.com/v0.5.0/guides/runs/run-on-a-schedule.md#its-versions)). - **The Cloud Run module's `upgrade.sh` upgrades every network shape.** It took a deployment with `network_mode = "none"` only, and one on a private network was upgraded by hand. Now a deployment of the module on runtime 0.1.8 or later, in any `network_mode`, can run it, to 0.2.0 or later: use it as of the `@kindgi/sdk@0.3.0` tag ([Cloud Run](https://docs.kindgi.com/v0.5.0/deploy/self-hosted/cloud-run.md#operate-it)). From 0.2.0, a deployment whose database has a private IP can't upgrade to 0.3.0 with it yet ([Known issues](https://docs.kindgi.com/v0.5.0/releases/0.3.0.md#known-issues)). - **An agent's model settings say how much its model thinks.** A model-settings block takes `thinking`, beside `temperature` and `maxOutputTokens`: `lowest` (as little as the model allows), `minimal`, `low`, `medium`, `high`, `xhigh` or `max`, and an improvement pass can try the levels its schema marks tunable. A provider's model lists the levels it takes in its `thinking`'s `levels`, and a `default` for a call that asks none. A level a model doesn't take goes up to the next one it takes, or to its highest, and the call warns `thinking-level-adjusted`. Each built-in adapter sends the level in its vendor's own field, and each model call's cost record says in `thinking` the level it asked for, the one sent, and the fields as they went out. The CLI's presets list each thinking model's levels: a provider registered from an older preset has none until you register it again. A runtime before 0.3.0 takes none, so there `kindgi providers register --preset` registers the models without them, and says so ([Temperature and thinking](https://docs.kindgi.com/v0.5.0/guides/models.md#temperature-and-thinking)). - **A guardrail can judge a tool call, its result or a model reply, not only the final answer.** Its `at` says where: `'before-tool'`, a call before it runs (after its access check, before any approval); `'after-tool'`, what a call returned, before the model sees it; or `'model-step'`, a reply that asks for tool calls, before any of them runs. There, `halt` fails the turn, and `retry` refuses the call, withholds its result or sends the reply back, counting attempts across the turn. A check names where it can run with `defineCheck({ points })`, `scope.tools` limits a guardrail at a tool point to the tools it names, and a call a `before-tool` guardrail judges waits for the calls before it. A check that can't run at its point fails as `check-point-unsupported`, or `check-timed-out` past its time limit. With `sees: 'conversation'`, a check also gets the conversation's earlier turns ([Where in the turn it runs](https://docs.kindgi.com/v0.5.0/guides/guardrails/configure-a-guardrail.md#where-in-the-turn-it-runs)). A guardrail a pack defines doesn't get all of this in this release ([Known issues](https://docs.kindgi.com/v0.5.0/releases/0.3.0.md#known-issues)). - **`GET /v1/runtime` says which runtime answers:** its release in `version`, such as `0.3.0`, whether it serves one tenant or many in `tenancy` (`single` or `multi`), and in `development` whether it runs in development mode. Any of the tenant's tokens reads it, whatever its rights. It's `runtime.get()` in the TypeScript client and `runtime.get` in Python ([Restart and check health](https://docs.kindgi.com/v0.5.0/deploy/self-hosted/restart-and-check-health.md#check-health-and-logs)). - **A flow run has a provenance record, as an agent turn has.** Once the run finishes, its record holds each step that ran, why it ran, the runs it started, and what the run's output came from: ids, kinds, statuses, times and codes, never a value. A very large run's record is cut from the middle and says what it left out. `GET /v1/provenance/{runId}` gives each step's model usage in `stepUsage`, and so does the signed export. `GET /v1/provenance?flowId=`, `kindgi provenance list --flow=` and the clients list one flow's runs' records. A finished run whose record isn't written yet answers `404 provenance-not-found`, and says whether it's being written or failed ([A flow's answers](https://docs.kindgi.com/v0.5.0/guides/observability/trace-an-answer.md#a-flows-answers)). A flow run that ended before the upgrade has no record. A person's erasure also reaches the records of the flows their runs ran in, and marks them erased. - **`GET /v1/identity/me/permissions` says whether the license is out of your reach:** `licenseOperatorOnly` is `true` when `GET /v1/license` refuses you whatever your role, as on a runtime serving many tenants. The console reads it, and no longer asks for the license only to be refused, which left a refusal in the tenant's access audit. The `license-operator-only` refusals now say why in plain words, without a setting's name ([People, API keys and service accounts](https://docs.kindgi.com/v0.5.0/deploy/people-and-keys.md#what-you-may-do)). ## Fixed - **A pnpm workspace pack's image no longer carries its dev dependencies:** a pack with build steps (`prisma()`'s `prisma generate`) installs its dev dependencies too, and prunes them after the steps. In a pnpm workspace, the prune left their folders in `node_modules/.pnpm`, where the pack couldn't load them but the image still carried them. Now they're dropped, on pnpm 9 to 12. Rebuild the pack's image with this CLI to leave them out; nothing else in the image changes. - **`upgrade.sh`'s way back names the CLI of the release you upgraded from:** when the new revision doesn't come up, the steps it prints to export the erasure ledger and replay it ran `npx @kindgi/cli@0.1`, whatever the release. Now they name that release's line, such as `@kindgi/cli@0.2` from 0.2.0. From a pre-release such as `0.3.0-rc.0`, npx finds no `@kindgi/cli@0.3` until 0.3.0 is out, so they say to name the CLI's own pre-release, `@kindgi/cli@0.3.0-rc.N`, whose number can differ from the runtime's (`npm view @kindgi/cli versions` lists them) ([Operate it](https://docs.kindgi.com/v0.5.0/deploy/self-hosted/cloud-run.md#operate-it)). - **Copying the runtime image says how long it can take:** the copy goes through the machine you run it on, every layer down and back up, and takes both platforms (amd64 and arm64), so on a slow uplink it can take most of an hour. `upgrade.sh` says so as it starts the copy, and in `--dry-run`, and so do the deployment pages ([Pull the runtime image](https://docs.kindgi.com/v0.5.0/deploy/self-hosted/pull-the-runtime-image.md)). - **A tool's error says why it failed:** a TypeScript tool whose `fetch` failed reported only `fetch failed`. The reason was in the error's cause, which no run showed. Now the message names up to three causes, as Node writes them: `fetch failed; caused by ConnectTimeoutError [UND_ERR_CONNECT_TIMEOUT]: Connect Timeout Error (attempted address: shop.acme.example:443, timeout: 10000ms)`. A refused connection names its addresses, and an error without a cause reads as it did. The message is masked, its causes included: a Kindgi token, and a URL's secret query or fragment value such as `?token=` or `X-Amz-Signature=`, become `[redacted]`, and the tool's own secrets and connection tokens are taken out first. The same holds for a check's `evaluate` and a pack file that fails to import. Rebuild the pack's image with this CLI to get it; a tool the server runs in its own process has it with this runtime ([When a call fails](https://docs.kindgi.com/v0.5.0/guides/tools/write-a-tool.md#when-a-call-fails)). - **A tenant id that isn't a uuid is refused with a message that names the setting.** `KINDGI_TENANT_ID`, `--tenant` or the config file's `tenant` must be a uuid ([Self-host](https://docs.kindgi.com/v0.5.0/deploy/self-hosted/self-host.md#3-build-sign-and-push-your-pack) makes one). Another id got past the settings check, then stopped the start at the runtime's first database write for the tenant, with a database error that named no setting. The runtime now refuses it as it reads its settings, before it connects to the database, and the message names the setting. The Cloud Run and Azure Container Apps modules refuse a `seed_tenant_id` or `seed_user_id` that isn't a uuid at plan. - **`kindgi artifacts download` writes the file only once the whole file has arrived.** It writes to a new file next to the one it saves, and moves it into place once the stream has ended and its sha256 is the one the server sent. Before, a download that stopped part way left a cut-off file under the name, nothing compared the sha256, and with `--force` the file already there was overwritten as the download began. Now a download that fails says the file wasn't written and leaves no file, and the file already there stays as it was. Without `--force`, a file that turns up under the name during the download is kept too. The `size` and `hash` it prints are those of the bytes written, and a name of `.` or `..` from the server gives the file the blob id. [Keep files with a run](https://docs.kindgi.com/v0.5.0/guides/runs/keep-files-with-a-run.md#find-and-download-them) says what an interrupted download can leave behind. - **One Ctrl-C stops `kindgi artifacts download`.** Before, the first Ctrl-C did nothing, and only a second one, a forced exit, stopped it, which could leave a half-written file behind. Now the first Ctrl-C, or `SIGTERM`, stops it, whether it's still waiting for the server or part way through the file. It leaves no file, the file already there stays as it was, and it says `kindgi artifacts download stopped: no file was written.` and exits with code 130. - **A write sent with an `Idempotency-Key` that can't be checked against its key no longer runs.** When the database that keeps the keys fails before such a write runs, the answer is `503 idempotency-store-unavailable` with `Retry-After: 5`. Before, it ran as if it had no key, so a repeat could run it again. Now nothing runs, so a retry with the same key is safe, and the Python client retries it on its own. When the write ran but its answer couldn't be kept, its answer stands, and a repeat within 30 seconds gets `409 idempotency-key-in-flight`, then runs again. Each such failure is now logged ([Retry a start safely](https://docs.kindgi.com/v0.5.0/guides/runs/retry-a-start-safely.md#how-it-works)). - **The system API's tenant reads answer `503` when the database is too busy.** `GET /v1/system/tenants` and `GET /v1/system/tenants/{tenantId}`, when the database's statement or lock timeout or the wait for one of the server's connections ended them, answered `500`. They now answer `503` ([`database-busy`](https://docs.kindgi.com/v0.5.0/reference/errors.md#database-busy)) with `Retry-After: 5`, as other reads do. - **A deploy that failed after publishing its tools no longer leaves its image undeployable.** Its rollback unregisters the tool versions it published, and a version number is used once, so the next deploy of the same image was refused with `400 validation-failed` until the pack was rebuilt under a new tool version. A deploy now reinstates an unregistered tool version its pack brings, as `kindgi tools reinstate` does, one its owner unregistered too. A rollback that can't undo one of its writes now logs a warning that names what it left as it was ([What unregistering a version does](https://docs.kindgi.com/v0.5.0/guides/agents/agent-and-tool-versions.md#what-unregistering-a-version-does)). - **The access audit no longer records some allowed requests twice.** Listing or creating a project's judging rules or sites, or the tenant's sign-in providers, listing a project's judging queue, and reading one agent, flow, tool, guardrail, eval suite or MCP endpoint each left two identical rows in the access audit when allowed. Each is checked, and recorded, once. - **A deploy refused because its pack's items belong to another project names a fix your runtime has.** `409 agent-project-mismatch`, and the `tool-`, `flow-`, `guardrail-` and `block-` ones, named a copy of the pack made with `kindgi init`, even where one pack service runs every deployment, the default, so a copy's code wouldn't run. There it now names an environment order: put both projects in one (`kindgi environments set`) and `kindgi promote` the build to the second. For projects in two orgs it names moving one, and on a runtime with neither, no fix ([A pack goes into one project](https://docs.kindgi.com/v0.5.0/concepts/projects-packs-values.md#a-pack-goes-into-one-project)). - **Each tool call in a model's reply has an id of its own.** The agent loop keeps what it decided for a call (its guardrails' verdicts, its approval, that it ran) by the call's id. When Gemini gave a call a null or empty id, or one an earlier call in the reply had, and when a compatible server sent a Chat Completions call like that, the Gemini and OpenAI-compatible adapters now make one, and send it back with the call and its result. - **`kindgi deploy --hosted` and `kindgi deployments get` say when they can't read where each value is set.** A read that failed printed nothing, as if nothing stood in the way. Now they print `Couldn't read where each value is set:` and why, such as the HTTP status and code. The deploy goes on, and `deployments get --json` is unchanged. - **The `sample` template says it has three tools.** `kindgi init --template=sample` makes `echo`, `greet` and `fetch-httpbin`, and `kindgi dev` loads all three, but the pack's README, `package.json` and `kindgi.config.ts` said two. - **The Python SDK's logger writes an error inside a field as it writes `err`:** its class's name, its message with known secret shapes masked, its code and its causes, without a stack. It was written as its text alone. A value that raises when it's read is written as `[unreadable]`, and never fails the log call. - **A flow's step whose read of the database failed is left for the run's next resume.** An agent step, a loop body's step or a fan-out's branch whose read failed failed the run. Now the step is left: its `step.retry-scheduled` entry says `left: true`, it runs again at the run's next resume and uses one of its `retry.maxAttempts`, and a step left 3 times fails as if it had thrown. A step left in a subflow's child run leaves the parent's subflow node too: the child run waits for its parent's next resume, shows as running, and ends when its parent ends. Resuming it directly is refused with [`run-held-by-parent`](https://docs.kindgi.com/v0.5.0/reference/errors.md#run-held-by-parent). - **A failed type fetch on a new database connection no longer ends the runtime.** When the database refused, reset or ended it, as in a failover or a restart, the request waiting on it now fails with the database's error, or runs once the connection connects again. - **A database that closes every connection while the runtime starts now fails the start.** It exits with code 1 after the connect timeout, its log saying `Can't connect to the database at : CONNECTION_CLOSED`, instead of reconnecting with no line and never finishing its start. - **A database restart or failover no longer leaves the migrations, their lock or the vector index build waiting for a connection.** Each takes a Postgres connection of its own. If the database ended a session while one waited, it now gets the connection the pool opens again. If every start of that connection is closed, it fails as a query does, at whichever comes first: its pool wait (`POOL_WAIT_TIMEOUT`; 10 s by default, `KINDGI_DB_POOL_WAIT_TIMEOUT_MS`) or the 30 s connect timeout (`CONNECTION_CLOSED`, also when there's no pool wait), and the pool stops opening connections for it. If the server refuses or resets that connection's type fetch, it fails with that error. When the runtime shuts down and the pool takes longer than its 5 s to close, what still waits fails with `CONNECTION_DESTROYED` instead of never settling. - **An MCP endpoint's tool sync no longer gives up when another replica syncs the same tool.** It failed after the lock wait, 30 seconds by default, and the endpoint stayed unsynced until it was registered again. Now it tries again for up to 15 minutes, and writes only for the endpoint's current registration. - **A `KINDGI_TENANT_ID` with an upper-case letter is read in lower case,** as the database, a key and a console session hand it back, so every part of the runtime reads one tenant. A person whose user record an earlier runtime made under the upper-case id signs in through the tenant's identity provider as that person. - **A file deleted from a Google Cloud Storage bucket that keeps old versions is now gone from all of them.** With `KINDGI_ARTIFACTS=gcs:[/]` on a bucket with Object Versioning, purging a deleted artifact under a retention policy, and purging a tenant, left the file's bytes in an old version. Both now delete every version of the file. The bucket's own soft delete still keeps a deleted version restorable for its window, as before. - **A tenant purge stays under its `gcs:` prefix.** With `KINDGI_ARTIFACTS=gcs:/`, a purge lists, deletes and counts only the files under `/`. Before, with the prefix `prod`, it also reached the same tenant's files under `prod-eu/`, as when two deployments share a bucket and a tenant id. - **A delete that the bucket's retention or a hold refuses says why.** The error names the file, the retention's end and each hold: `/ is locked by GCS: a retention until