OpenCode 1.19.0 Ends Automatic Updates and Ships the Explicit Path to OpenCode 2

OpenCode, the MIT-licensed open-source coding agent whose GitHub repository reports more than 212,000 stars, released v1.19.0 on Oct. 11, 2026 at 01:39 UTC. The release notes are short — one core improvement, two bugfixes, and one TUI change — but the policy shift inside them is consequential for anyone running coding agents in production: updates are no longer installed automatically, and the road to the next major version, OpenCode 2, now runs through explicit operator commands.

What shipped in v1.19.0

Area	Change	Why it matters
Core	opencode upgrade --major upgrades the install to OpenCode 2	The major-version migration becomes an explicit opt-in
Core	Allow the OpenAI ultrafast service tier	Harness-side allowance; account-level access still governs availability
Core	Validate PTY connection origins and tickets before checking whether a PTY exists	Hardens the pseudo-terminal attach path
TUI	/update installs updates or upgrades to OpenCode 2; updates are no longer installed automatically	Ends silent update installs

The captured release page below shows the full notes, the 733b2c6 commit marker, and the Latest badge GitHub assigns to the tag.

Automatic updates are off

The TUI line in the notes does two things at once. It introduces /update as the in-session command for installing OpenCode updates or moving to OpenCode 2, and it states plainly that updates are no longer installed automatically. For a solo developer that is a small friction increase. For fleets it is a change-control win: a pinned harness stays pinned until a human or a pipeline asks for a new version, which removes the drift class where a running lane silently picks up new defaults mid-week. Our guidance on canarying every CLI upgrade still applies — with one adjustment: the canary is now the only update path, not a brake on one.

# Cross the major-version boundary from a shell
opencode upgrade --major

# Inside the OpenCode TUI: install updates or move to OpenCode 2
/update

The trade-off runs the other way, too. Machines that relied on silent installs stop receiving fixes — including hardening like the PTY change below — until someone schedules the update. The patch clock is now an owned responsibility, not a background service.

A security-shaped bugfix

Under bugfixes, the notes say: “Validate PTY connection origins and tickets before checking whether a PTY exists.” The ordering is the substance. By checking a connection’s origin and ticket before answering whether a given pseudo-terminal exists, the server stops disclosing PTY presence to callers that have not proven where they come from or that they hold a valid ticket. The notes do not name a vulnerability, assign a CVE, or describe an exploit, and it would be overreach to claim one. What is verifiable is hardening of the terminal attach path in a tool that routinely runs shell commands. If OpenCode sessions on your machines are reachable by other processes or across a network, roll this release with security-patch priority — and test that legitimate clients still attach.

The OpenCode 2 path exists; the destination is still unlabelled

“Run opencode upgrade --major to upgrade to OpenCode 2” is the first shipped mechanism for crossing the major-version boundary, and the repository corroborates that v2 work has been underway: the tree carries a specs/v2 directory and a root-level V2_HTTP_API_AUDIT.md. But nothing in these notes describes what OpenCode 2 actually changes, and the release documents no availability expectations beyond the command itself. Operators should hold the distinction: the upgrade path is available now; the migration decision waits on OpenCode 2’s own release notes and a staging run. A one-line command is not a migration plan.

Release engineering context

The project’s releases index shows the fast cadence behind this tag: v1.18.35 landed Oct. 6, and v1.18.34 on Sept. 30 added macOS Developer ID signing for CLI binaries plus re-signing of locally compiled macOS binaries. The v1.19.0 tag itself publishes 40 assets — desktop builds, latest.json update manifests, source archives — with per-file SHA-256 checksums and a release attestation JSON. Pipelines that pin OpenCode should record those digests.

The repository lists the install channels: a curl install script, npm i -g opencode-ai, Homebrew, Scoop, Chocolatey, pacman and the AUR, mise, and nix. The auto-update change does not land evenly across them. Package-manager installs were already explicit, so the behavioral shift hits script- and binary-installed machines hardest — exactly the population least likely to have a patch owner.

What operators should do now

• Inventory install channels. Find the script- and binary-installed machines first; they were the ones receiving silent updates.
• Assign a patch cadence and an owner. Decide how often each lane runs /update or its package manager, and who approves.
• Stage OpenCode 2 separately. Keep opencode upgrade --major out of routine patching; give it its own canary and rollback note.
• Prioritize the PTY fix anywhere sessions cross process or host boundaries.
• Record checksums and attestations for every pinned build so rollbacks are verifiable.

OpenCode occupies a broad middle ground in the open-source harness field we track — more install channels than most, and one of the largest star counts in the category. With v1.19.0, its update semantics move closer to the pinned-fleet model operators already run for Claude Code and Codex. The gate is now yours to open.