# OpenCode 1.19 Adds an Explicit Upgrade Path to OpenCode 2

OpenCode 1.19 changes how updates install and adds a direct route to V2, making plugin compatibility and existing workflows worth checking before migrating.

By Paras Madan | 2026-10-12


OpenCode 1.19.0, released on October 11, gives existing users an explicit route to OpenCode 2 and changes how updates are installed. You can request the major upgrade from the command line or through the terminal interface. The V1 terminal interface no longer installs updates automatically.

For developers who have built their daily workflow around OpenCode, that makes this release worth checking. A coding agent can accumulate custom tools, permission rules and integrations over months of use. Moving that setup to a new major version deserves a little preparation.

## What changed in the October 11 release

The [1.19.0 release notes](https://github.com/anomalyco/opencode/releases/tag/v1.19.0) specify two routes: run `opencode upgrade --major` from the command line, or use `/update` in the terminal interface. The latter can install OpenCode updates or upgrade to OpenCode 2.

The release also adds support for OpenAI's `ultrafast` service tier.

OpenCode 2 predates this update. The project's [V2 tag](https://github.com/anomalyco/opencode/releases/tag/v2.0.0) is dated September 11. The October 11 news is the migration path supplied to V1 users, along with the change to automatic update behaviour.

That distinction helps when deciding what to test. Someone already using V2 is in a different position from a developer with a customised V1 installation who has just encountered the upgrade command.

## Check which parts of your setup need migration

The current [V1 migration guide](https://opencode.ai/v2/docs/migrate-v1/) names three intentional breaking changes: the plugin API, server and client contracts, and terminal configuration. Both major versions now use the `opencode` command. They are no longer installed side by side by default, and the V2 curl installer replaces the V1 binary.

Supported existing configuration can still load from the same locations. Converting everything to native V2 syntax is optional. Keep a copy of the V1 setup, though: the guide warns against sending V1 back to configuration converted into V2-only forms.

There is also a practical limitation for code-checking workflows. V2 accepts existing LSP configuration but does not run language servers or provide their tools and diagnostics. The documented alternative is to use the project's lint, typecheck or compiler commands.

For a team, that is a reason to review its usual acceptance checks. If an agent's work normally arrives with compiler output attached, make that expectation explicit in the migration test. A familiar prompt can produce a plausible answer even when a supporting integration is missing.

## Plugins need more than a renamed setting

OpenCode's [plugin migration documentation](https://opencode.ai/v2/docs/build/plugins/migrate-v1) says V1 plugin implementations do not run in V2. Moving a file or changing the configuration key does not port the code.

A V2 plugin uses a definition with an identifier and a setup function. Hooks, tools and subscriptions are registered through its context. Some older hooks also need a different design rather than a direct name substitution.

The guide's verification steps are useful for maintainers: confirm the plugin appears in the active list, exercise its registered behaviour, and check cleanup when it is removed or reloaded. Test options and saved state in a clean project. For a published plugin, test the installed package as well as the development copy.

If you depend on a community plugin, check its stated V2 support before migrating. If you maintain one, a compatibility note should describe which releases you tested and which functions worked. That is more useful to a downstream developer than a general claim that the upgrade is straightforward.

## Try one complete workflow first

Choose a small task you can verify independently, such as making a change in a test project and running its checks. Include the integrations you rely on during ordinary work. Record the installed version and any configuration changes so another person can reproduce the result.

The useful outcome is a repeatable task that still works with your chosen model, tools and approval rules. Once that is established, you can move the rest of the setup with a clearer idea of what needs attention.

I'm Paras Madan. I work across AI engineering and distribution, helping technical products reach the developers who can use them.

I help teams turn changes like this into clear developer content, from release explainers to migration guides that show what to check before upgrading.

[Book a 30-minute call](https://cal.com/paras-madan/30min)