Yeah, this is not healthy behavior, and the logs do show a few concrete things that would cause exactly the spiral you’re describing.
The biggest one is that your instance is set to compression.threshold: 0.1. That is extremely aggressive. In the logs, the gateway is repeatedly doing flush_memories, then compression, then Session split detected, with very long runs like api_calls=71, api_calls=54, api_calls=90. That will absolutely make the agent feel unstable and forgetful.
There is also a more serious line earlier in the full log:
Context compression: no provider available for summary. Middle turns will be dropped without summary for 600 seconds.
That is a direct context-loss path. If compression is firing constantly and summary is unavailable, Hermes will shed middle context and the agent will start acting like it forgot what you already told it.
The approval side is also not matching “no confirmation gates.” Your Telegram logs show both choice=always and later choice=session approvals. That means the gateway did have standing permission to keep executing dangerous write commands in those sessions. That does not make the resulting behavior okay, but it does explain why it kept writing after you expected it to stop.
The desktop CLI side is not clean either. It logged Agent thread still alive after interrupt, so the CLI run was also in a bad state.
So the next move here is to stop using this runtime state and reset the environment before trusting it with any more writes.
Do this first:
- Update Hermes. You are on
0.10.0 (2026.4.16), and there have been fixes after that in the flush/compression/interrupt/drain area.
- Raise compression back to something sane:
hermes config set compression.threshold 0.5
- Force approvals back to manual:
hermes config set approvals.mode manual
- Clear any permanent dangerous-command allowlist:
hermes config set command_allowlist []
- Pause the active cron jobs so broken scripts stop running:
hermes cron list
then
hermes cron pause <job_id>
- Restart the gateway
- Start a fresh chat session after restart. Do not resume old sessions for testing, and do not use
session or always on approval buttons while you are validating behavior.
If you are doing code work in a git repo, also turn on isolated worktrees:
hermes config set worktree true
And if checkpoints are enabled, use /rollback to recover files instead of asking the same unstable session to repair its own damage.
One important correction from the logs: I cannot confirm from these pastes that Hermes is literally loading 100% of all memory files on every turn. What I can confirm is repeated compression/splitting plus at least one explicit “drop middle turns without summary” condition, and that alone is enough to explain the context-loss behavior you are seeing.
After you reset it, the only thing to retest first is a simple no-tool memory check in a fresh session. If it still starts splitting/compressing aggressively or free-writing after that reset, send one fresh hermes debug share from after the restart and we can look at the new clean-state behavior instead of the already-corrupted runtime.
olive mist
livid bear
