---
title: Mnemosyne Automatic Capture Failure
type: incident
status: active
created: 2026-08-01
updated: 2026-08-01
verified_on: 2026-08-01
confidence: high
tags: [memory, mnemosyne, hermes, incident]
sources: [live-config, mnemosyne-db, hermes-cli-e2e]
---

# Mnemosyne Automatic Capture Failure — 2026-08-01

## Impact
Ordinary Hermes conversations were not being written to Mnemosyne `working_memory`. Explicit memory tools, SQLite integrity, vectors, FTS indexes, consolidation, backups, and cron monitoring remained operational. The newest automatic/explicit working row before repair was approximately fourteen hours old despite active Hermes sessions.

The always-injected legacy files were also effectively full: `MEMORY.md` was 5,055 bytes against a 5,000-character limit and `USER.md` was 2,958 bytes against 3,000. Legacy writes had begun failing.

## Root Cause
Structured values under `memory.mnemosyne` in `~/.hermes/config.yaml` had been serialized as strings instead of native YAML types. The critical value was:

```yaml
sync_roles: "['user']"
```

The provider interpreted this as the literal invalid role `['user']`, so turn synchronization completed without persisting a user row. Other malformed values included `skip_contexts`, `reflect`, `sleep_threshold`, and `ignore_patterns`.

## Repair
- Backed up config to `/home/hermes/.hermes/backups/mnemosyne-capture-fix-20260801_180249/config.yaml.before`.
- Rewrote structured Mnemosyne settings with native YAML types.
- Set `profile_isolation: true` because the installation has multiple Hermes profiles.
- Preserved `sync_roles: [user]` and the intended skipped contexts.
- Ran `hermes config check` successfully.
- Created authoritative Mnemosyne canonical slots for user preferences and key workflows, correcting stale light-theme, numbered-Obsidian, and CT460 route entries.
- Backed up legacy files to `/home/hermes/.hermes/backups/legacy-memory-slim-20260801_180702/`.
- Reduced legacy injection from 8,013 bytes to 1,080 bytes while retaining essential always-on rules.

## Verification
A pre-fix CLI turn using marker `MNEMO_E2E_20260801_180113_27053` completed but produced no database row.

A post-fix CLI turn using marker `MNEMO_FIXED_20260801_180310_16583` wrote:

```text
[USER] Reply with exactly OK. Memory capture test marker: MNEMO_FIXED_20260801_180310_16583
```

The row was verified directly in `~/.hermes/mnemosyne/data/mnemosyne.db`. Final diagnostics reported zero failed checks, complete working-vector coverage, zero orphan embeddings, 1,482 working rows, and 463 episodic vectors.

## Remaining Activation Step
The already-running Telegram gateway/provider instance was initialized before the config repair. Run `hermes gateway restart` from an external terminal to load the corrected typed configuration for messaging-platform turns. The gateway cannot safely restart itself from one of its own child tool calls.

## Monitoring Note
The health script checks capture staleness only after 24 hours. It therefore remained green during this fourteen-hour active-capture outage. A future improvement should compare recent non-cron conversation activity with the newest `working_memory` row rather than lowering the threshold blindly and creating idle-period false positives.

## Related
- [[systems/mnemosyne]]
- [[systems/memory-backend]]
- [[incidents/2026-07-29-mnemosyne-relay]]