OpenCode 1.19 makes its updater manual
OpenCode 1.19.0 puts users in charge of when its built in updater installs a release. The release published on October 11 stops automatic installation through that updater and introduces a command for moving to OpenCode 2. For existing users, the immediate change reaches beyond the major upgrade. Even routine patches through this updater now need an explicit installation action.
Automatic settings now mean notifications
The practical detail is in the update checking code. Earlier behavior could install a patch during the background check. The new routine checks for a version and returns notification state instead. It no longer calls the installation function.
Setting autoupdate to true now has the same notification behavior as setting it to notify. Setting it to false still disables the check. Anyone who relied on automatic patches should plan to review update notices and install deliberately through the terminal interface or upgrade command.
A choice between updating and moving to V2
The new update dialog makes another distinction. If a newer V1 release is available, it offers that update first. Once V1 is current, it offers the move to OpenCode 2. A failed version check produces an error state rather than an installation offer.
Skip and Dismiss also behave differently. The repository tests describe skipping a particular V1 release until a newer version appears. Dismissing the V2 offer suppresses it for one week. Those preferences are independent, so postponing the major upgrade does not hide an ordinary V1 notice.
What the major upgrade replaces
The installation implementation shows why a major upgrade deserves preparation. For npm, pnpm, bun and yarn, it removes the V1 package before installing the V2 package. If that installation fails, it attempts to reinstall the original V1 version. Homebrew similarly removes the detected V1 formula and attempts restoration if the replacement fails.
That recovery path is an attempt, not a guarantee. The curl route runs the V2 installer against the existing binary location, without the same restoration step in this function. Methods without an automatic V2 installation path return guidance before removing anything.
The installation tests in the repository cover package replacement, failure recovery and an unsupported Chocolatey path. These findings come from reading the tagged source and its tests. ByteForward has not run these tests or verified a live migration.
Check the workflow before making the switch
OpenCode’s migration guide identifies changes to plugins, server integrations and terminal configuration. V1 plugins need porting. Terminal settings move to a global file. The guide also says V2 accepts the lsp field but does not run language servers or produce their diagnostics.
A useful preparation step is to list which of those capabilities a project uses, retain a copy of the V1 setup and verify the required behavior before adopting V2 for regular work. Keeping supported configuration in its existing form is allowed. Converting everything first is unnecessary.
For teams, the update policy change creates a clear maintenance decision. Assign time to review releases and choose when to install them. Treat the V2 offer as a separate compatibility decision, especially when plugins or OpenCode’s LSP diagnostics are part of the daily workflow.
For developers considering a hosted workflow, Cloudflare’s experimental OpenCode integration introduces a separate set of execution and recovery considerations. Its cloud session support does not remove the need to check the capabilities a local V1 project depends on.
