Hermes v0.22.3–0.22.4 makes session auto-pruning opt-in for unset settings and improves plugin-update discovery. It does not reset explicit retention preferences or make plugin updates automatically safe. Before upgrading a persistent agent, check what it will delete, what code it will update and which distribution actually delivers the release.
The October 21 v0.22.3 release and v0.22.4 follow-up form one operational patch event here. This is not another recap of the v0.22.0 local-model and connector launch. That earlier article describes the older release’s retention default; the version-specific behavior below is the important change.
Retention defaults changed, existing choices did not
The sessions documentation at the v0.22.4 tag defines sessions.auto_prune as off by default. Crucially, explicit existing values are preserved. Only an unset key follows the new default.
| Your setting | What the new default means | Operator decision |
|---|---|---|
| Unset | Automatic pruning is off | Choose a retention policy deliberately |
| Explicitly false | Your off setting is preserved | Keep enough disk capacity for history |
| Explicitly true | Your on setting is preserved | Review the retention window and backups |
When enabled, pruning removes ended sessions inactive beyond sessions.retention_days, which defaults to 90 days. Startup maintenance can run through CLI, gateway or cron entry points. Do not assume that upgrading changes an existing true to false, or that an infrequently used conversation is a backup.
The docs also distinguish stale automation-owned open-session cleanup from later pruning. Avoid a blanket promise that every session marked open is permanently exempt from maintenance.
A low-disk prompt is not a retention policy
For an unset auto-prune setting, Hermes can offer a low-disk prompt. The documented thresholds are under 2 GB free, or below 10% free when less than 20 GB remains. The in-Hermes slash commands let you inspect or choose the behavior:
/autoprunedisplays the state./autoprune onenables pruning./autoprune offkeeps history and suppresses further prompts./autoprune laterdefers the reminder for a week.
These are Hermes conversation commands, not commands to paste into your operating-system shell. My recommendation is to set the policy before a disk-pressure incident: decide which history must be retained, verify a backup and document who can authorize deletion.
Deleting SQLite rows does not necessarily return the database file’s space to the operating system immediately. Retention, database optimization, backups and privacy deletion are different tasks. Do not reach for a forced database operation just because a disk graph has not dropped; follow the documented process-holder restrictions first.
Checking plugins and applying updates are separate actions
The tagged plugin guide documents a read-only discovery step:
hermes plugins check-updatesThat command does not change plugin files. Applying an update is a separate operation. hermes plugins update lists eligible updates and requests a batch confirmation in a terminal; hermes plugins update NAME targets a specific plugin.
Batch confirmation does not replace all subsequent review. New capabilities, widened reviewed catalog pins and scan findings can still require plugin-specific consent. Non-interactive --yes is not a blanket grant of new capabilities. Scheduled update checks also differ from the separate plugins.auto_apply: true opt-in for unattended tracked Git updates.
My recommendation is to begin with the check, inspect the proposed changes, then update one required plugin in a test profile before considering a batch. Do not treat discovery as authorization to install third-party code.
Provenance and pinning still matter
Pinned plugins remain pinned. Manually copied, drifted, unknown and pip-distribution installations are not silently converted into managed Git updates. A self-cloned installation needs an explicit adoption step before it becomes tracked.
A new or changed update source requires review before hermes plugins trust-update-url NAME. That command is a trust decision, not an error-clearing shortcut. Confirm the repository owner and expected update destination before accepting it.
Most importantly, scans and capability consent are not a sandbox. Plugins run as in-process Python; malicious code can ignore cooperative gates. A scan that finds no known problem does not prove a plugin harmless. Keep sensitive profiles and production credentials out of an unreviewed plugin evaluation.
Check the delivery channel before expecting the fix
Both release pages state that bundled .exe and .dmg Desktop packages are unchanged for these releases and wait for the next bundled release. Do not assume a desktop installer immediately includes the same backend as the latest GitHub tag.
Store installations update through the Store; CLI installations have their own updater or installer route. Docker and Hermes Cloud reference moving stable/latest images, which are not reproducible version pins. Check the actual version and installation owner rather than applying the CLI path to every desktop package.
The full curated patch notes are deferred to v0.23.0. This article relies on the current release summaries and exact-tag documentation, not an invented complete feature list or a claim that FindMilan tested your deployment.
My pre-upgrade acceptance checklist
- Record the running version, distribution channel, explicit retention settings and installed plugin sources.
- Back up required history and verify that it can be recovered before changing retention or plugin code.
- Read the update list without applying it. Review source changes, pins and requested capabilities.
- Upgrade through the distribution’s supported route; verify the backend version that actually starts.
- Recheck the effective pruning setting and run one harmless plugin task plus one representative scheduled task.
- Confirm the destination result and preserve the prior approval boundaries before resuming consequential work.
For help separating retention, third-party code and agent permissions, see AI consulting, workflow automation and the Hermes and OpenClaw setup project.
Frequently asked questions
Does upgrading to Hermes v0.22.4 turn off existing session pruning?
No. The off default applies to an unset key. Explicit true and false values are preserved, so inspect your actual configuration.
Does hermes plugins check-updates install anything?
No. It is read-only. Applying updates is separate, and batch consent does not remove plugin-specific review requirements.
Do plugin scans make third-party Hermes plugins safe?
No. They are not a sandbox. Review provenance and source before trusting code that runs inside the agent process.
Do bundled Desktop users receive these changes immediately?
Not necessarily. These release pages defer bundled .exe and .dmg changes to a later bundled release. Check the backend version you actually run.
Frequently asked questions
Does upgrading to Hermes v0.22.4 turn off existing session pruning?
No. Automatic pruning defaults to off for an unset sessions.auto_prune key, but explicit existing values are preserved. An existing true value remains a separate retention decision that you should inspect.
Does hermes plugins check-updates install anything?
No. It checks without changing plugin files. Applying updates is a separate operation, and batch confirmation does not remove per-plugin capability, catalog or scan review requirements.
Do plugin scans make third-party Hermes plugins safe?
No. Scanning and capability consent are not a sandbox. Plugins run as in-process Python, so review their source, provenance and permissions before trusting them.
Do bundled Desktop users receive these changes immediately?
Not necessarily. The v0.22.3 and v0.22.4 release pages say bundled .exe and .dmg Desktop packages are unchanged until the next bundled release. Verify your actual backend version and distribution channel.