Skip to content

Tale v0.5.73

Choose a tag to compare

View all tags
@github-actions github-actions released this 05 Oct 15:13
· 185 commits to main since this release
v0.5.73
c7810bd
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Highlights

  • Docker inside agent sandboxes starts on demand. The engine starts with the first Docker
    command, and health checks no longer wake it. It stops again after five minutes without clients
    when no container is running, restarting or paused and none has a restart policy. The next
    command restarts it with the same images, volumes and workspace. Agents need no setting for
    this.
    Sandbox infrastructure
    · #4173
  • Long agent runs recover faster and fail explicitly when they reach a limit. After a reconnect,
    a run resumes from durable checkpoints instead of replaying its whole history, and streamed
    output is updated incrementally. Session start, file staging and output replay have explicit
    time, memory and storage budgets; a run that exhausts one fails with a reason. Recovery visits
    unreachable runs in turn, so they no longer keep reachable runs waiting, and one slow direct-chat
    answer no longer holds the worker slots of answers that already finished. A failed sandbox
    create keeps the workspace's data for a retry. Operators can also opt new workspaces into a
    lighter profile without Docker and set Claude Code's reasoning effort (see the upgrade notes).
    #4176,
    #4177,
    #4200
  • Sandboxes clean up more safely. After repeated agent rotations, process cleanup keeps its hold
    until the last successor finishes and signals only process groups it still owns. A session on
    a connected device keeps its route when its creation overlaps a cleanup.
    #4324,
    #4277
  • Operators can keep project and agent instructions, standing-task descriptions and native
    automation definitions, deployments and schedules in reviewed source files and apply them with
    the Tale CLI. tale deploy --configuration-only applies such instruction and workflow changes
    without a snapshot, rollout or restart, once a full deployment of this release has completed.
    Configuration refuses to re-enable a disabled schedule or change one paused after failures, and
    it does not grant secrets, assign tasks, select models or change agent equipment. Upgrading
    changes no instructions or workflows by itself.
    Apply changes without a rollout
    · #4306
  • The authenticated backend metrics add
    tale_backend_automation_trigger_scan_last_success_timestamp_seconds, the database time of the
    last schedule scan that actually completed. An alert on it notices when scheduled automations
    stop being scanned while the API still answers. It reads zero without a verified completion in
    the last ten minutes, and it measures scanning, not whether each workflow succeeds. With backend
    tracing on, agent work also reports spans for acquiring the sandbox, gateway provisioning,
    staging, execution, persistence and harvest.
    Metrics
    · #4305,
    #4176
  • With SENTRY_DSN set, the sandbox service also reports its failures, such as failed requests
    and background tasks, through the backend's privacy filter. Browser, backend and sandbox events
    share one SENTRY_ENVIRONMENT label, which a managed deployment can now choose without being
    renamed.
    Choose where errors go
    · #4334
  • A project agent's updatedAt now advances with every change, including two saves in the same
    millisecond or a save after the server clock moved back. A conditional update with
    expectedUpdatedAt therefore refuses a stale save instead of overwriting newer configuration.
    #4333
  • A project's Environment tab shows a failed read of its secrets with Try again instead
    of an empty editor, so Save can no longer overwrite secrets the page could not read.
    #4317
  • Every password check inside the app now counts toward the same temporary lock as a failed
    sign-in: confirming the password for a passkey, turning two-factor on or off, creating backup
    codes, showing the authenticator secret and changing the password. Adding a passkey on a session
    signed in more than a day ago asks for the password first instead of failing with "Session is
    not fresh", and an account without a password is offered Sign in again. The two-factor
    password prompt is cleared when it closes, so a reopened prompt asks for the password again.
    Add a passkey
    · #4336,
    #4340,
    #4341,
    #4349
  • Authenticator entries can name the deployment they belong to. With TOTP_ENVIRONMENT=te, newly
    generated setup QR codes and links name the entry Tale <TE>; unset or pr keeps Tale.
    Showing the authenticator secret again now gives the same entry name as the original setup.
    Entries already saved in an authenticator app keep their names.
    Domain identity
    · #4355
  • Other screens that fail to load also say so and offer Try again, instead of showing zero,
    an empty list, editable defaults or an endless spinner. This covers your teams and passkeys in
    the account settings, the organization settings, Usage, Trash, the audit log's block
    counters, the Embedding settings, the governance policies, the legal hold pickers, the
    member list for data subject requests, a project's audience, a task agent's Details, the
    automation editor, automation metrics, and an automation run's details and agent transcript.
    Governance policy editors stay locked until their policy loads, a data subject request can't be
    filed until its member list loads, and automation metrics keep earlier figures, marked as
    possibly outdated, when a refresh fails. A project that fails to load keeps its header and tabs
    instead of saying that it may have been deleted.
    See your teams
    · #4296,
    #4300,
    #4272,
    #4314,
    #4287,
    #4292,
    #4302,
    #4275,
    #4294,
    #4288,
    #4304,
    #4278,
    #4344,
    #4343,
    #4345,
    #4354
  • Saving no longer loses work. Project agents and teams lock their fields until a save settles,
    a refused member edit keeps the dialog open with your changes, and the add-credential wizard
    holds Back while it saves. A refused API-key creation is reported and keeps its name and
    expiry for a retry. A skill save that lands after its dialog closed no longer replaces a later
    draft, and creating a blank skill under a taken name reports that it exists instead of
    overwriting it.
    #4256,
    #4286,
    #4293,
    #4269,
    #4267,
    #4299,
    #4255
  • Drafts survive what happens around them. The automation editor keeps edits made during
    Save anyway, and its trigger and project sections keep unsaved changes when another session
    saves. A Knowledge entry being edited keeps its draft when a newer version arrives and asks
    before discarding it. Compose keeps the chosen mailbox and sender when credentials fail to load
    and holds Send until they load, and an answer typed for one automation question never
    carries over to the next.
    #4313,
    #4321,
    #4337,
    #4332,
    #4338
  • Forms match what is saved. The Custom instructions editor counts to the 3,200 characters
    that saving allows instead of advertising 5,000, Edit member checks the name before saving,
    legal matter fields use the API's length limits, and a long automation name no longer yields a
    slug that saving refuses. Login policy delays keep fractions of a second, and a custom
    provider's model field shows the IDs that Save sends.
    #4297,
    #4237,
    #4310,
    #4279,
    #4261,
    #4315
  • Records show what is stored. In a workflow run with several agent steps, each step shows its own
    transcript, and an older step without a recorded execution shows none instead of another step's.
    AI events in the audit log keep their diagnostic metadata with secrets redacted, an unset
    product price or stock shows a dash instead of reading as free, an expanded feedback comment
    loads in full, and a task created as Done or Cancelled gets a completion time.
    #4239,
    #4244,
    #4274,
    #4298,
    #4249
  • Actions finish what they report. Deleting a task removes its whole subtree; tasks nested deeper
    than 32 levels used to survive, the first of them as a new top-level task. Removing the logo or
    a favicon in the branding settings deletes the stored image, and Add device completes only
    when the device enrolled with its own join command connects. A notification whose mark as read
    fails comes back instead of staying hidden. SharePoint offers only one-time imports; it used to
    offer Sync and report it completed although no sync was registered.
    #4226,
    #4271,
    #4257,
    #4309,
    #4199
  • Lists and search stay accurate. Contact search runs on the server and also matches phone
    numbers, and a sorted large contact list renders in a window that grows as you scroll. Website
    search clears its results when you edit the query, a stale response no longer replaces newer
    results, and the credential vendor filter can always be cleared. Products, Contacts and
    Knowledge entries offer bulk delete only to members with write access. Connectors that left the
    roster stay visible on an agent and can be removed, and a sandbox placement that cannot be read
    shows Unknown instead of the server.
    #4243,
    #4303,
    #4352,
    #4281,
    #4353,
    #4312,
    #4320
  • Chat and documents: a new chat that fails to start keeps its attachments, renaming a chat waits
    for an input method to finish composing, a refused rename keeps the typed title for a retry,
    and the document preview fits narrow screens.
    #4268,
    #4203,
    #4311,
    #4318
  • Accessibility: task cards describe their blocked state, review recipient and comment count to
    keyboard and screen-reader users, searchable select popovers have names, notification switches
    keep focus while saving, global search keeps its selection on a visible result when the scope
    narrows, the times on Home rows meet AA contrast, and dialogs block pointer input to the page
    behind them from their first frame.
    #4295,
    #4178,
    #4265,
    #4308,
    #4171,
    #4307
  • On the website, the comparisons with Flowise, Vellum and Vibe Kanban cite a primary source for
    each claim, show their review date and state each product's current status.
    #4335
  • For contributors, each of the seven validation workflows ends in a CI ready check. It passes
    only when every applicable job ran and succeeded, and it fails on a failure, cancellation,
    unexpected skip or missing scope. Merge groups run the full set.
    #4323

Upgrade notes

  • The backend applies database migration 0150 when it starts. It adds a nullable recovery-check
    time to project-agent and automation runs and two partial indexes, so recovery can visit runs in
    turn. The previous backend keeps working on the migrated database during a rolling deploy.
    Building the indexes reads both run tables once, which can lengthen the first start on an
    instance with a long run history.

  • Update the platform, the sandbox service and the sandbox runtime image together. Checkpoint
    recovery for long agent runs needs all three; with an older runtime, a run falls back to the
    previous recovery. During a rolling upgrade, keep old sandbox services on the runtime image
    they use until they are replaced, and don't move a runtime image tag that an old sandbox service
    still uses: it cannot tell a passing stall from a confirmed failure. A new sandbox service with
    an older runtime refuses new work on an unhealthy session and keeps its normal idle and lifetime
    cleanup. Checkpoints and active execs last only for the runtime’s lifetime: restarting it loses
    them while persistent workspace files remain. Preserve valuable work before restarting sessions.

  • Sandbox behavior that changes without configuration:

    • A session now waits at most 5 seconds for shared build-cache setup, instead of 15, or a
      quarter of its startup budget if that is shorter, before it uses its local builder.
      SANDBOX_BUILDKITD_PROVISION_TIMEOUT_MS (100–60000) changes the wait.
    • An organization's build-cache helper runs as many build steps at once as its whole CPUs
      allow, instead of four. Its CPU limit, SANDBOX_BUILDKITD_CPUS, defaults to
      SANDBOX_AGENT_CPUS, which is 2. The bound applies when an idle helper is recreated;
      SANDBOX_BUILDKITD_CPUS=4 restores four steps and raises the helper's CPU limit to four.
    • SANDBOX_SESSION_CREATE_TIMEOUT_MS (180 seconds by default) bounds every step of a session
      start on Docker and Kubernetes, build-cache setup included. A cancelled request stops its
      session start and keeps the workspace.
    • Resuming a released warm session passes the same memory and disk admission as a new one, so
      it can wait for capacity.
    • On Kubernetes, session Pods get a startup probe on /readyz and a liveness probe on
      /livez. Kubernetes restarts a session daemon that stops answering, even when its session is
      pinned; Docker or egress failures alone don't restart it.

  • With SENTRY_DSN set, sandbox failures also appear in your reporting project after the
    upgrade; the sandbox service sends errors only, never traces. The optional SENTRY_ENVIRONMENT
    labels browser, backend and sandbox events. A managed deployment still defaults it to its
    retained name and now keeps a label declared as an environment reference in its specification
    instead of replacing it. Set the referenced variable at the destination: tale deploy refuses a
    missing required reference before it changes the stack.
    Choose the error reporting environment

  • A wrong password in an in-app check now writes a login_attempt audit row stamped
    metadata.passwordCheck, which names the check; sign-in rows stay unstamped. Filter on that
    stamp if you count sign-in attempts from the audit log. While an account is locked, these checks
    refuse until the lock expires, and the password change form says how long that is.

  • Optional environment variables, documented in the
    environment reference,
    change nothing until you set them:

    • SANDBOX_AGENT_PROFILE, read by the backend API and worker. agent-light gives new agent and
      workflow workspaces their coding tools and a persistent workspace without Docker or
      build-cache helpers. Existing workspaces keep their profile.
    • TALE_SANDBOX_CLAUDE_EFFORT, read by the backend API and worker, sets Claude Code's reasoning
      effort to low, medium, high or max. Unset keeps the harness default. Compare
      representative tasks before lowering it; shorter runs are not guaranteed.
    • SANDBOX_DOCKER_DATA_ROOT and SANDBOX_DOCKER_DATA_PATH give the sandbox service a read-only
      mount of Docker's data root, so disk admission checks that filesystem too. tale deploy adds
      the mount; a raw Compose file needs the override shown in the reference. A configured mount
      that cannot be read or verified blocks new and resumed sessions.

    The repository's compose.yml and tale deploy pass the two backend variables to the backend
    API and worker; a hand-written Compose file or manifest must pass them as well. Recreate both
    services after changing them.

  • TOTP_ENVIRONMENT is a new optional backend variable for the name of newly generated
    authenticator entries: te gives Tale <TE>, other labels of 1–32 characters must start with a letter or digit and
    contain only letters, digits, _ or -. They are uppercased, and pr or unset keeps Tale. Leave it unset rather than empty: an empty or
    invalid value stops the backend from starting. It rotates no secret and renames no entry already
    saved in an authenticator app.
    Domain identity

  • tale deploy --configuration-only needs the receipt of a completed full deployment made with
    this release's CLI and platform. A deployment whose receipt predates this capability must
    complete one normal deployment first, and a refused configuration-only apply never falls back to
    a full deployment.

  • Enable an alert on the schedule-scan metric only after this release is deployed and its
    timestamp is seen advancing. Treat a missing series or a timestamp well in the future as
    unhealthy.

  • Known limitation: the app's project-agent editor does not yet send the revision it opened with,
    so saving it can still overwrite a change made after it opened, including instructions applied
    through configuration (#3598).

  • The API contract stays at 3.15.0.

API contract changes

None in this range. The contract stays at 3.15.0: 139 operations.

What's Changed

Full Changelog: v0.5.72...v0.5.73

Contributors

larryro and yannickmonney
Assets 8
Loading