You found a package your project should follow. This page adds it to the project, records the exact version, and shows how to check that your agent will now read it.
The agent runs `vibe install org.vibevm.world/wal`. vibe walks the project's [registries](../glossary/index.xml#registry) in order and asks the first one that knows the package for its versions; with no constraint given, it picks the newest stable release. It resolves the package's own dependencies with the rest of the project's graph, fetches everything that is not yet in the machine [store](../glossary/index.xml#store), and verifies each [fingerprint](../glossary/index.xml#fingerprint). Then it prints a plan: which packages will be added at which versions, and which files will change. Nothing is written until you confirm. On confirmation vibe copies the packages into `vibevm/vibedeps/`, records the requirement in `vibe.toml` and the pins in `vibe.lock`, and regenerates the boot files. Then the agent runs `vibe tree` to show you the new reading list.
1. Install by [coordinate](../glossary/index.xml#coordinate). Add `@` and a constraint to ask for a range or an exact version:
2. Confirm the plan when asked. `--assume-yes` answers yes for scripts and agents.
3. Check what was recorded and what the agent will read:
`vibe install org.vibevm.world/wal@^1.0` accepts any 1.x; `@=1.0.0` accepts exactly one; `--exact` writes the resolved version as an exact pin into the [manifest](../glossary/index.xml#manifest) instead of a range. The manifest keeps the constraint you asked for; the [lock file](../glossary/index.xml#lock-file) keeps the version you got.
A kind prefix, as in `flow:org.vibevm.world/wal`, is optional; when present, vibe checks it: if the package turns out to be of another kind, the install stops.
`vibe install` with no package names installs what the manifest already requires, at the versions the lock file pins. When neither the manifest nor the lock changed since the last install, vibe does not even run the resolver: the lock file is the answer, and the command only checks that the tree matches it.
Installing a package by name re-resolves the whole graph, but every dependency the change does not touch keeps its pinned version; only a real conflict triggers a full re-resolution.
A package may declare a script to run after it is installed. Installing the package is the consent to run it; the script runs inside the package's own folder and its effects are not tracked. Read the manifest of a package you do not trust before installing it.
A package that is already installed is not installed twice: vibe says so and points at `vibe update`.
A public registry that answers with an authentication error for a missing package is walked past, not treated as a failure; add `--auth-required` in a script that must notice a private registry being down.
A package that delivers tools is recorded at install and built on demand: `vibe bin build` compiles the named tools, or all of them, from the exact installed package, and `vibe bin exec <name>` resolves the tool through the project's lock file to its folder and runs it, building first if needed. Installing the package is the consent to build, and vibe narrates what it is about to compile. Offline, a build that needs crates from the network fails the way Cargo fails, with the manual recipe as a hint. When your own code needs a shipped crate, reference it by path into the package's folder, and keep `vibevm/vibedeps/` out of your Cargo workspace, because a folder cannot belong to two workspaces.