Update check logic, caching, and version reporting bugs
NousResearch/hermes-agent · cluster 1620 · apps/desktop
Data as of
14 open items. Fix merged in #1637. Check it covers your case.
The short answer
- Known?
- Yes. 41 related items grouped here, 13 issues already closed.
- Fix event
- A fix was merged to main in PR #1637. Check it covers your case. No release data is tracked.
- Tracker
- The maintainers' tracker marks this
partially resolved, deciding PRs #1637, #34846. That is separate from the fix event. - Still open
- 6 issues and 8 PRs.
Next step: read #1637, then check whether your report is one of the 6 still open.
Read #1637Pick up a Lab taskThese issues and PRs concern problems with how the update checker determines the latest version (main vs. release tags), stale or incorrectly keyed update-check cache behavior, and false 'commits behind' warnings shown to users. A few adjacent items touch Windows update behavior and stable release cadence proposals.
Open issues6
- Issue#8063[Feature]: Add fixed-cycle stable version release mechanism (monthly/optional weekly)
- Issue#16640[Feature]: Docker stable releases
- Issue#20728Bug: TUI banner shows stale "N commits behind" after successful `hermes update`
- Issue#23681[Bug]: Update check cache hides commit list until ~/.hermes/.update_check is manually deleted
- Issue#23721[Feature]: "hermes update" command need support tag parameter.
- Issue#39771hermes version shows '860 commits behind' after checking out latest tag v2026.5.29.2
Open PRs8
- PR#11329fix: invalidate update cache in _update_via_zip path (#11327)
- PR#23699fix: don't cache failed update checks; sync cache on explicit --check
- PR#27844fix(update): key update-check cache by git HEAD
- PR#39776fix(version): suppress false 'commits behind' warning on detached HEAD (tag checkout)
- PR#40999fix: invalidate update cache using local HEAD (fixes #40944)
- PR#41012fix(cli): invalidate update cache when source HEAD changes
- PR#41043fix(cli): bust update-check cache when local HEAD moves
- PR#43824fix: clarify update status for branch and tag checkouts
Fixes on record
-
#1637 fix(cli): invalidate update-check cache after hermes update
files:
hermes_cli/main.pyShow the diff
-
hermes_cli/main.py@@ -2124,7 +2124,17 @@ def _restore_stashed_changes( print(" Review `git diff` / `git status` if Hermes behaves unexpectedly.") return True - +def _invalidate_update_cache(): + """Delete the update-check cache so ``hermes --version`` doesn't + report a stale "commits behind" count after a successful update.""" + try: + cache_file = Path(os.getenv( + "HERMES_HOME", Path.home() / ".hermes" + )) / ".update_check" + if cache_file.exists(): + cache_file.unlink() + except Exception: + pass def cmd_update(args): """Update Hermes Agent to the latest version.""" @@ -2197,6 +2207,7 @@ def cmd_update(args): commit_count = int(result.stdout.strip()) if commit_count == 0: + _invalidate_update_cache() print("✓ Already up to date!") return @@ -2217,6 +2228,8 @@ def cmd_update(args): prompt_user=prompt_for_restore, ) + _invalidate_update_cache() + # Reinstall Python dependencies (prefer uv for speed, fall back to pip) print("→ Updating Python dependencies...") uv_bin = shutil.which("uv")
-
-
#34846 feat(cli): warn on unsupported pip installs + fix stale update-check cache (#34491)
files:
hermes_cli/banner.py,tests/hermes_cli/test_pip_install_detection.py,tests/hermes_cli/test_update_check.py,website/docs/user-guide/features/code-execution.md
12 PRs closed without merging
From the close comments: done elsewhere 2 · duplicate 2 · superseded by another PR 2 · closed without comment 1 · partial fix 1 · other 4
- #11451 Fix stale update cache after successful updates · other
-
#20792 fix(banner): bind update-check cache to local HEAD so banner refreshes after hermes update (#20728) · superseded by another PR →
#20653 -
#21447 fix: invalidate stale update-check cache · duplicate →
#18236,#9670,#5359,#11327,#21675 -
#22256 Fix stale update cache invalidation for custom HERMES_HOME · done elsewhere →
4a65c9c,#21526 -
#23259 fix(update): clear update cache under custom HERMES_HOME · done elsewhere →
4a65c9c,#22256,#21526
Show 7 more
- #23700 fix(update): show pending commit list in --check output and banner · other
-
#34501 fix(cli): invalidate update-check cache when installed version changes · superseded by another PR →
689ef5e,#34846,#34491 - #38103 fix(version): bump main branch to 0.15.2 to match latest release tag v2026.5.29.2 · other
-
#38619 fix: bump version from 0.15.1 to 0.15.2 to match release tag v2026.5.29.2 · duplicate →
#38103 - #40985 fix(banner): invalidate update-check cache when local git HEAD moves · closed without comment
-
#107496 feat(update): support configurable stable branch tracking · partial fix →
b0c7613,38c9611,#58746 - #113278 feat(update): stable-release default channel with install-scoped record and Desktop selector · other
Closed issues · 13
- Closed#1620[Bug]: `hermes --version` shows "26 commits behind" when already on latest
- Closed#11007Stale update cache: banner shows 'N commits behind' after updating
- Closed#11327Banner shows stale 'commits behind' after successful update — .update_check cache not invalidated
- Closed#21526hermes update: stale 'commits behind' banner persists for custom HERMES_HOME profiles
- Closed#27841Update check cache can report stale commits-behind after git pull
- Closed#34491check_for_updates() cache not invalidated after pip upgrade, showing stale "1 commit behind"
- Closed#34514[Feature]: hermes update should track the latest release, not the latest main commit
- Closed#38093[Bug]: main branch reports 0.15.1 after v2026.5.29.2 release
- Closed#38618Update reports 7 commits behind / remains on 0.15.1 when main differs from latest release tag 0.15.2
- Closed#40944Banner shows stale "commits behind" count after manual git pull in source installs
- Closed#49611[Feature]: Do Not Automatically Update Windows Desktop on Startup
- Closed#52814[Feature]: Update to latest tagged release
- Closed#58746feat(hermes): hermes update should target the latest stable release, not main
How this cluster was grouped
-
Link evidence (
partly structural links): some members are connected by structural evidence (shared changed files, or a closing/superseded reference); the rest are joined by an automated relevance judgement over their text. - Members outside that structural core may belong to a different underlying problem.
-
Pairwise link density
0.05: the share of item pairs that carry a link, counting a structural link in full and a relevance-only link at 0.36.1.00means every pair is linked.
Pick up a Lab task
Check whether a fix covers the open issues here, with your own agent. Bring back evidence for maintainers.
Open the Lab