Upgrading
A native install keeps itself current, and jevlin upgrade does the same by hand: the release is downloaded from the project's GitHub releases, its signature and checksum verified, and the new binary run before and after it is installed. An npm install is npm's to update.
The daily check
Once a day, when an agent session starts or ends, Jevlin checks the project's GitHub releases for a newer one. If there is one, a native install replaces its own binary with it, the same careful way jevlin upgrade does: signature and checksum verified, the new binary run before and after, the old one kept as jevlin.previous, nothing else touched. The check contacts nothing but GitHub and sends no credential.
To be told instead, or to turn the check off, add to your config:
[update]
mode = "notify" # or "off" to stop the check; the default is "apply"
Under notify, jevlin status and jevlin doctor say a release is available and give the command that installs it. The default installs a release nobody on this machine has looked at, on the strength of the project's release signature, checked against a key built into the copy you already have; choose notify where you would rather pick the moment yourself. An npm install is never replaced this way; the check only notes that a release exists, and jevlin status and jevlin doctor tell you to run npm's command.
jevlin status says when it last checked and what it found. jevlin doctor's up to date line says the same, and says so when the check has not run for three days. That usually means no agent with the hooks has been opened, or that your agents' hooks reach the network through a proxy on this machine, where no check is started: Codex's sandbox does that, and a check from inside it would break the Codex command running. Restart open agents after an upgrade.
If a release misbehaves, jevlin upgrade -rollback puts the previous binary back, and the daily check then leaves the release you rolled back from alone: it installs the next newer one, and jevlin upgrade by hand installs any release you ask for and lifts the hold. If an automatic upgrade ever fails so badly that the old binary could not be put back, jevlin status and jevlin doctor say so and list the copies left beside the binary, none of them deleted; reinstall from the releases page or put one back by hand, and no automatic check runs until jevlin upgrade succeeds.
The daily check arrived in v0.4.0, telling only; v0.4.1 signed releases and made apply the default. A copy on v0.4.0 keeps that release's default and only tells you about newer ones until jevlin upgrade has installed one. An older Jevlin refuses a config that names the [update] key, as it refuses any key it does not know, so add it only once v0.4.0 or later is installed. See the changelog.
By hand
jevlin upgrade # the latest release
jevlin upgrade -version X.Y.Z # exactly that release, never an older one
jevlin upgrade -rollback # put back the binary the last upgrade replaced
npm install -g @jevlinsearch/jevlin@latest # an npm install is updated with npm
upgrade downloads only from the project's GitHub releases, checks that checksums.txt is signed by the project's release key and that the download matches it, and runs the new binary before and after installing it. A release without that signature is refused. The release that first carried the check, v0.4.1, was installed by the copy before it, which checked the checksum only; every upgrade after it checks the signature too. It keeps the old one as jevlin.previous; -rollback swaps back with no network. It refuses an npm copy and a development build, takes at most three minutes, and never touches your wallet, registration or config.
The new binary then rewrites the skills and hooks this installation set up, and for Codex the block in ~/.codex/config.toml. An earlier version's block, which opened Codex's network to every host, becomes the permission profile without a question; a setting of your own that the profile would change is left and printed for you to change by hand. If that step fails, the upgrade still succeeded, and the message gives the command that finishes it. Restart open agents.
When it fails
The first word after upgrade: says what to do:
| word | meaning |
|---|---|
retry | Try again later; nothing changed. A slow first run, such as a virus scan, ends here. |
release_invalid | The release itself is wrong. Do not retry blindly. |
ownership | This copy is not one upgrade may replace, such as an npm install. |
filesystem | Fix the permissions or the file it names. |
lifecycle_busy | Another setup or upgrade is running. |
refused | An older version was asked for. |
manual_intervention | Putting the old binary back failed too. Every surviving copy is listed; none is deleted. |
On Windows, previous_in_use means an older Jevlin or agent process still runs jevlin.exe.previous. Your binary was put back; close that process and run upgrade again.
After an upgrade
jevlin version # the version now installed
jevlin agents status # every agent's files are current
jevlin doctor # one line per check
Running jevlin setup again is never required after an upgrade, but it is safe: it keeps everything and updates its files in place. See Setup in detail. How the check records what it did, and where, is on Files and locks.