[FEATURE]: stable/latest autoupdate channel with version_policy #27997

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

The Feature

Add an object form for autoupdate in opencode.json so users can choose an update channel and the version range that may be applied automatically.

Existing values should keep working.

Enable the current default behavior:

{
  "autoupdate": true
}

Disable autoupdate:

{
  "autoupdate": false
}

Notify without automatically applying updates:

{
  "autoupdate": "notify"
}

Proposed object form:

{
  "autoupdate": {
    "mode": "auto",
    "channel": "stable",
    "version_policy": "same-major"
  }
}

Suggested fields:

• mode: "auto": automatically apply updates allowed by policy
• mode: "notify": notify only, do not install automatically
• mode: "off": disable update checks / updates
• channel: "stable": use the stable update channel
• channel: "latest": use the latest update channel
• version_policy: "any": allow the selected channel's candidate version
• version_policy: "same-major": only auto-apply updates within the current major version
• version_policy: "same-minor": only auto-apply updates within the current major/minor version

If version_policy is omitted, I think it should default to any to preserve the current behavior as closely as possible.

Motivation, pitch

OpenCode is part of active development workflows: interactive sessions, automation, plugins, LSP, permissions, and model/tool execution. Users should be able to choose whether they want the fastest update path or a more stable update path.

There are already related reports where update behavior, regressions, or plugin version handling affected workflows:

• v1.15.0 direct exec opencode run returned exit 0 with empty stdout/stderr (opencode run --agent X "prompt" returns empty stdout AND stderr when spawned via direct execvp (no shell) — v1.15.0 regression #27669)
• v1.15.x Windows Desktop + LSP file-read freeze (LSP causes desktop app to freeze/hang on file read (regression in 1.15.x) #27894)
• v1.15.2 TUI session hang after LSP initialization with InstanceRef not provided (bug: TUI session hangs with InstanceRef not provided rejection after LSP initialization (v1.15.2) #27880)
• v1.14.50 message submission regression, reproducible with --pure (Regression in v1.14.50: message submit fails silently due to ToolRegistry.resolveTools Object.entries crash #27630)
• plugin @latest cache staying pinned to an older npm version (Plugin @latest cache can stay pinned to stale npm version #25293)
• plugin target / initialization / version parsing compatibility issues ([Bug]: npm plugins not loaded on v1.3.8 — "No plugin targets found", expects "oc-plugin" field in package.json #20139, Plugins deadlock on startup when calling client.app.log() (v1.4.8 regression) #23147, Plugin without version defaults to "latest" causing semver parsing error #12143, Plugin install fails with 'Invalid Version: latest' in v1.3.6 #19956)

The current startup autoupdate behavior already appears to auto-apply patch updates and notify for minor/major updates. This request is not about claiming that minor/major releases are silently auto-installed on startup.

The gap is that users still reach moving latest versions through several paths:

• opencode upgrade
• package-manager latest installs
• update prompts
• plugin @latest resolution
• generated plugin/runtime compatibility changes

A stable / latest channel choice plus version_policy would make that behavior explicit and configurable.

Proposal

Define two update channels:

• latest: the newest published release
• stable: a release promoted after a stability window or after no known critical/blocking regressions remain

Then apply version_policy after selecting a candidate from the chosen channel.

For example, suppose the installed version is:

1.14.50

and the stable channel contains:

1.14.52
2.0.3

Same-major stable auto-update:

{
  "autoupdate": {
    "mode": "auto",
    "channel": "stable",
    "version_policy": "same-major"
  }
}

OpenCode should be able to auto-apply 1.14.52, but should not auto-apply 2.0.3 because it crosses the current major version. It should show an update notification instead.

Any stable auto-update:

{
  "autoupdate": {
    "mode": "auto",
    "channel": "stable",
    "version_policy": "any"
  }
}

OpenCode may auto-apply the latest stable candidate, including 2.0.3.

Latest notify-only with same-minor policy:

{
  "autoupdate": {
    "mode": "notify",
    "channel": "latest",
    "version_policy": "same-minor"
  }
}

OpenCode should only notify. The policy should still make clear which updates would be considered within the same minor line.

Related work

• [FEATURE]:Stable Branch Release #14358 proposes a broader stable release cycle. This request is narrower: expose only stable and latest as update channels in opencode.json, plus version_policy for automatic update boundaries.
• Plugin Auto-Update Feature #6159 discusses plugin auto-update policy.
• Plugins with implied latest version don't auto-update on restart #6774 and Plugin @latest cache can stay pinned to stale npm version #25293 discuss plugin latest update/cache behavior.
• https://x.com/justsisyphus/status/2022909902386270234 discusses update stability and release-channel expectations.

Expected behavior

• Existing autoupdate: true | false | "notify" settings continue to work.
• Object-form autoupdate supports mode, channel, and version_policy.
• Supported channels are stable and latest.
• version_policy values are any, same-major, and same-minor.
• Missing version_policy defaults to any.
• channel chooses the update candidate stream.
• version_policy decides whether the selected candidate may be installed automatically.
• Updates outside the policy are not auto-installed and are shown as notifications.
• The stable promotion rule is documented.
• Install-method limitations are documented for npm/bun/pnpm/curl/Homebrew/Scoop/Chocolatey/Desktop/GitHub Action.
• Plugin pinning, @latest cache behavior, and core/plugin compatibility errors are documented or surfaced clearly.
• Security or critical hotfix behavior is documented for users on conservative policies.