What happened
OpenCode v2.2.3 adds a built-in provider named Claude Agent. The release notes describe a short setup path: install Claude Code, run claude auth login, then select Claude Agent from OpenCode’s /connect flow. OpenCode can then use that Claude Code login and its available models. If Claude Code is not found at the default location, OPENCODE_CLAUDE_PATH can override the executable path.
That is a meaningful integration detail rather than merely another model name in a selector. The provider relies on the locally installed Claude Code executable and its authenticated state. A developer who already uses Claude Code can therefore connect that access to OpenCode without the release notes describing a separate API-key setup. OpenCode remains the environment through which the user works, while Claude Code supplies the login and model access.
The release also changes the boundary of managed policy. Previously, a bare integration.use rule could apply more broadly. In v2.2.3, integration.use controls only which integration accounts may be used. OpenCode introduces separate actions for MCP servers, skills, and plugins: mcp.use, skill.use, and plugin.use. Rules using the older mcp:, skill:, and plugin: resource prefixes are converted automatically, but a bare integration.use rule no longer grants access to those other surfaces. Teams with centrally managed OpenCode policy should check their rules before assuming that existing access behavior remains unchanged.
There are additional runtime and interface changes. Experimental schedules gain Code Mode JavaScript checks, including statically authorized tool calls, persistent state, and custom wake messages. TUI plugins now require OpenTUI 0.8; the release notes call this a breaking change and point to changes in the ScrollBox facade objects and custom render contexts. For desktop users, the project reports less rendering work for streaming replies and long conversations, alongside fixes for side-panel tabs, repeated “Session not found” notifications, and opening files over HTTP. The SDK also preserves partial LLMResponse output when an AI error interrupts generation, object generation, or a tool loop.
What the archive adds
An earlier Telegram post described OpenCode as an agent runtime that separates the working harness from a single model vendor, unlike vendor-native command-line agents that tie sessions, permissions, skills, and project rules more closely to their own model access. This release adds a concrete mechanism to that story: OpenCode can now use a Claude Code login through its built-in Claude Agent provider. It is a new fact on that broader interoperability thread.
Trend signal
This release supports the pattern that harness architecture outlives model choice. The evidence is narrow: OpenCode has added one provider that reuses one external coding agent’s login. But the setup separates the environment where a developer runs an agent from the credentialed path used to reach models. That is consistent with the archive assumption that multi-provider agent runtimes continue to gain relevance alongside vendor-native agents.
Why it matters
For an AI development team, the useful question is no longer only which coding model to buy. It is also which runtime owns the workflow around that model: sessions, tools, permissions, project context, extensions, and policy enforcement. OpenCode’s Claude Agent provider gives developers a specific way to test that separation using an existing Claude Code login.
The policy changes matter just as much for organizations. MCP servers, skills, and plugins are different execution and integration surfaces from an account connection. Splitting their authorizations can make a policy more explicit, but it also means that a formerly broad rule may no longer express what an administrator intended. The release offers automatic conversion for older prefixed rules, not a guarantee that a bare rule will preserve prior access.
Limits and uncertainty
The release notes establish the setup steps and the policy semantics, but they do not establish performance, reliability, model availability, cost, or entitlement details for the Claude Agent path. They do not say whether every Claude Code account type behaves identically, nor do they compare this provider with direct API access or other OpenCode providers. The notes also do not demonstrate how the integration behaves under enterprise controls, concurrent use, or an interrupted authentication session. Teams should treat the provider as a newly shipped integration and validate it in their own environment.
Skill to build now
Create a small provider-evaluation checklist this week. Use the same representative coding task in OpenCode with the Claude Agent provider, then record what remains stable when the provider changes: repository instructions, permissions, MCP access, skills, session history, tool behavior, and review workflow. Separately, inspect managed-policy files for bare integration.use rules and decide explicitly which MCP servers, skills, and plugins should receive the new dedicated actions. This turns a release feature into a controlled runtime comparison rather than an informal model swap.
Reader takeaway
OpenCode 2.2.3 makes a practical claim about agent portability: a developer can authenticate through Claude Code yet work through OpenCode’s runtime. That may make runtime choice easier to evaluate, but organizations using managed policies should review authorization rules first because integration access is now distinct from MCP, skill, and plugin access.
Open question
Will this provider remain a simple local-login bridge, or will OpenCode expose enough observability and policy controls for teams to operate it consistently alongside direct provider connections?