OpenCode 2.0 lets an agent write a plugin and use it without restarting the session. Developers bringing their own extensions face an immediate snag: plugins written for 1.x won't run. The new release makes the coding agent easier to change while it's working, at the cost of porting the code that already customizes it. Anomaly's announcement describes the overhaul.
For anyone who has built a company-specific tool or review hook, that compatibility break deserves attention before the new features do. OpenCode is an MIT-licensed coding agent, so its extensions can be part of a team's own development machinery. A plugin API change reaches beyond the appearance of a chat window.
Your configuration can survive while your plugin needs a rewrite
The V2 migration guide draws a useful line. Supported existing configuration, agent definitions and file-based commands are intended to keep working. V2 reads the familiar configuration locations and translates supported settings in memory, without rewriting the files. Converting everything to the native V2 format is optional. Plugin implementations and integrations that call the old server API require migration.
That promise has specific limits. The same guide says V2 accepts lsp settings but doesn't run language servers or supply their diagnostics and tools. Workflows that depended on that feedback need project lint, type-check or compiler commands instead. An accepted configuration entry doesn't establish that its old behavior still exists. The documented exceptions are worth checking against the parts of OpenCode you actually use.
Installation also needs care. The V1 documentation warns that both generations use the opencode command and cannot sit side by side under that default name. Its installation methods can replace a V2 installation. The V2 introduction identifies @opencode/cli as the npm package for the new version. Copying an old setup command from a team document can therefore send you down the wrong installation path.
For an existing CLI installation, Anomaly's announced upgrade route is to reach the latest 1.x release first, then run:
opencode upgrade --major
Plugin authors have more to do than rename a field
V1 plugins returned an object containing tools and hooks. V2 uses a default-exported definition with a stable identifier and a setup(ctx) function that registers behavior. The plugin migration documentation explicitly says moving a file or renaming its configuration entry is insufficient. A plugin can still be found on disk while its implementation needs porting.
Some changes demand a decision about intent. The old command.execute.before hook has no direct global replacement. A plugin that owns a command should register that command, while one meant to change submitted prompts should use the prompt hook. The migration table also distinguishes prompt admission from context prepared immediately before a model request. Translating names mechanically can put a team's instruction at the wrong stage.
The new plugin API gives each extension a lifecycle. Setup can return cleanup work for unloading. Changes to a registry, such as the available models, are registered as repeatable transformations. When that registry changes, OpenCode rebuilds it by replaying the active transformations in order. Plugin authors need to keep those callbacks cheap and repeatable, with external data fetched before the transformation is registered.
Anomaly's explanation of reloading shows why this matters. If one plugin refreshes a model catalog and another disables selected providers, replacing the catalog directly can wipe out the restriction. Rebuilding from ordered transformations reapplies both changes. Its second example is a plugin that halves an output limit: repeatedly modifying the same value would keep shrinking it.
That design supports edits during work. According to the same explanation, removing a plugin drops its registered transformations and rebuilds the affected state. Editing replaces the old registrations with new ones, and every session sees the result. For a developer maintaining a custom tool, the useful gain is being able to revise it without abandoning the conversation where it is needed.
Code Mode changes how integrations get called
The tools documentation describes Code Mode as a JavaScript runtime for combining calls and processing their results before returning information to the model. It has no direct filesystem access, imports, timers or fetch. Access goes through the tool catalog. This gives an agent a way to express a small workflow in code while keeping intermediate results out of the conversation.
MCP connections use that route by default. In the MCP server configuration, codemode defaults to true; setting it to false exposes a server's tools directly. The guide still warns that MCP tools consume context and recommends connecting only servers you need. The new calling mechanism gives developers another integration choice, without making a large collection of connected services cost-free.
The permission boundary is documented separately from the runtime's limits. Allowing execute makes Code Mode available, while nested built-in and MCP calls keep their own permission checks. Plugin tools enforce the checks they declare. The tool reference therefore gives plugin authors a concrete responsibility: any checks their tool needs must be asserted by that tool.
A new API needs consumers that handle interruptions
OpenCode 2.0 also puts a single background service behind its interfaces by default. Anomaly says terminal, web and desktop clients talk to that process, with scripts able to discover it locally. Background subagents and shell commands let work continue while the main conversation proceeds. These are release features, rather than results from our own testing.
For developers migrating an external integration, the JavaScript client is @opencode/client. Its types and methods come from the same contract as the HTTP API reference. Requests can carry cancellation signals and headers. That matters for a dashboard or scheduled job that needs to stop waiting for an operation without treating every request as an unbounded conversation.
There is a less conspicuous limit in the client's event handling: subscriptions have no replay or automatic reconnection. If the event source fails, current subscriptions end and the consumer must subscribe again after recovery. A late subscriber doesn't receive past business events. Anyone building a progress display should account for those documented stream semantics before relying on the display to describe everything an agent has done.
Embedding uses a different package. The SDK documentation says @opencode/sdk hosts OpenCode inside an application and routes calls through its HTTP router in memory, without opening an HTTP listener. The application owns the host's lifetime and must release its resources. Developers can choose between connecting to a service and hosting the agent themselves, with different cleanup obligations.
Check the extension while it is running
Permission rules in V2 form an ordered array, and the last matching rule wins. Global and agent rules can alter earlier behavior. The permission documentation also states that a custom subagent uses its own permissions, rather than a subset of its parent's. Reviewing only the main agent's settings won't establish what a delegated task can do.
Plugin configuration has its own ordering. Applicable plugin arrays accumulate, and later entries can disable or re-enable identifiers. The configuration guide documents commands to list active plugins and check package updates. Seeing an extension in that list is a useful first check; exercising its behavior remains a separate job.
The next evidence to watch is whether the extensions people depend on behave correctly through edits and reloads. OpenCode's plugin verification guidance calls for exercising registered hooks and tools, checking cleanup after removal, and testing the installed package. For a team adopting 2.0, a review hook that still runs after a reload is a more useful milestone than a successful first launch.