Skip to main content
October 7, 2026 · v0.5.155

New Features

API Tokens: Personal, Service Account, and CI Credentials

The old API key reached every organization its owner belonged to, with the owner’s full role, and was stored in plaintext. It is replaced by three kinds of credential, each with a defined reach.
  • Personal access tokens - Create a token under Account → Personal access tokens and choose the workspaces it covers, across organizations. It can never do more than your current role allows, and anything outside its grant answers not found. Tokens are stored as hashes and shown once.
  • Organization service accounts - Organization → API access creates service accounts for integrations. A service account belongs to the organization, not to a person, so it doesn’t take a seat, appear in member lists, or stop working when someone leaves.
  • Keyless CI with GitHub Actions - A GitHub Actions workflow can exchange its identity for a 15-minute token, so a release pipeline stores no long-lived secret. Trust policies can pin the repository, workflow file, environment and ref, and oxyc handles the exchange itself.
  • Expiry, Extend, and Activity - Any token can be extended by 30, 90 or 365 days, given a set date, or set to never expire. Its Activity drawer shows how it has been used, and the audit log names the token behind every action.
  • Organization token policies - Org admins can cap token lifetime, decide whether all-access tokens are allowed, and revoke every personal token’s access to the organization at once.
Existing keys keep working exactly as before. They now appear as Legacy API keys, each marked Legacy, and new credentials are created as API tokens.

Anomaly Alerts in Slack

Before this release, an anomaly a monitor scan found stayed in the Insights Inbox until someone opened it. A monitor can now post new findings to a Slack channel in your organization’s workspace:
  • Opt-in per file - Add a notify: block to a .monitor.yml and pick the lowest severity that should be posted (high by default).
  • One message per scan - Each new anomaly gets one line. Anomalies that fired together share a line, and a long list stops at ten lines with a count of the rest.
  • Each anomaly posted once - An anomaly is never posted twice, and turning notifications on doesn’t post the anomalies already in the inbox.

Preview a Monitor Before It Scans

Until now, Scan now was the only way to see what a monitor would do, and its findings went straight into the Insights Inbox and Slack. Each row of the Monitors tab now has a Preview button:
  • A dry run of one monitor - It shows the periods the next scan would flag, with observed and expected values, percentage change, and severity.
  • Nothing is written - A preview files nothing in the inbox and posts nothing to Slack, so a measure that won’t resolve, a segment with too little history, or a sensitivity that is too high shows up before anyone else sees it.

Workspace Health History

The Health tab used to show only the current status and when it started. It now keeps a record of past status changes:
  • A History section - Lists how long the workspace spent in each status, newest first, with a one-line total for the period.
  • Up to 90 days - Shows whether an outage is the first this month or the fourth, and how long earlier ones took to clear.

Custom-App Sandboxes

Each developer, or each AI agent building an app, can now have their own named environment for a custom app, separate from staging and production, and run it from the CLI:
  • The whole loop from oxyc - Create a sandbox with oxyc env create, publish to it with oxyc publish --app-env, then call functions, run the app’s checks, read logs and delete the sandbox when done. Every step supports --json, and the same loop is available as MCP tools through oxyc mcp.
  • A database schema per sandbox - In organizations with an OLTP staging branch, each sandbox gets its own app schema, copied from staging. Two sandboxes on the same app no longer collide on rows, and a schema migration can be tried in a sandbox.
  • Credentials just for agents - An agent can get a short-lived token, approved once in a browser, that works only on the sandbox loop for a few named apps. It no longer needs the developer’s own 90-day login. Admins can see these tokens on their own page.
  • Previewing a draft from the admin console goes through staging - Viewing a draft now uses the app’s staging host, and the console shows what staging held. Agent requests from staging run with every write held, and automation runs started from staging are refused.

Custom-App Operations for Admins

New tools for seeing how custom apps are running and used:
  • Issues - The app page in the admin console has a new Issues section that groups failed function calls the same way on-call alerts do, with how often each failed, when it was first and last seen, and whether the live build has had it. Copy for an agent copies the issue and the commands that fetch its details.
  • Weekly usage report - Global Owners and Global Admins get a weekly email summarizing each organization’s custom apps: people, opens, function calls, releases and storage, plus the apps that need a look. The report is also in the admin console, and each admin can turn the email off.
  • oxyc apps - A read-only command group that lists registered apps and shows each app’s live build, health, usage, and whether the live build has fallen behind its repository.
  • Clearer admin and traces screens - Failures, logs and traces are laid out as aligned lists, with labeled ids and figures in columns.

Browser Sign-In for Agents

oxyc login-link prints a one-time link that signs a browser in as your personal access token, so an agent driving a browser can use a deployed Oxygen without Google, GitHub or a magic link. The session has the token’s permissions and no more, lasts at most 12 hours, and ends when the token is revoked.

Platform Improvements

Security and Data Isolation

  • Agent traces stay within their workspace - The Traces, Clusters, Metrics and Execution Analytics pages now show only data from the workspace that produced it. Before, on a deployment with several organizations, these pages could include other workspaces’ rows.
  • Data App inputs are treated as plain values - A value a viewer entered in a Data App control was run as a template on the server. It is now passed to the query exactly as typed.
  • SQL values are escaped correctly for each database - Quoted values are now escaped the way each engine expects, so a backslash in a value can’t end the string early on ClickHouse or other engines. This also applies to BigQuery schema parameters and SDK useQuery parameters.
  • Staff limited to some organizations see only those - A staff member whose access covers only certain organizations now sees only those organizations’ data on every admin page.

Sign-In and IDE

  • Gmail and other personal email addresses can receive magic links - Some mailbox providers were blocked, and those users quietly never got a link.
  • The IDE works on a detached HEAD - A workspace checked out at a specific commit instead of a branch used to show an empty editor, failed saves and a disabled Compile button with no explanation. Files now open and save normally, and actions that need a branch explain why they’re unavailable.

Observability

  • The traces view can be linked - Filters are kept in the URL, so you can share a link to a filtered traces view, and going back from a trace keeps your filters.
  • Trace summary and Compare work - The summary strip above a trace now appears, and Compare can load both traces.
  • App logs grouped by request - The admin app’s Logs section groups output by invocation and shows the request id and trace id to copy. You can pick a window of 1 hour, 24 hours or 7 days, and search the full 7 days by request id.

Reliability

  • Custom-app procedure runs survive a deploy - A run now executes once on the task queue, so restarting a server no longer kills a run in progress or leaves it stuck as running. Cancelling an agent request that has already finished no longer fails.
  • More pages work without the Developer Portal - Airway run controls, custom-app function calls, Orchestrator Dashboard history and the World Model graph can now be served by any server, so they keep working when the Developer Portal instance is down.
  • The World Model never shows hidden entities by mistake - If the World Model display config can’t be read, the page now asks you to retry instead of showing every entity, including hidden ones.
  • Unresolvable rollups are refused - A pre-aggregation that names a measure its view doesn’t declare is now rejected, instead of being built silently with that measure missing.

Custom Apps

  • More memory for large requests - A function’s request body is now held in memory once instead of twice, leaving more room before the memory limit. When a function does run out of memory, its error page explains how to find the cause.