Install vibe
01vibe is one program with no runtime to install. On Windows you download an archive and unpack it; on any platform with a Rust toolchain you build it from the source. When it is done, one command prints the version.
Install vibe on this machine: on Windows from the latest release archive at github.com/vibevm/vibevm, otherwise by building the source checkout with its first-run script. Then open a new shell and confirm that `vibe --version` prints a version.network access to github.com; on a platform other than Windows, git and a Rust toolchain
vibe --version prints vibe 1.0.0 in a new terminal, and vibe self doctor reports no problems
vibe --versionvibe self doctor
What happens
03On Windows the agent downloads the release archive, unpacks it, and runs its installer script. The script imports the binary into vibe's own managed folder under ~/.vibe/opt, marks it active, and adds one folder of small launcher scripts to your user PATH. Everywhere else the agent clones the source repository and runs its first-run script, which builds the program and installs it through the same manager. Either way, the result is the same layout: versions under ~/.vibe/opt/vibevm/, launchers in ~/.vibe/opt/bin/, and a pointer that says which version is current.
04 spec: $VIBEVM_INSTALL_ROOT (the install BASE) defaults…
$VIBEVM_INSTALL_ROOT(the install BASE) defaults to~/.vibe→ root~/.vibe/optin normal use (owner ruling 2026-08-20, the release-1.0 install path; until then the default base was the bare home dir →~/opt). An explicit override keeps its meaning —<override>/opt— and one env var still relocates everything; tests pin it to a temp dir. A managed binary keeps recognising its own root by shape (the trailingoptcomponent), so both generations of store keep working.
05vibe runs on Windows, macOS and Linux. The one-line cold start is a script at a stable address: https://vibevm.org/install.sh for Bash, install.ps1 for PowerShell, and install.cmd for cmd.exe. From cmd.exe, run curl.exe -fsSL https://vibevm.org/install.cmd -o "%TEMP%\vibevm-install.cmd" && call "%TEMP%\vibevm-install.cmd". Both Windows entry points use the same verification path: the CMD launcher downloads a size- and time-bounded copy of the PowerShell script, which downloads the release manifest, verifies a small bootstrap binary by size and digest, and hands control to that binary to verify and install the full bundle. Package managers such as Homebrew and WinGet come later.
06 quote from the specification
Decision: M0 builds and runs on macOS, Linux, and Windows.
07 spec: Stable endpoints provide one-line native cold…
Stable endpoints provide one-line native cold start: Bash for Linux/macOS/WSL, and either PowerShell or cmd.exe for Windows. The CMD entry point first downloads a bounded copy of the PowerShell installer, then invokes that same script, so both Windows shells share one verification and installation path. That path downloadsDISTRIBUTIONS.json, verifies a small rawvibebootstrap by size/SHA-256, then that Rust binary verifies and atomically installs the full bundle.
By hand
On Windows
091. Download vibe-<version>-windows-x86_64.zip from the releases page of github.com/vibevm/vibevm.
102. Unpack the archive into a folder of your choice.
113. In that folder run the installer:
134. Open a new terminal, so that the changed PATH is read.
145. Check the result:
16The archive also contains SHA256SUMS.txt. Compare the digest of vibe.exe with the line in that file before you run the installer. The installer does the same check.
From the source, on any platform
171. Install git and a Rust toolchain. OpenSSL is not needed.
18 spec: A from-source build needs git…
A from-source build needs git, a Rust toolchain (rustc + cargo,
stable ≥ 1.93, edition 2024 — via rustup so the pin resolves), and a
system linker / C toolchain (Windows: VS Build Tools; macOS: Xcode CLT;
Linux: build-essential). A native binary install needs none of those;
its bootstrap uses only the platform download/TLS facilities.
192. Clone the repository: git clone https://github.com/vibevm/vibevm.git and enter the folder.
203. Run the first-run script: bash tools/first-run.sh on Linux and macOS, .\tools\first-run.ps1 on Windows. It builds the program, installs it into the managed store and sets up the launchers.
214. Open a new terminal and run vibe --version, then vibe self doctor.
22Later, vibe self update follows the running installation's origin: a binary installation checks the newest release, while a source installation rebuilds its source checkout. vibe self reinstall refreshes the current version. vibe self ls lists the versions on the machine, and vibe self rollback returns to the previous one.
23 spec: self install <selector> —…
self install <selector>— from a source execution, build the selected ref; from a managed binary execution, an explicitX.Y.Zinstalls that native release. Flags:--release/--profile <debug|release>(source lane);--mirror <gitverse|github>(force the source lane);--force(always allocate a fresh immutable#N).
Watch an update
24vibe self update shows whether it is downloading a binary or building from source, the current component and elapsed time. Downloads have a byte counter when their size is known. Source builds can take substantially longer; the build stage remains visible while Cargo runs. Add --verbose to see detailed operation diagnostics: vibe self update --verbose.
25 spec: The self install/update/reinstall paths identify source…
The self install/update/reinstall paths identify source versus binary acquisition. Source execution observes source discovery/fetch/checkout, prerequisite preparation, each essential binary build, placement and activation. Binary execution observes release metadata, existing-generation verification or reuse, bounded download bytes, extraction/verification and activation. Existing immutable generations, offline admission and injected environment persistence remain unchanged.
Where things go
26vibe keeps everything it owns under one folder in your home directory, ~/.vibe/: the installed versions and their launchers under opt/, the machine store of fetched packages under cache/, registry clones under registries/, and your settings files. Nothing is written anywhere else, and the whole folder can be moved by setting the environment variable VIBE_SETTINGS.
27 spec: The settings home is ~/.vibe
The settings home is~/.vibe(owner, 2026-08-20). This document previously named~/.config/vibe/config.toml; the code has treated~/.vibeas canonical all along and the XDG path only as a legacy location an operator is invited to migrate out of. The correction is to this document, not to the tree.
28The installer never overwrites a running binary and never edits your PATH twice: it adds one entry, guarded by a marker, and leaves the rest alone.
29 spec: never clobber
never clobber (only our entry is added; the rest of PATH is
preserved),
Edge cases and rules
30If vibe --version prints nothing in the terminal where you ran the installer, open a new one: the PATH change applies to new shells only.
31A ready-built binary from anywhere can join the managed store without a toolchain: vibe self import ./vibe.exe --tag 1.0.0 --use.
32 spec: self import <PATH> --tag <X.Y.Z> —…
self import <PATH> --tag <X.Y.Z>— put a legacy READY-BUILT localvibeexecutable into the inventory as an immutabletag:instance, reusing the store/placer/lock/state machinery (built 2026-08-20 for the 1.0.0 distributive; the install.ps1 of the zip calls it instead of duplicatingstate.toml). Local by construction: no network, no signature machinery — the file is streamed through SHA-256 once, and that digest drives idempotence: same tag + same digest reuses the instance; same mutable tag + different digest creates a new local#Nbeside the preserved old one.--replace-candidateremains compatibility spelling. Optional--commit,--profile(defaultrelease); inactive by default —--useruns the same complete shim/PATH/pointer/advisory-HOME activation as every other lane.
33Building an arbitrary git ref is running arbitrary code, as with any build from source. Build from the repository and the branches you trust.
34 spec: Building an arbitrary ref is arbitrary…
Building an arbitrary ref is arbitrary code execution — inherent to a build tool the user invokes deliberately, and accepted.