Updating

sigil update

Fast-forwards the git clone at ~/.sigil/app to the latest release branch, reinstalls dependencies, runs pending migrations, and restarts the daemon.

Flag
--check	Report whether an update is available; don’t apply it
--force	Re-pull and reinstall even if already current

Why git rather than npm

Sigil is persistent infrastructure — a background daemon plus editor hooks pinned to a path on disk. It installs as a git clone and updates with a fast-forward under the hood; pushing to the release branch is the release.

npx/pnpx was never viable: those run from a throwaway cache your package manager later deletes, which would silently break memory. Sigil detects an ephemeral install directory and refuses to set up from one.

What it touches

~/.sigil/app	Fast-forwarded to the release branch
Dependencies	Reinstalled
Database	Pending migrations applied
Daemon	Restarted so the new code takes effect
~/.sigil/config.json	Untouched — your configuration survives
Your memory	Untouched

Config schema changes are handled by ordered migrations that run on load, so an older config.json upgrades itself. Unknown keys are dropped.

Migration rollback

If a migration fails, the update rolls back rather than leaving you half-upgraded on a schema the new code doesn’t understand.

update rolled back after a failed migration — fix the migration and re-run `sigil update`.

Your install stays on the previous version and keeps working.

Update notifications

The daemon checks periodically and writes ~/.sigil/.update-available. CLI commands surface it:

⬆ Sigil update available — run `sigil update`

Switch it off in Settings → General → Skip update checks (preferences.noUpdateCheck). That’s also the only outbound call Sigil makes on its own.

After updating

sigil doctor

Usually nothing else is needed. If a hook or MCP entry has gone stale:

sigil connect

After a Node version switch

This is the one that catches people. Switching between Node versions with nvm or fnm — or reinstalling Node entirely — moves the paths agent configs were written with.

sigil connect

Re-pins the launcher shims in ~/.sigil/bin/ to the current install and re-syncs every client’s generated config. It touches no database, no provider, and no API key.

This is why the shims exist

Every integration points at ~/.sigil/bin/, never at a versioned package path. The shim resolves the real binary at runtime, so most Node switches survive without intervention. sigil connect is for when the shim itself needs re-pinning.

Updating a multi-device setup

Update each install independently. Migrations are idempotent — the first machine to run them applies the change; the rest find the schema current.

Update the machine that runs migrations first if one of them is clearly the primary. Older installs continue to work against a newer schema for the common case of additive migrations, but don’t leave them behind indefinitely.

sigil update --check     # on each machine

Not a git install

If Sigil was installed some other way, update refuses rather than guessing:

sigil update needs a git install, but this copy is not a git clone.
Reinstall with the official installer so updates work:
  curl -fsSL https://raw.githubusercontent.com/Anmol-Srv/sigil/master/install.sh | sh

Reinstalling over an existing install preserves ~/.sigil/config.json and your database.

Rolling back

~/.sigil/app is a git clone, so:

cd ~/.sigil/app
git log --oneline -10
git checkout <previous-tag-or-sha>
sigil daemon restart

Applied migrations are not reverted. Rolling back across a schema change needs npx knex migrate:rollback from that directory — check what the migration did before you do.