Skip to content

Tale v0.5.88

Choose a tag to compare

@github-actions github-actions released this 13 Oct 12:29
18edad5

Highlights

  • A coding agent's sign-in now ends when it can no longer be trusted. A refresh token used a second time disconnects that app everywhere the person connected it. A changed or admin-set password, a removed passkey or a reset two-factor sign-in disconnects every agent the person connected, in every organization; the audit log names the act as the platform's, or as the admin's when an admin did it. An erasure deletes the person's connections in that organization and keeps only audit rows that have lost their personal data, and the erasure result counts Coding agent connections among the categories it removed. Coding-agent sign-in stays off unless an operator turns it on, so nothing changes for a deployment until then.
  • A person is told why an agent of theirs stopped working. When something other than themselves disconnects an agent they connected (a reused refresh token, a changed sign-in method, or an owner's or admin's disconnect, which names them), they get a notice in their bell, in the organization the connection was to, in English, German or French. It is never e-mailed, cannot be muted and is not shown to admins; their own disconnects and a seat that ended tell nothing.
  • Old coding-agent connections and unused apps are cleaned up every day. A connection that ended is removed 90 days later, an app that registered and was never connected a day after it appeared, and tokens a month after they expired or were retired. An app with a live connection and an organization's own sign-in application stay.
  • The screen where a coding agent asks to connect. The person sees who is asking, with a Verified domain or Unverified app badge and where the browser goes back to; chooses the organization (those they may not use stay listed with the reason) and how much the agent may do (read and test, edit automations, edit and deploy, and on top of those reading and changing settings and connecting AI subscriptions); and sees what that comes to. The server judges the choice again when they connect, and a sign-in older than a day asks for the password before more than reading is granted. It builds on two design-system components, ConnectionIdentity and PermissionSummary, and on a data route, and it appears only where an operator turns coding-agent sign-in on.
  • Full releases admit one new service and CLI cohort per UTC day. Retrying the same published tag for recovery remains allowed, and sites-only builds keep their existing scope.

Upgrade notes

  • From v0.5.87 to v0.5.88 no database migration, configuration change or manual step is needed, and the API contract stays at 3.43.0. The backend schedules one new daily sweep, maintenance.agent_connections_gc; it removes only the agent-connection records described above, and a deployment that never enabled coding-agent sign-in has none.
  • Where an operator has turned coding-agent sign-in on, a password change, a removed passkey or a two-factor reset now also disconnects the person's agents. Tell members to connect them again afterwards.
  • Upgrading from v0.5.86 or earlier also applies two migrations that the v0.5.87 notes leave out, 0203_agent_connections.sql and 0203_auth_factor_authorities.sql. Both only add tables and their indexes, and the previous image is safe to keep serving while they apply.
  • Since v0.5.87 a session that a trusted-header proxy or single sign-on opened for one organization can use only that organization; its other organizations answer ORG_FORBIDDEN, which the dashboard currently words as "not a member" (#4908). The new operator setting TALE_ORG_SESSION_CUTOVER_AT is for a second rollout, once every old writer has retired: leave it empty until then, and when you set it, give an exact UTC timestamp with milliseconds that has already passed (for example 2026-10-14T00:00:00.000Z), because the backend refuses to start on any other value.
  • Known limitation since v0.5.87: signing in on a browser that still holds another person's valid session is refused with ORG_FORBIDDEN, and the sign-in page words it as a wrong password. Sign out of the other account first (#4919).
  • This corrects an upgrade note of v0.5.87: the release workflow admits at most one new full cohort per UTC day. Adopt the service images and CLI of each version as one validated cohort, as before; recovery of a published tag is unchanged. Releasing Tale has the procedure.

API contract changes

None in this range. The contract stays at 3.43.0: 161 operations.

What's Changed

Full Changelog: v0.5.87...v0.5.88