The Obot Platform v0.27.0 release is out. Its headline feature is Claude Environments, which lets organizations run Claude Code cloud sessions on their own Kubernetes infrastructure while Obot controls who can start a session, which tools it can use, and where it can send traffic. This release also adds MCP servers generated from OpenAPI schemas, Okta SCIM provisioning, tool search for vMCPs, and a UI available in Japanese, Korean, and Simplified Chinese.
Several of these features have their own in-depth posts from the engineers who built them. This post covers each one briefly and links to those posts for the details.
Try Obot today — the open-source MCP gateway. Self-hostable, MIT licensed, full audit trail at every tool call.
Anthropic’s self-hosted environments let an organization run Claude Code cloud sessions on its own infrastructure instead of Anthropic’s. Developers start those sessions the same way as any other cloud session, from claude.ai/code, the desktop and mobile apps, or claude --cloud in the terminal, and choose the environment from the same picker. On its own, self-hosting leaves the runner image, the fleet, and the network to you, and the environment shows up for every member of the Claude organization. With v0.27.0, Obot handles that part. It runs sessions on your Kubernetes cluster with Agent Substrate, which isolates each session and suspends idle ones with their workspace saved, and it checks that the user has access before provisioning anything.
Administrators grant access through profiles, which map users and groups to the vMCPs a session can use, the hosts it can reach, the secrets it gets, and its CPU and memory limits. Secrets are configured per destination and injected at the egress gateway, so a session can call an internal API without ever seeing the token. Anthropic-hosted environments have a similar network secrets feature, but self-hosted environments don’t, so this fills that gap. Obot vMCP credentials are handled the same way and are scoped to the user’s mapped Obot identity. Every egress request is recorded in the audit logs, and Claude Tag sessions started from Slack or GitHub run under a dedicated service identity. Repository checkouts and the files a session creates stay in your cluster, while the conversation itself, including prompts, responses, and tool results, still goes to Anthropic.
We built on Claude’s self-hosted environments because they are the most fully featured self-hosting option available to integrate with today, and we expect other frontier labs to follow suit. A deep integration also meant developers keep their native Claude Code experience. That was important to us: Obot should govern the session without getting in the way of how people already work. The lower-level building blocks, including Agent Substrate, are not specific to Claude, and we plan to reuse them as we extend this to other agents, including open source agents such as Pi and opencode.
Claude Environments is experimental and disabled by default. It requires Obot to run in Kubernetes with additional cluster resources and configuration, and a Claude Team or Enterprise organization with self-hosted environments turned on, which is itself a public beta from Anthropic. It replaces the former Hosted Agents feature.
Plenty of internal services, such as a custom asset tracker or a legacy application that still holds the records you need, have working APIs and OpenAPI schemas but no MCP server. Pointing an agent at the schema with a credential in an environment variable works, but it gives the agent everything that credential allows. In v0.27.0, an administrator can add an MCP server of type OpenAPI and import a schema from a URL or a file. Each API operation becomes an MCP tool, and Obot runs the server on Docker or Kubernetes.
That puts the API behind every control Obot already applies to MCP servers. Credentials stay in Obot and are forwarded on each request, either set once by an administrator or supplied by each user when they connect. When you add the server to a vMCP, you choose which operations an agent gets and can rename or reword them, so a reporting workflow can have the read operations without the ones that modify records. Profiles decide which users and groups can reach those tools, filters inspect each call, egress policies limit where the server can connect, and every call is recorded in the audit logs. Tool search, covered below, keeps a large API from crowding the model’s context.
OpenAPI entries also work in Git-backed catalogs:
name: Frankfurter
description: Currency information and exchange rates
runtime: openapi
openAPIConfig:
source:
url: https://api.frankfurter.dev/v2/openapi.json
The runtime does not perform OAuth flows against the upstream API, and schemas are limited to 1 MiB. Both are tracked for future releases.
Before v0.27.0, Obot read group information from Okta through an API Services app with read access to the whole directory, and group memberships were refreshed when users signed in. Some security teams would rather have Okta decide what Obot can see. With SCIM, Okta provisions users, groups, and group memberships into Obot. Administrators choose in Okta which users and groups to push, and changes arrive as they happen. Users still sign in through the existing Okta OIDC app. Deprovisioning is where this matters most. Unassigning a user in Okta deactivates them in Obot: they are signed out, and their API keys, tokens, and other credentials stop working, including keys used by agents that run without a person present. Their account and data are kept, so assigning them again restores access. When configuring the Okta auth provider, administrators choose between SCIM and the Okta API for group data, and existing Okta deployments can migrate in place. Support for Microsoft Entra ID is planned.
The Obot UI is now available in Japanese, Korean, and Simplified Chinese. It defaults to the browser’s language, and users can switch from Language in the profile menu. The translations cover the full UI, about 4,000 strings per language, along with auth and model provider configuration text and error messages returned by the API. Product names, code samples, and commands stay in English.
These three languages run on general internationalization support in both the UI and the API, so adding another language is mostly a matter of adding translation files. The UI keeps one message catalog per feature area, and the API picks up new locale files automatically. The initial translations were machine-generated, and native speakers are already improving them: @Sriver535 corrected about 15 Japanese strings in their first contribution to Obot. If you find a mistranslation or want to add a language, pull requests are welcome.
Tool Search for vMCPs
Our v0.26.0 post named tool search and OpenAPI support as the next things coming for vMCPs, and both ship in this release. They are related. A single OpenAPI schema can describe hundreds of operations, and a vMCP that combines several servers can grow just as large. Loading every tool definition into the model’s context up front spends tokens on tools that have nothing to do with the task. vMCPs now have an opt-in Tool search setting. When it is enabled, clients see two tools, search_tools and call_tool, instead of the full list. The agent searches tool names, descriptions, and parameters, then calls the tool it found. In an informal test against 108 tools across six services, tool search used about 90% fewer input tokens on average for targeted tasks, with similar latency. Tool search does not grant additional access. The same component, profile, and user selections decide which tools can be found and called, and each call is authorized and audited as the underlying tool. Obot suggests turning it on when a vMCP has more than 50 tools, and catalog YAML supports it as toolSearch: true.
Remote MCP servers that only accept a localhost OAuth callback, such as Vercel’s official MCP server, can now be added to the catalog. Users complete sign-in with obot mcp login <url>.
Users can reauthenticate a single vMCP component, such as Outlook, without signing out of the others.
The same MCP server can be added to a vMCP more than once, each with its own component name and tool prefix. This is useful for connecting several accounts of the same service.
Catalog entries support minObotVersion and maxObotVersion, so a shared catalog can offer entries only to Obot versions that support them.
Obot Sentry supports Kiro as a client.
When the license service can’t be reached, Obot keeps the last accepted license entitlements until the license expires instead of degrading.
Upgrade Notes
Obot Agent and Hosted Agents have been removed. Obot Agent had been disabled by default since v0.23.0, and Hosted Agents never left experimental status. Claude Environments replaces both. If you were using either feature, we recommend you don’t upgrade to v0.27.0. Please open an issue on GitHub and let us know what you’d like to see as a replacement.
MCP clients must connect through vMCPs. Direct connections to catalog entries, MCP servers, and server instances are now rejected. Connections that were migrated to vMCPs keep their existing URLs.
Several default catalog entries are deprecated. Legacy Slack will be removed on October 30, 2026, and seven other entries will follow on dates not yet announced. Upgrade to at least v0.26.2 before they are removed so existing deployments are preserved.
That’s v0.27.0: Claude Code sessions on your own infrastructure, MCP servers from the APIs you already have, Okta in charge of who gets in, and a handful of improvements along the way.
