Updating BharatCode

Checking for an update

Run bharatcode update with no flags to compare the commit this binary was built from against the latest upstream release. It is a single, best-effort HTTP call that never mutates the install — it only reports whether you are behind, and how to update a source install.

$ bharatcode update

If you are current, it says so; if a newer release exists, it tells you and points you at --apply.

Installing with --apply

Pass --apply to actually install a newer release. When an update is available BharatCode downloads the latest release binary for your platform, verifies it, and replaces the running executable in place. When you are already up to date, --apply changes nothing and says so.

$ bharatcode update          # check only — nothing is changed$ bharatcode update --apply  # download, verify checksum, replace in place

Checksum verification

Self-update is checksum-gated. Before writing anything, --apply verifies the downloaded binary's SHA-256 against the release's published digest. A mismatch hard-fails the update and leaves your existing binary untouched — a corrupted or tampered download can never overwrite a working install.

When update is a no-op

Two situations make update (and --apply) deliberately do nothing:

• Offline mode. Probing GitHub or downloading a release is network egress, which offline mode promises will not happen. The command prints the offline banner and exits cleanly.
• Unstamped builds. A binary built without version/commit stamps — for example one produced by go install — has no baseline to compare against, so the self-update path is skipped. Update those with the same tool you built them with.

Auto-update on startup

To keep BharatCode current without thinking about it, set auto_update to true under options in your config. On each launch BharatCode does a best-effort, time-bounded check and, if a newer release exists, downloads and installs it — the same checksum-verified swap as --apply.

{  "options": {    "auto_update": true  }}

It is off by default: the binary never mutates itself unless you opt in. The same guards apply — the startup check is skipped in offline mode and for unstamped builds — and, as with --apply, the on-disk swap takes effect on the next start rather than mid-session.