sf update

Update sf to the latest version

sf update

Upgrades sf in place, using whichever installer put it there. How it was installed is detected, not assumed — pip install --upgrade inside a uv tool environment writes packages uv’s receipt does not know about, which is worse than doing nothing.

sf update --check    # report only, change nothing
sf update --pre      # consider pre-releases

What it does for each installation

Installed with	sf update
uv tool install	Upgrades it. The recommended installation
pipx install	Upgrades it
pip into a virtualenv of your own	Upgrades it, with uv if uv is on the path
pip into a project’s .venv next to a uv.lock	Refuses. Upgrading in place would leave the lock file describing a version that is no longer there. Run uv lock --upgrade-package starforge-core && uv sync instead
pip into the system Python	Refuses. An upgrade there can affect other tools. Reinstall with uv tool install starforge-core
a source checkout	Refuses. Use git pull

A refusal names the command that would work, so sf update never leaves you without a next step. This is the reason to prefer uv tool install: it is the installation with nothing in the way of an upgrade.

Keep the CLI close to the server. sf version prints both, and the JobSpec dialect the server speaks; a CLI that speaks a different dialect cannot submit at all, and says so.

sf update

Update sf to the latest version

sf update [options]

Option	Description
--check	Only report whether a newer version exists; change nothing
--pre	Consider pre-releases as well