Updating

The app checks for a newer snowpea core once per launch and tells you in two places: a banner above the screen, and Settings → About.

The banner

When a newer release exists, a strip appears at the top of the window:

Update available 0.1.7 → 0.2.0

• Update starts the upgrade.
• Details opens Settings → About.
• Dismiss hides the banner for that version only. The next release says its piece again.

Settings → About

The card lists the core version, the protocol version both sides agreed on, the update channel the answer came from (pypi or git), and when it was last checked.

• Check now asks the network. The plain launch check does not: the core caches its answer for 24 hours, so starting the app ten times in a morning costs one lookup.
• Update to X starts the upgrade.
• Release notes opens the release page, when the channel has one.

A daemon that outlived its install

The app reuses whatever daemon is already running rather than starting its own every launch, because that daemon holds live sessions, scheduled jobs and gateway bindings. The risk is a daemon that keeps running code you have since replaced: reinstalling the core does not restart it, and neither does restarting the app.

So on every connect the app asks the daemon what it is running and compares it with what is installed — the version, and whether the core's files are newer than the moment the daemon started, which is what catches a reinstall of the same version. If they differ and nothing is mid-turn, the daemon is replaced without asking. If a turn is in flight it is left alone and a strip appears instead:

Core is out of date — restart when idle

Restart replaces it. Nothing is lost by waiting: the running turn finishes on the old daemon, and the next connect makes the same check again.

What "Update" actually does

The core runs the upgrade in a detached process and answers straight away, so the button finishing does not mean the upgrade did. A phase line follows it: started, then done or failed, with the core's own message and the path of the log it wrote.

An upgrade that finishes leaves the daemon still running the old code — a running process cannot swap itself out. Until it is restarted, the version on this card is the old one, which is why a finished upgrade offers Restart core rather than doing it for you. Restarting drops the connection for a moment; the app reconnects on its own.

When it cannot update itself

Some installs are not the core's to modify — a system package, or one managed by Homebrew or pipx. In that case nothing is spawned and the card shows the command to run yourself instead, along with the reason.

A downgrade is refused by the core, not by the app, and the reason is shown the same way.