Identically named memory tools can operate on different state merely because one execution path does not forward a profile setting. In the reported setup, interactive sessions read the intended Mnemosyne store but scheduled runs defaulted elsewhere, producing apparently empty or different context. This does not prove inter-tenant access without a…
Inspect the ClaimsCase · DiggingBeagle record
Hermes scheduled agents may read the default memory bank instead of their configured profile
Scheduled Hermes runs were reported to omit a configured profile environment value and silently use a different memory bank.
Scope
Only one reporter configuration is documented; no verified cross-tenant exposure or released correction is shown.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade D
- AI role
- AGAINST AI
Basis and provenance
The pinned Claim and its primary disclosure support the described controlled result, but do not establish a population-wide rate or calibrated impact. The only available supporting evidence is the reporter's or advisory author's own account; independent reproduction has not been shown. Impact remains unbanded because no calibrated impact rubric for this particular evidence is established.
Assessed Nov 2, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-2026-NOV02-HERMES-CRON-MEMORY-PROFILE-A · Hermes Agent issue 147747: cron profile environment not forwarded
At a glance
Scheduled and interactive workflows need the same explicit memory identity and a verified storage binding, not fallback to a default bank.
Read the implicationsOnly one reporter configuration is documented; no verified cross-tenant exposure or released correction is shown. Whether the same fallback occurs for all scheduler entry points or crosses tenant boundaries has not been shown.
Limits and uncertaintyFull account
Identically named memory tools can operate on different state merely because one execution path does not forward a profile setting. In the reported setup, interactive sessions read the intended Mnemosyne store but scheduled runs defaulted elsewhere, producing apparently empty or different context. This does not prove inter-tenant access without a demonstrated shared profile, but it does undermine consistency and any claim that the same agent has one durable memory across execution paths.
The issue contrasts an interactive Hermes run that loads the configured Mnemosyne location with a cron run lacking the profile's MNEMOSYNE_DATA_DIR. The scheduled agent therefore reads a default, much smaller bank and may write new memories there. Silent fallback is material because the model can appear to have forgotten prior work despite no user-initiated reset. This is a profile-propagation defect in the scheduler, not evidence that two unrelated tenants shared secrets. A correct fix has to restore the chosen memory identity at job admission and verify it before both reads and writes.
Mechanism and trust boundary
- 01
Interactive session selects a memory profile
A profile environment points to the intended Mnemosyne bank.
Boundary: Operator configuration into memory identity
- 02
Cron launches without that variable
The scheduled executor uses a default directory rather than the selected bank.
Boundary: Scheduling boundary into different storage identity
- 03
Agent reads or writes the wrong context
The model receives incomplete history and may persist changes to an unintended location.
Boundary: Storage routing into future agent decisions
Claims & evidence
CLM-2026-NOV02-HERMES-CRON-MEMORY-PROFILE-AThe reporter observed interactive Hermes sessions loading a profile with more than 1,200 memory entries while cron sessions used a much smaller default directory because MNEMOSYNE_DATA_DIR was missing.supported
Basis: reported finding
- supportsHermes Agent issue 147747: cron profile environment not forwardedprimary disclosure
Issue 147747, cron versus interactive environment and Mnemosyne path reproduction
Implications
Scheduled and interactive workflows need the same explicit memory identity and a verified storage binding, not fallback to a default bank.
Controls and mitigations
- Pass the canonical profile into cron jobs, record memory-store ID per run and fail visibly on unexpected fallback.
- Persist the resolved profile and memory-bank identity in the cron job payload, and fail visibly instead of defaulting when that identity cannot be mounted.
Unknowns and contradictions
- Only one reporter configuration is documented; no verified cross-tenant exposure or released correction is shown.
- Whether the same fallback occurs for all scheduler entry points or crosses tenant boundaries has not been shown.
Sources and citation
Material revision history
- Nov 2, 2026 · Canonical change recorded · new in release · revision 214