# OpenCode 2.0 Can Write Its Own Plugins. Your Old Ones Need a Port. **Summary:** OpenCode 2.0 can write and hot-reload plugins, but V1 extensions need a port. I would verify existing integrations and control of background work before expanding what the agent can do. - Canonical: https://markhuang.ai/news/opencode-2-plugins-need-a-port - Language: en - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-10-14 - Section: News - Tags: OpenCode 2.0, Coding Agents, Plugin Migration, Developer Tools, Agent Reliability - Source: [Anomaly](https://anoma.ly/notes/opencode-2-0/) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![A modular computing instrument connected to three glass panels, with an older cartridge whose connector does not fit the open socket](https://cdn.markhuang.ai/news/opencode-2-plugins-need-a-port/hero.webp) *An editorial metaphor for the upgrade: a more extensible runtime still needs compatible extensions.* [Anomaly's OpenCode 2.0 announcement](https://anoma.ly/notes/opencode-2-0/) makes an appealing promise: the agent can write a plugin for itself during a session and use it immediately. The same announcement says that OpenCode 1.0 plugins will not run in 2.0. That is the tension I would weigh before upgrading: new ways to extend the agent, and a port for extensions an existing workflow may depend on. I like the direction. I would still port any plugin the workflow depends on before asking the agent to write more. Anomaly says it implemented nearly every 2.0 feature as an internal plugin and now has 80+ of them. That gives the team a reason to maintain its plugin API. It does not establish that a generated extension will preserve my intended permissions or workflow. OpenCode already had a client/server design; 2.0 makes one shared background service the default for the terminal, web interface, and desktop app. That makes the upgrade useful for building integrations, and gives me more to check. I would evaluate the whole setup, including the plugins and scripts attached to it. ## A better place to build around the agent The announcement describes a new API and a `@opencode/client` package that can discover the local service. OpenCode can call its own API, including to move a session into a Git worktree. Background subagents and asynchronous shell commands let other work continue while a task runs. I can see the appeal for developers who want custom automation around a coding agent. A script and a terminal client can work through the same service. That gives custom automation a place alongside the interactive session. Jeff Morhous makes a similar observation in [his independent walkthrough](https://www.augmentedswe.com/p/whats-new-in-opencode-2): the changes make it easier to build software around OpenCode. The announcement also describes Code Mode, which turns MCP servers or OpenAPI endpoints into functions an agent can compose in JavaScript. Its example fetches GitHub issues and creates corresponding Linear issues. One script can use a tool's output as another tool's input. I want that convenience, though I would still check whether the agent chooses the right actions before giving it access to more services. ## An old plugin needs more than a new filename The [official migration guide](https://opencode.ai/v2/docs/migrate-v1/) is clear about the main breaks: plugins, server API contracts, and terminal configuration. It explicitly warns that moving a plugin file or renaming its configuration entry is insufficient. Plugin authors need to port the implementation. The guide also gives existing users a reason to be less anxious. Supported V1 configuration, agent and command definitions, skills, and MCP setup are intended to keep working. Converting everything to the native V2 configuration format is optional. The guide also says both versions use the same configuration locations and recommends keeping a copy of the V1 setup while validating V2. That changes my upgrade decision. Someone using the standard agent with supported configuration may have little to port. A team relying on a custom review plugin or a script that calls the old server API needs to verify those integrations separately. I would list those dependencies before installing, then check their actual behavior rather than count how many files migrated without an error. ## I would check what happens when a provider fails One public report gives me a useful case to check: a [GitHub request for provider-level retry coordination](https://github.com/anomalyco/opencode/issues/55075). The reporter describes concurrent sessions retrying a failing provider independently and asks for shared backoff and a circuit breaker. I have not reproduced that report, so I would use it to design a check rather than estimate how widespread the problem is. A shared process can make sessions easier to reach without coordinating how they handle a failing provider. Before depending on background work, I would want to see what happens when the provider stops responding, how I find the affected sessions, and how I interrupt them from another client. Those are the checks I would run before relying on it. Self-written plugins deserve similar scrutiny. The [plugin documentation](https://opencode.ai/v2/docs/build/plugins) exposes hooks for permission evaluation and tool execution. I would examine an extension that changes permission decisions much more carefully than one that changes the terminal's appearance. Hot reload shortens the path to trying an extension. I would review what it changes before keeping it. ## I would migrate the workflow before expanding it I would start with a familiar, bounded task and only the integrations it needs. I would check that the ported plugin still enforces its intended rule, that a custom client can complete its normal operation, and that I can find and interrupt background work. I would keep configuration changes small enough to compare with the saved V1 setup. This is the same cost I described in [my piece on proving an agent's patch](https://markhuang.ai/news/coding-agents-patch-proof-cost): generating a change and accepting it are separate jobs. OpenCode's ability to write its own extensions makes that distinction more immediate. I would consider 2.0 for the shared runtime and the new extension API. I would call the upgrade successful once the existing workflow behaves correctly. If that workflow depends on a plugin, porting it is where I would ask the agent to start.