Changelog

2026-07-20

• Commands that print a lot of output over SSH no longer return corrupted data. Running something like tektona ssh <sandbox> -- cat bigfile silently lost chunks from the middle of the output once it grew past a couple of megabytes, and the command still reported success — so a redirected file looked complete but held misaligned bytes, and a 4 MB read could come back missing a megabyte. The sandbox now slows the command down when output arrives faster than it can be sent instead of discarding it, so what you receive matches what the command produced. This also fixes large files failing to sync out of a tektona mount.
• Two mounts can no longer be created under the same name at once. Starting several tektona mount --name X at the same moment let all of them through — each checked for a clash before any had been recorded — leaving mounts that shared one name and could not be unmounted individually. Mounts are now admitted one at a time, so only the first takes the name. If you already have duplicates, tektona unmount now shows which local directory each one syncs instead of repeating the same name once per mount.
• A mount daemon left wedged no longer blocks every later start. A daemon that stalled while shutting down stayed alive holding the lock that allows one daemon at a time, so starting a new one silently did nothing and mounts kept failing with no cause given — the config directory looked permanently broken. Such a daemon now exits instead of lingering, a start that finds one is told what is in the way, and unmounting a stuck mount reports it if the daemon could not be brought back afterwards rather than leaving the other mounts stopped in silence.
• Large downloads through a forwarded port no longer arrive corrupted. Pulling a big file through tektona sandbox port-forward could silently lose data once the sandbox sent faster than the local client read — a 64 MB download arrived as 11 MB of misaligned bytes with no error anywhere. The gateway now absorbs far larger bursts, and if it ever still has to drop data it closes the connection instead of handing over a corrupted stream. tektona sandbox cp gets the same protection.
• Mounted files keep their group and other permissions. Files and directories synced by tektona mount no longer lose every permission bit below owner in either direction — a 0644 file arrived as 0600 and a 0755 directory as 0700, so anything in the sandbox not running as the file's owner could not read them, and a page served from a mounted directory came back "403 Forbidden" through a preview URL. Synced files now arrive as 0644 (or 0755 when executable) and directories as 0755.
• Mounts now tell you when a file could not be synced. Some paths can't cross between a sandbox and your machine — two filenames differing only in case can't both exist on macOS or Windows, and symbolic links pointing outside the mount are refused. Previously these were skipped in silence, so a file simply never appeared and nothing said why. tektona mount now warns after the initial sync, tektona mount ls shows a PROBLEMS count, and tektona mount ls -o json lists each skipped path with the reason.
• The CLI now ships its third-party license notices. Every release archive and npm package includes a THIRD_PARTY_NOTICES.txt listing the copyright and permission notices of the open-source software compiled into the tektona binary. Homebrew installs place it alongside the binary in the Caskroom.
• Large files written inside a sandbox now sync back to a mount. Writing a file bigger than a few megabytes inside a mounted directory could silently break the mount: the file never arrived locally, tektona mount ls showed the session stuck disconnected, and it stayed that way until you unmounted and mounted again. Bulk transfers out of a sandbox now come through intact, and in the rare case the connection can't keep up the session fails and reconnects instead of hanging.
• A stalled mount no longer blames the wrong thing. When tektona mount flush gave up on a mount that had stopped syncing, it told you the sandbox was likely paused or deleted and suggested unmounting — even when the sandbox was running and healthy and the real problem was the sync connection. The message now names both possibilities and points at tektona mount ls and tektona sandbox show so you can tell which one you have.
• A mounted sandbox now stays paused. Pausing a sandbox with an active tektona mount woke it again within a second — the mount reconnected and the reconnection itself resumed the sandbox, so a mounted sandbox could never stay paused and a forgotten mount kept one running indefinitely. A mount's connection no longer resumes anything; it retries quietly until the sandbox is running again, then syncs whatever changed in the meantime. Connecting with tektona ssh still resumes a paused sandbox as before.
• SSH connections to a sandbox now end when the sandbox pauses. Previously a session stayed open and looked healthy after its sandbox was paused or stopped, so clients waited indefinitely on a connection that could no longer reach anything — file syncs in particular could stop propagating changes without reporting a problem. Such connections are now closed as soon as the sandbox is no longer running, so clients notice immediately and reconnect on their own once it resumes.
• Your account now has a username and a public profile. Every user gets a unique, case-insensitive handle (lowercase letters, numbers, and hyphens, up to 39 characters). Existing accounts were assigned one derived from their email address, and you can change it at any time. You can also set a display name, bio, company, website, and social links.
• Upload a profile picture. Add a PNG, JPEG, WebP, or GIF (up to 5 MB) to your account, or remove it again.

2026-07-13

• DNS-over-HTTPS is now also blocked over HTTP/3. Blocking well-known public DoH resolvers previously only covered HTTPS, so a client that spoke DNS-over-HTTP/3 could still bypass the DNS path the platform inspects. Those resolvers are now blocked on HTTP/3 too, and clients fall back to the standard DNS path automatically. As before, you can use a specific DoH resolver by adding its exact host to your egress network policy's allow list.

2026-07-11

• Sandbox disk size is now honored on every image. The writable filesystem inside a sandbox now grows to fill the disk you request, regardless of the base image. Previously, images without resize2fs built in (many minimal images such as Alpine, distroless, and -slim variants) silently kept only their built-in filesystem size — often tens of megabytes — so --disk had no effect and large writes failed with "no space left on device". The rootfs is now grown in-process at boot, so the space you asked for is actually available.
• Resizing CPU or memory no longer breaks resume. A CPU/memory resize now applies on the sandbox's next reboot instead of its next resume. Previously, resizing memory (or CPU) and then hibernating and resuming could leave the sandbox in an error state, because the saved memory image is bound to the size it was captured at. Resume now restores the sandbox at its captured size, and the resize takes effect the next time you reboot it. Disk growth is unchanged.
• HTTP/3 now works through the egress domain filter. Outbound QUIC / HTTP-3 (UDP port 443) to an allowed domain is now inspected and permitted instead of being blocked — the gateway reads the server name from the connection's first packet and applies your sandbox's egress policy, so allowed domains work over HTTP/3 while denied and uninspectable traffic is still dropped.
• DNS-over-HTTPS is blocked by default so egress policies stay effective. Sandboxes no longer resolve names through well-known public DoH resolvers (e.g. Google, Cloudflare, Quad9) by default; those endpoints are blocked so DNS falls back to the standard resolver the platform inspects. This keeps allowed domains reachable on non-HTTP ports and keeps egress filtering consistent. To use a specific DoH resolver, add its exact host to your egress network policy's allow list. Plain HTTPS to those providers' other services is unaffected.
• SSH and VNC access now shrugs off connection floods. The access gateway rate-limits repeated connection attempts and failed authentications per client address, so port scanners and floods can't degrade sandbox access. Normal usage — even many parallel SSH sessions and port forwards — is unaffected.
• Attaching or detaching a sandbox's egress proxy profile now confirms the change is active before succeeding. tektona sandbox egress-proxy set/unset report an error if the change was saved but couldn't be confirmed on the sandbox's node (it still applies automatically once the node is reachable — retry to confirm); paused sandboxes must be resumed first, and detaching when no profile is attached now says so instead of silently succeeding.
• Detaching an egress proxy profile now cuts the injected credential off immediately. Previously, after detaching (or switching) a profile on a running sandbox, an already-cached credential could keep being injected for up to a minute. Detach and switch now evict the cached values right away, so attach, switch, and detach all take effect on new connections within about a second.
• The first agent message on a fresh sandbox now answers in seconds instead of ~90. The agent server accepts connections a moment before it can respond, and a readiness check that landed in that gap silently stalled the whole first message. Each check is now individually bounded, so the first message goes through as soon as the agent is up.
• Attach or switch an egress proxy profile on an existing sandbox. tektona sandbox egress-proxy set <sandbox-id> <profile> attaches a profile (or replaces the current one) and unset detaches it — no recreate needed, and a running sandbox picks the change up within seconds.
• Sandbox reboot no longer fails for sandboxes created before the latest platform update. Rebooting (or resetting) such a sandbox could fail and leave it in an error state; the reboot now comes up with the platform's current agent, like a resume does.
• The coding agent works again after a sandbox reboot. Previously, after tektona sandbox reboot (or reset) the sandbox's agent never reconnected, so agent messages failed until the sandbox was recreated. The agent now comes back automatically within seconds of the reboot completing.
• First message to a freshly created sandbox no longer fails while the agent finishes initializing. Previously, the very first agent message could error if the agent's one-time startup took long, and only a retry went through. The message now waits for the agent to come up and is delivered on the first attempt.
• Egress proxy rule changes now apply to running sandboxes immediately. Adding, updating, or deleting an injection rule on an egress proxy profile now reaches every running sandbox attached to that profile within a second or two, instead of relying on a periodic refresh — no restart needed.
• Multiple egress proxy rules for the same host now all apply. Previously, when several rules targeted one host (e.g. an API key from one rule and a tenant header from another), only one rule took effect and the others were silently ignored. All matching rules now inject together; if two rules set the same header, the more specific rule wins and a warning is logged.
• Agent event streams now include tool results. Subscribers to a sandbox's agent event stream previously saw each tool call but never its outcome; a tool_result event now follows every tool_call, carrying the tool's output or error.
• Remove egress proxy rules from the CLI. tektona egress-proxy rule rm <profile> <rule-id> removes an injection rule from a profile, and tektona egress-proxy show now lists each rule's id so you can find the one to remove.

2026-07-10

• The first preview request to a paused sandbox no longer stalls. In some situations — when the preview had served traffic shortly before the sandbox paused — the first request after the pause could hang for about 30 seconds and fail instead of waking the sandbox, and only a second attempt would load. The first request now wakes the sandbox and serves promptly.
• Full-mode forks are now reachable from outside right away. A sandbox forked with --mode full kept the parent's network address in its restored memory, so its preview URLs and forwarded ports returned 502 until a reboot — even though the preserved processes were running fine. The fork now comes up with its own address and its previews work immediately.
• Long commands over tektona ssh <id> -- <command> no longer disconnect after 5 minutes. In some situations, a one-shot exec session could be closed about 5 minutes after the client's stdin closed, cutting off a command — such as a long build or test run — still running at that point. The session now stays open until the command actually finishes.
• New repositories default their branch to main. Registering a repository without specifying a default branch now stores main instead of a blank branch, so the CLI and API show a real branch. Pass --default-branch (CLI) or default_branch (API) to choose another.
• Register project repositories from the CLI. The new tektona repository command (alias repo) lists, adds, shows, and removes the git repositories a credential can unlock — e.g. tektona repository create --url https://gitlab.com/group/app. Previously this was only possible in the console or the SDK, so tektona git-credential create --repo … had no CLI way to register the repo it referenced.
• Secret injection and outbound HTTP(S) now work immediately after a sandbox starts. Previously, the first web requests from a freshly created or resumed sandbox — including requests relying on egress secret injection or git credentials — could fail for a few seconds until the network configuration caught up, forcing a wait-and-retry. The configuration is now in place before the sandbox is reported running.
• process run --shell runs shell one-liners. tektona sandbox process run -s <id> -- 'apt update && apt install -y nginx' runs the command line through a shell inside the sandbox (bash when the image has it, sh otherwise), so &&, pipes, and globs work. Without the flag, the command remains an exact argument vector.
• More reliable hibernate and resume. In some situations, resuming a hibernated sandbox could lose its in-memory state; resume now reliably restores the sandbox exactly as it was paused.
• More reliable full forks. In some situations, a full fork (disk + memory) could start without the source's in-memory state. During a full fork, connections into the source sandbox (shells, agent sessions) drop briefly and reconnect within a couple of seconds.
• Better handling of failed pauses. In some situations, a failed pause could show the sandbox as paused or hold up later pauses; a failing pause now leaves the sandbox running and is retried on the next idle check.

2026-07-09

• tektona ssh into a sleeping sandbox now wakes it for you. Running tektona ssh <id> against a paused sandbox shows a Resuming sandbox… indicator while it wakes and connects once it's ready, even if waking takes a little while.
• process ls --autostart shows an accurate last-run state. Each autostart process now reflects its most recent run — never before it has started, then its real outcome once it finishes — instead of staying stuck on running.

2026-07-08

• Refinements to sandbox process management. Following the launch, process ls now shows only running processes by default (newest first), with an AUTOSTART column marking autostart-managed processes and -a/--all to include finished ones; long commands are truncated to keep the table readable. process get and process logs keep working by name after a process finishes, and process stop reports already finished for a process that has ended rather than claiming to stop it. process run now returns a non-zero exit code when a command is killed or times out, so scripts and CI can tell it didn't finish cleanly. Process listings expose each running process's pid over the API and SDK, and process commands against a deleted sandbox now return a clear sandbox <id> not found.
• tektona ssh <id> -- <command> keeps stderr separate from stdout. Command output over SSH now delivers stderr on its own stream, so 2>/dev/null and piping stdout alone behave as expected. Interactive shells are unchanged.
• tektona sandbox delete lists multiple sandboxes one per line. The delete confirmation now prints each sandbox on its own line so you can review what's about to be deleted.
• More reliable sandbox and process operations during platform updates. Creating, deleting, or managing a sandbox — and running process commands — could occasionally fail while the platform was being updated. These operations now retry automatically and succeed once the update settles.

2026-07-06

• Run, stream, and manage processes inside a sandbox. Start one-off commands, background servers, and interactive shells from the CLI (tektona sandbox process), the HTTP API, the TypeScript SDK, or in-sandbox with tektonactl process. Processes belong to the sandbox — they survive disconnects and are addressable by id or a memorable name (auto-generated, like quantum-phoenix, when you don't set one) — with live log tailing, attach/reattach, graceful stop and signals, autostart on every boot, and per-process control over pause behavior and keeping the sandbox awake.

2026-07-05

• API responses now include rate-limit headers. Requests are rate limited per user/API key — and per client IP before authentication — with generous defaults that normal CLI, SDK, and automation traffic stays under, plus a separate tighter budget for sandbox creation. Each response carries X-RateLimit-Limit-{throttler}, X-RateLimit-Remaining-{throttler}, and X-RateLimit-Reset-{throttler} (throttler = general, sandbox-create, or ip) describing your current budget. Exceeding a limit returns 429 Too Many Requests with a Retry-After header; the TypeScript SDK's RateLimitError now exposes throttler, limit, remaining, and resetSeconds.
• The CLI tells you when you hit a rate limit and retries for you. When the API throttles a request, tektona prints a notice with the server-suggested wait, then retries automatically after it (a few attempts). If the requested wait is long, the command fails right away with the time to retry instead of hanging.

2026-07-04

• Stored secrets are now cryptographically bound to their identity. Encrypted secrets, git credentials, and registry credentials are now sealed so a stored value cannot be moved between records and still decrypt. Existing data is preserved: values written before this change keep working, and an operator runs a one-time envelope migration during a maintenance window to upgrade them in place — no need to re-create any secret, credential, or project CA.

2026-07-04

• Private preview URLs no longer leak their access token via the browser Referer. Responses served over a token-bearing preview URL now send Referrer-Policy: no-referrer, so cross-origin requests made by the previewed page don't carry the token-containing hostname to third-party hosts.

2026-07-03

• Resuming a sandbox right after pausing it is now reliable. Waking a sandbox during the brief window when its paused state is still uploading no longer leaves it stuck or flipped to an error state, and later actions like reboot keep working.
• Reboot is now orderly and no longer loses recently written files. tektona sandbox reboot now shuts the guest's processes down (SIGTERM, then SIGKILL) and flushes the filesystem before restarting the VM, so files written shortly before the reboot survive it; if the guest is unresponsive it falls back to a hard reset. A new tektona sandbox reset performs an unconditional hard reset (like pulling the power) for an unresponsive sandbox — un-synced files may be lost.
• Deleting a project now works once its sandboxes are gone, and keeps usage history. A project can be deleted after all of its sandboxes are deleted; sandboxes that still exist — running or paused — must be deleted first. Deletion now preserves the project's past sandbox usage for billing history instead of erasing it, and the project's name becomes available for reuse.
• Lifecycle settings can be set on tektona sandbox create. Pass --auto-pause, --auto-pause-mode, --auto-resume, or --auto-delete at create time instead of creating first and running sandbox lifecycle; any you omit inherit the project/platform default.
• Slimmer tektona sandbox ls output. The egress proxy profile column moved to the --wide view to keep the default listing narrow.
• Sandboxes now auto-pause after 15 minutes idle by default. New sandboxes hibernate after 15 minutes with no activity and auto-resume on the next access. Compute billing stops at the idle deadline even if the pause itself lands a little later. Change or disable it per sandbox or per project.
• Auto-delete is available as an opt-in retention window. Off by default — paused sandboxes are kept until you delete them. Set an auto-delete window per sandbox or per project to delete a paused sandbox that long after it was paused.
• Lifecycle settings are now three-tier. Auto-pause, pause mode, auto-resume, and auto-delete resolve from a per-sandbox override, then the project default, then the platform default — each set to a value, never, or inherit. Manage them in the console, API, or CLI: tektona sandbox get shows the effective values and which tier supplied each, tektona sandbox lifecycle sets a sandbox's own overrides, and the new tektona project lifecycle-defaults sets project-wide defaults.
• Paused sandboxes wake on any access. Opening an SSH or VNC session, loading a preview URL, or sending an agent request to a paused sandbox now resumes it automatically — previously only SSH and VNC woke it.
• Auto-pause no longer pauses sandboxes that are in use. Sandboxes now detect activity from live SSH, VNC, and terminal sessions, traffic to preview ports, agent activity, and outbound transfers, so the idle timer only counts genuinely idle time.
• tektona sandbox get shows a clearer, fuller picture. Details are now grouped into sections (Network, Lifecycle, History) with the egress network policy and egress proxy profile always shown, the idle-lifecycle settings (auto-pause, auto-pause mode, auto-resume, auto-destroy), your sharing level and access, and — new — the last 50 state transitions. Use --history=N to change how many to show or --no-history to hide them.
• tektona sandbox create now shows the egress network policy and egress proxy profile in its create summary.
• API: the single-sandbox endpoint now returns project, sharing, and access. GET /v1/sandboxes/{id} now includes the sandbox's project, share_type, and your access level, matching what the list endpoint already returned. The project object (on get and list) also now carries the project's name (URL-safe identifier) and display_name; its slug field still returns the identifier but is deprecated — read name instead.

2026-07-02

• New desktop and base image release (0.4.3). Installing a service with apt (e.g. nginx) now starts it automatically, just like on a regular Ubuntu machine — previously it stayed stopped with a policy-rc.d returned 101 notice until started by hand. Use it with tektona sandbox create -i ghcr.io/tektona-ai/desktop-x11:0.4.3.
• Faster sandbox starts. Desktop-image sandboxes boot roughly twice as fast, and the first start from an image that isn't cached yet completes much sooner.
• More reliable sandbox creation. Creates no longer occasionally stall for 30 seconds or fail spuriously during rapid create-and-delete bursts.
• @tektona/sdk 0.3.0 — org/project sandbox settings moved (breaking). The default-sandbox-settings methods now live on the resource they configure: tek.org.getSandboxSettings() / updateSandboxSettings() and tek.project.getSandboxSettings() / updateSandboxSettings(). They were previously on tek.sandbox (getOrgSettings/updateOrgSettings/getProjectSettings/updateProjectSettings) — update those call sites.

2026-07-01

• New desktop and base image release (0.4.2). Fixes the bundled installations of the Codex, opencode, and Claude AI coding agents so they run out of the box. Use it with tektona sandbox create -i ghcr.io/tektona-ai/desktop-x11:0.4.2.
• Fixed sandbox create --env variables not being applied in some cases. Environment variables set at create time are now reliably available in the sandbox's shells.
• @tektona/sdk 0.2.1 — the package now allows importing @tektona/sdk/package.json, so tools that read the package manifest (e.g. for the version) work again.
• The TypeScript SDK (@tektona/sdk 0.2.0) now covers the full public API. Every resource is reachable from one client — sandboxes, secrets, projects, organizations, container registries, git repositories, git credentials, egress network policies, and locations — with create/list/get/update/delete where the API supports them. Highlights:
  • Set a default org/project once on the client (new Tektona({ org, project })) and override per call.
  • Every list() is cursor-paginated and returns a Page; listAll() auto-pages the whole set.
  • Full sandbox control — pause/resume/reboot/fork/resize, sharing & transfer, idle-lifecycle config, listening ports, transitions, and egress injection rules — with grouped sub-namespaces (sandbox.ssh, sandbox.vnc, sandbox.desktop, sandbox.preview).
  • Typed, instanceof-friendly errors.

2026-06-30

• TypeScript SDK groundwork for full API coverage. @tektona/sdk now exposes a service per API resource off the client, supports a client-level default org/project scope (overridable per call), cursor pagination on every list() (plus a listAll() async iterator), and a richer typed error hierarchy (ApiError with statusCode; AuthenticationError 401 and AuthorizationError 403 are now distinct). New calls: sandbox.list/get/delete and location.list.
• Manage organizations and projects from the CLI with tektona org and tektona project — list, show, create, and update orgs and projects, with an interactive wizard on a terminal or a fully scriptable flag-only path for agents and CI. Updating edits the display name and settings; the name is fixed once created.
• get is the canonical verb for reading a single resource — tektona org get, tektona project get, tektona sandbox get, and tektonactl get (kubectl-style). The previous show/info names keep working as aliases, so existing commands and scripts are unaffected.

2026-06-29

• One reference grammar for egress network policies and egress proxy profiles. Both --egress-network-policy and --egress-proxy-profile now use the same scope-keyword prefixes: tektona/<name> (system), org/<name> (organization), project/<name> (project), and a bare <name> as a strict alias for project/<name>. Breaking: a bare name now always means the project scope — previously a bare network-policy name resolved to the org and the project keyword was org/project/<name>. Existing sandboxes are migrated automatically so their effective egress is unchanged; use the explicit org/<name> form for an org-scoped resource. tektona egress-network-policy ls and info now also surface project-scoped policies.
• Clearer error for an invalid egress network policy reference. Creating a sandbox (or setting a project/org default) with an egress network policy reference that isn't one of tektona/<name>, org/<name>, project/<name>, or a bare <name> is now rejected with a clear message instead of being accepted and silently falling back to no policy.

2026-06-28

• Sandbox placement now accounts for disk. Scheduling reserves each sandbox's disk against the node's available space, so a node is no longer placed onto past its capacity. Paused sandboxes whose state is safely stored in object storage don't tie up disk — their local copy is reclaimed under pressure and restored on resume — while active and not-yet-saved sandboxes keep their reservation.

• Faster first-time sandbox creation. Building a new image snapshot and booting it on a cold node is quicker: snapshot compression now uses all CPU cores, and the runner streams the snapshot download straight through decompression instead of waiting for the full download first. Repeat creates from a warm cache are unaffected.

• tektona sandbox cp accepts a bare sandbox id. You can now write tektona sandbox cp file.txt <sandbox-id> without the trailing colon; it uploads to the sandbox's working directory, the same as <sandbox-id>:.

2026-06-27

• Cleaner CLI tables. CLI listings now print plain, borderless columns instead of boxed tables for easier reading.
• Egress columns in the sandbox list. The sandbox list now includes each sandbox's egress network policy and attached egress proxy profile; the owner moved to the wide view.
• Egress proxy profile in the sandbox API. Sandbox API responses now include the egress proxy profile attached to a sandbox. The egress network policy and egress proxy profile are returned as objects with a name (rather than a bare string), leaving room to carry more detail later.
• tektona secret ls shows when each secret was last updated. The listing now includes an UPDATED column.
• Clearer egress policy details. tektona egress-network-policy info now always lists the full allowed and denied entries for both domains and CIDRs — empty lists are shown explicitly as (none) instead of being hidden.
• Clearer tektona egress-proxy ls output. The listing now auto-sizes its columns, marks the project default with a *, and shows each profile's rule domains (truncated with +N) instead of a bare rule count. The redundant scope column was dropped.

2026-06-26

• Fixed sandbox egress sometimes failing after resume. Resuming a paused sandbox could leave its HTTP/HTTPS egress broken while DNS kept working. Egress now keeps working after a resume.

• The network works the moment a sandbox is running. A sandbox is no longer reported as running until its guest network is actually usable, so tektona sandbox wait --state running followed immediately by network use (e.g. apt-get in CI) no longer fails with connection-refused. This only waits for the sandbox's own network stack to come up — sandboxes with a restrictive egress policy still start normally.

• tektona ssh works from locked-down networks. Some networks (e.g. CI/pipeline runners) only allow outbound web ports and block the default SSH port 2222, so tektona ssh, sandbox cp, and port-forwarding would time out. The access gateway now also accepts SSH on 9443, and the CLI automatically picks a reachable port (preferring 9443, falling back to 2222) — update to the latest CLI to get it. Existing setups keep working unchanged.

2026-06-22

• Sandboxes no longer lose egress after a runner restart. If a runner's egress proxy lost its connection to the platform message bus at startup (for example during a node reboot), it stayed up but silently stopped applying egress rules to sandboxes on that node. It now keeps retrying the connection and re-syncs sandbox rules automatically on reconnect.

• Sandboxes no longer occasionally start with broken egress. On a multi-node deployment, a sandbox could come up unable to reach any allowed domain (TLS connections refused) when an internal placement update raced and dropped the sandbox's network slot. The slot is now preserved, so egress works reliably regardless of which runner the sandbox lands on.

2026-06-19

• Allowed domains no longer time out after a while. Long-running sandboxes could intermittently lose connectivity to a still-allowed domain (connections hanging or timing out) once the domain's DNS record expired, because the resolved IP was dropped from the egress allowlist a moment before it was renewed. Allowed IPs are now held with a grace margin so re-resolution refreshes them in time, keeping allowed domains continuously reachable.

2026-06-10

• Edit a git credential. You can now update a git credential's token, repositories, forge, and display name from the console or with the new tektona git-credential CLI. Each credential also gets a stable slug-style name (unique per scope, fixed after create) that the CLI uses to address it, and a rotated token takes effect on running sandboxes within a few seconds.
• Update a secret's value in place. tektona secret set <key> now updates an existing secret instead of erroring; the new value is re-injected into running sandboxes' egress traffic within a few seconds, with no recreate or pause/resume.
• Reboot no longer intermittently fails. tektona sandbox reboot could occasionally return an error (or appear to hang) even though the sandbox had come back up, when the VM's startup events landed in a particular order. Reboot now reports success once the sandbox is running again.
• Private registry image builds. Sandboxes can now pull base images from private registries you've configured for the project; the build authenticates with the registry credential instead of failing anonymously.
• Git credentials take an explicit forge. Creating a git credential now requires a forge field (github or gitlab) instead of the old kind; the backend no longer infers the forge from the repository host. A credential still unlocks one or more registered project repositories with a single token, and the token is never returned by the API.
• Git credentials rely on your egress network policy for reachability. A git credential authenticates the request but no longer implicitly opens the forge host. The project's egress network policy must allow it (for example github.com or gitlab.com), otherwise the sandbox cannot reach the repository.
• Egress config applies to running sandboxes. Editing an egress network policy (reachable domains) or an egress proxy profile (injection rules) now takes effect on already-running sandboxes within a few seconds, with no recreate or pause/resume needed. Adding the first proxy rule to a sandbox that started without one begins injection live, and newly allowed domains become reachable live.
• Console. You can now update a secret's value from the Secrets page.
• Console. Added project Secrets, Egress Proxy Profiles, and Git Credentials tabs.
• Console. Egress proxy profiles now open a details view showing their injection rules.
• Console. Egress proxy profiles can now be edited after creation from the profile details page, including adding, editing, and removing rules and setting a profile as the project default.
• Sandboxes verify TLS for passthrough hosts. Sandboxes now trust both the egress proxy CA and the image's public root certificates, so tools like git and curl can verify hosts that are not injected. Previously only injected hosts verified, so cloning a public GitHub repository failed with a certificate error.

2026-06-09

• Dashboard disk stats fix. Sandboxes that failed into a terminal state (error/failed/completed) no longer keep counting toward "disk allocated" or accruing disk GiB-hours after they died. Disk now stops accruing at the terminal transition instead of running until the row is deleted.
• Secrets. Secrets can now be stored at org, project, or personal scope and injected into sandbox egress traffic without ever entering the sandbox. Resolution follows personal → project → org precedence.
• Egress proxy profiles. Named profiles bundle injection rules and attach to sandboxes (a project default or tektona sandbox create --egress-proxy-profile <name>).
• New CLI. tektona secret set/ls/rm and tektona egress-proxy apply/ls/show/rm (plus egress-proxy rule add).
• Git tokens. Git tokens are now injected at the egress boundary, scoped to the exact repos they unlock, so the token never enters the sandbox.
• tektonactl ca cert. Prints the sandbox's egress CA so in-sandbox tools with their own trust store (e.g. Java keytool) can import it.
• Breaking: "network policy" renamed to "egress network policy." The API routes (/v1/.../egress-network-policies), the sandbox field (egress_network_policy), the CLI command (tektona egress-network-policy) and flag (--egress-network-policy, alias --egress-policy, with the old --network flag removed), and the SDK surface all use the new name. There is no compatibility shim.

2026-06-08

• Renamed concept. "Network Policy" is now called "Egress Network Policy" across the console, docs, and CLI help text.

2026-06-05

• View deleted sandboxes. Deleted sandboxes can now be surfaced with an include_deleted option and a toggle in the console, instead of disappearing from view.

2026-06-04

• Sandbox ownership & sharing. Every sandbox now has an explicit owner and can be shared with project members across a use / manage access ladder, with ownership transfer and admin oversight.
• Org and project sandbox dashboards. New console dashboards summarize sandbox activity per organization and per project.
• Repo-scoped git credentials. A single git token can now cover many repositories through path matching, project repositories can be referenced directly, and credential endpoints are unified under one scope.
• Cleaner sandbox ls. The owner column is hidden when listing your own sandboxes, and ownership and share-type columns moved after the core columns.
• Admin sandbox tooling. New admin sandbox info shows details for any sandbox, and admin sandbox ls now includes the image.

2026-06-03

• Exact sandbox disk sizing. Sandbox disks are provisioned at exactly the requested size, and creation is rejected with a clear message (including the image size) when the image is larger than the requested disk.
• Console fixes. Locked dark mode, corrected the VNC viewport height, and fixed the in-browser terminal scrollbar.

2026-06-02

• Reboot a sandbox. New tektona sandbox reboot performs a cold reboot in place, preserving the committed disk and IP address.
• Simpler sandbox create. Removed the --verbose flag.

2026-05-30

• Resize a sandbox. New tektona sandbox resize and resize API, with live disk growth applied to running sandboxes.
• Egress network policy deny-lists. Egress network policies support domain and CIDR deny-lists alongside allow-lists, editable from the console.
• List listening ports. A sandbox's listening ports can now be listed, with the owning process resolved for each one.

2026-05-29

• Copy files to and from a sandbox. New tektona sandbox cp for SFTP-based local ⇄ sandbox file copy.
• List projects non-interactively. New tektona project ls.
• Sessions start in the image working directory. Shell, exec, and SFTP sessions now land in the image's WORKDIR, with a sensible $HOME fallback.
• CLI update notice. The CLI tells you when a newer version is available.