OpenCode Windows — signed MSI, winget, and native ARM64.

Installing OpenCode on Windows.

OpenCode Windows supports three install paths: winget, the signed MSI, and the chocolatey portable. Each is appropriate for a different deployment posture.

For an individual developer on a laptop, winget install OpenCode.OpenCode is the fastest path: it fetches the signed MSI from the OpenCode download host, verifies Authenticode, runs the installer quietly, and adds opencode.exe to the system PATH. For a managed fleet, the MSI drops into Group Policy or Intune with a published ADMX template and pushes to every workstation without interactive prompts. For engineers who are not allowed to run MSIs, the chocolatey portable unpacks into a user-scoped directory and does not require administrator rights. All three paths land the same pinned release.

MSI and winget.

The OpenCode Windows MSI is signed with Authenticode and registered in winget as OpenCode.OpenCode. An end-to-end install is a single command.

# winget
winget install OpenCode.OpenCode

# Silent MSI
msiexec /i OpenCode-v2026.4.0-x64.msi /qn

# ARM64
msiexec /i OpenCode-v2026.4.0-arm64.msi /qn

# Verify
opencode --version
opencode doctor

After the MSI completes, open a new PowerShell window. opencode --version should print the pinned release, and opencode doctor reports the platform, the signature chain, the provider, and the sandbox policy. The PowerShell completion script lands in the user's module path and is picked up on the next shell.

PowerShell completions on OpenCode Windows.

The MSI installs a PowerShell completion module automatically. The completion script is generated by the CLI itself so it stays current for every release.

The module adds tab completion for every subcommand, flag, and model alias. Open a new PowerShell window after install and tab-complete opencode pr to see plan, apply, and revert. Users who prefer to regenerate the completions by hand can run opencode completion powershell | Out-String | Invoke-Expression and drop the result into a $PROFILE block. Completions survive a version upgrade because the module is regenerated on every install.

Command Prompt and Windows Terminal.

OpenCode Windows runs in Command Prompt, PowerShell, and Windows Terminal. Windows Terminal is the recommended default because its truecolor and tab handling match the modern terminal UX the agent was designed for.

On Windows Terminal, OpenCode Windows detects the terminal type and enables the full inline-diff view with colorized headers, folded context, and live tool progress. On legacy Command Prompt, the agent falls back to a plain-text layout but keeps every feature functional. The choice of shell does not change the agent's behavior — only the density of the UI on screen.

Native ARM64 OpenCode Windows builds.

OpenCode Windows ships a native ARM64 MSI for Snapdragon-based Copilot+ PCs and other Windows-on-ARM devices. Windows emulation is not required.

The ARM64 build is the same CLI, the same protocol, and the same release cadence as x64. Binary size is slightly smaller than x64 because the ARM64 code density is tighter, and startup time on a Snapdragon X Elite is measurably faster than x64-under-emulation on the same device. Endpoint management teams running mixed fleets pin both MSIs and let winget or SCCM pick the right one per device. Developers on ARM64 laptops do not need to know the difference — the winget manifest handles architecture selection.

WSL2 path.

OpenCode Windows and the WSL2 Linux build coexist on the same machine without conflict. Many developers run both.

The Windows build sits in %ProgramFiles%\OpenCode and the WSL2 build sits in /usr/local/bin/opencode inside the Linux distribution of choice. The two binaries share no state and do not race on a config file. The WSL2 path is the right pick when the developer's workflow is primarily Linux-toolchain: building a C library, running a bash-based test suite, or targeting a Linux container. The Windows path is the right pick when the workflow is primarily Windows: Visual Studio, .NET, or PowerShell-heavy automation.

Group Policy and endpoint management for OpenCode Windows.

Large Windows fleets manage OpenCode Windows through Group Policy or Intune. The ADMX template publishes every relevant knob: auto-update pinning, telemetry disable, provider endpoint lock, and sandbox policy.

Dropping the ADMX into the central policy store unlocks a new OpenCode section in the Group Policy Management Console that sits next to other developer-tool templates. Each setting maps to a documented registry key under HKLM\SOFTWARE\Policies\OpenCode; admins who prefer to push configuration through Intune configuration profiles or a custom CSP can read the same registry keys directly. The posture aligns to NIST supply chain risk management guidance, which is the framework most Windows-heavy regulated customers already cite in procurement.

Smart App Control and Defender.

OpenCode Windows is signed with an Authenticode certificate that is trusted by Smart App Control out of the box. Microsoft Defender SmartScreen sees the signed publisher and approves the install without a warning prompt.

On a fresh Windows 11 machine with Smart App Control in enforcement mode, winget install OpenCode.OpenCode completes without a manual override. On a machine with Defender Application Guard, the MSI installs under the guarded container if the policy allows it, and the CLI runs under the same confinement. These defaults matter: they are what makes OpenCode Windows deployable on laptops issued to interns without a helpdesk ticket for every install.