github obot-platform/obot v0.22.0
on GitHub

latest releases: v0.23.0-rc4, v0.23.0-rc3, v0.23.0-rc2...
16 days ago

We're excited to announce the v0.22.0 release of the Obot Platform. This release introduces two major capabilities focused on deeper integrations with popular coding agents running on users' local devices. Admins can curate a catalog of skills in Obot, govern access with dedicated skill access policies that work similarly to the policies used for MCP servers, and let users install those skills into their local coding agents with obot skills. Separately, obot scan gives admins fleet-wide visibility into which AI clients, MCP servers, and skills are installed across users' machines. The release also adds image pull secret management, external secret integration for MCP servers, and an OAuth inspector for diagnosing remote MCP authentication.

Big Updates

obot scan: Fleet Inventory of Local AI Clients

The new obot scan CLI command walks a user's home directory and reports every installed AI client it knows about (Claude Code, Claude Desktop, Codex, Cursor, Goose, Hermes, Openclaw, Opencode, VS Code, Windsurf, Zed), the MCP servers each one is configured to talk to, and any skills and plugins present on disk. Each scan submits a single envelope to the Obot backend.

Admins get a new Device Management area in the admin UI. The Dashboard shows distinct device and user counts and ranked donut breakdowns of the top clients, MCP servers, and skills across the fleet over a configurable time window. From there, admins can drill into per-device scan history, per-MCP-server occurrence lists (grouped by a content hash so the same logical server collates across users), and per-skill occurrence lists. Auditors get read-only access to the same views.

This gives admins concrete answers to "what MCP servers are people actually running" and "where is this skill installed" without surveying users by hand.

Centrally Managed Skills for Local Agents

Admins can now curate a catalog of skills in Obot and govern who can use them with dedicated skill access policies. These are managed separately from MCP server access policies but follow the same model, so the workflow is familiar. The user UI surfaces a new Skills page that lists exactly the skills a given user is allowed to install.

Users discover and install those skills into their local coding agents with the new obot skills command in the Obot CLI. It can be used two ways: directly from the terminal to search the catalog and install a skill into the current agent, or from inside the agent itself once Obot's bootstrap skill set is installed.

The bootstrap path is handled by obot setup. It walks the user through an OAuth login against a specific Obot instance, detects the major coding agents that follow the ~/.agents skills convention (Cursor, VS Code, Codex, and others), plus Claude Code (which uses its own dir), and installs four skills: obot (visible to the agent, explains how to use the CLI to find more skills) and the obot-scan, obot-skills-install, and obot-skills-search slash commands. From then on, users can run /obot-skills-search and /obot-install-skill from inside their agent without touching the terminal.

No manual config file editing and no API key handling: authentication is OAuth per Obot instance, and CLI tokens are stored in the OS keychain.

Image Pull Secrets

Admins can now manage container registry image pull secrets for containerized MCP servers from the Obot UI. Two secret types are supported: Basic, for registries like Docker Hub and GHCR, and ECR, for AWS Elastic Container Registry.

For ECR secrets, Obot assumes a configured IAM role and refreshes the ECR token every six hours so the secret stays valid without manual rotation. The UI surfaces the Trust Policy and ECR IAM Policy required for Obot to assume the role, includes a Test button to verify the secret works against the configured registry, and gives auditors read-only access.

UI-managed image pull secrets and static Helm-configured pull secrets are mutually exclusive: if any pull secrets are configured through the Helm chart, the UI is locked out and shows a clear explanation.

External Secret Integration for MCP Servers

MCP catalog entry env vars can now bind to existing Kubernetes Secrets instead of requiring users to type credentials into Obot. A catalog entry declares a secretBinding (Secret name and key) on an env var, and at deploy time Obot wires the value into the MCP server pod with a secretKeyRef rather than resolving the secret itself.

This lets teams keep credentials managed by Vault, AWS Secrets Manager, External Secrets Operator, or any other tool that syncs into Kubernetes Secrets. The secret value flows from the external store to the Kubernetes Secret to the container; Obot never sees or stores it. The UI shows configs that are secret-bound as such, without exposing the underlying value.

In V1, secret bindings can only be defined in git-managed catalog sync sources, not through the UI, so they remain code-reviewed and version-controlled.

MCP OAuth Inspector

This release adds a set of tools for diagnosing OAuth-protected remote MCP servers. The MCP server details page now surfaces the OAuth metadata Obot discovered for the server (authorization endpoints, supported scopes, client info, and so on), and exposes a walk-through debugger that steps through the OAuth handshake so it is clear where a flow is failing.

Users can also re-trigger the OAuth flow for a server directly from the UI when a token has gone stale or the server's OAuth configuration has changed, instead of having to delete and re-add the server.

User-Defined Headers for Multi-User MCP Servers

Multi-user MCP servers can now accept per-user header values. Previously, the only way to require per-user configuration on an MCP server was to deploy it as a single-user server, which spins up a separate pod for every user and can waste capacity in large deployments.

With user-defined headers, admins deploy one shared multi-user server, and each user supplies their own credential (or other per-user value) as a header that Obot passes through on every request. This only works when the MCP server implementation reads the header itself, so it is intended for servers built with this pattern in mind.

Generic Model Provider Replaces Ollama

The dedicated Ollama model provider has been replaced with a generic OpenAI Responses-compatible model provider. The generic provider works with Ollama, LiteLLM, and any other gateway that exposes an OpenAI-compatible Responses endpoint.

If you were using the Ollama provider, reconfigure it under the new Generic provider with the same endpoint.

Improvements

  • Per-server MCP startup timeout: npx, uvx, and containerized catalog entries can now declare a startupTimeoutSeconds that the Docker and Kubernetes backends honor, so slow-starting servers (especially ones building from source via npx) no longer time out under the previous default.
  • Separate resource request defaults for agents, remote MCP servers, and other workload types, so the admin can tune capacity per workload class instead of with one global value.
  • Dynamic OAuth client expiration is now configurable, instead of a fixed default.
  • CLI auth tokens are stored in the OS keychain.
  • Model providers support a per-provider log level for debugging.
  • The Helm chart supports an existingSecret for the custom encryption configuration, so the encryption key can be sourced from a pre-created Secret instead of generated at install time.

Upgrade Notes

This release contains several breaking changes. Review carefully before upgrading.

Legacy chat functionality has been removed. The legacy chat UI is gone, nanobot agent support is now always on, and a number of legacy APIs, configuration parameters, and the old triggers/knowledge/workspace systems have been removed alongside it. See #6680 for the full list.

Helm chart extraEnv and extraEnvFrom values have been removed. If your values.yaml set either of these to inject environment variables into the Obot deployment, move those values into the existing config: block (or, for secret references, use config.existingSecret) before upgrading. See #6648 for details.

Ollama provider has been replaced. See the "Generic Model Provider Replaces Ollama" section above.

What's Changed

Full Changelog: v0.21.1...v0.22.0

Check out latest releases or
releases around obot-platform/obot v0.22.0

Don't miss a new obot release

NewReleases is sending notifications on new releases.

Get notifications