fix(memory): prevent dead writes when memory_enabled is false (v0.15.1)

[Burgunthy]

Problem

When memory_enabled: false, the memory tool is still exposed in the tool list. The model sees it and calls it — writing data that is never injected into the system prompt. The tool returns {"success": true}, so the agent believes the write succeeded. The data is effectively lost.

The memory_enabled setting does not actually disable memory. It just stops reading it.

Reproduction

1. Set memory_enabled: false (with user_profile_enabled: true so agent still has memory tool)
2. Agent calls memory(target="memory", action="add", content="important info")
3. Tool returns {"success": true}
4. Data written to disk — but never injected into prompt (memory_enabled: false)
5. Next session: agent has no recollection. Dead write.

Fix

Three guards that make memory_enabled: false actually disable writes:

1. tool_executor.py (sequential path) — reject target="memory" when disabled
2. agent_runtime_helpers.py (invoke_tool path) — same guard for concurrent path
3. system_prompt.py — suppress MEMORY_GUIDANCE instructions when disabled

All guards check agent._memory_enabled with getattr(..., False) for backward compatibility.

Testing

• 9 new unit tests: all enabled/disabled/target combinations
• 223 existing memory tests: 0 regression
• E2E verified: agent receives clear error, suggests target="user" as alternative

Built on v0.15.1 main (rebuilt after Velocity refactor).

Related

• Refs fix(memory): honor config.yaml limits in registry-dispatched memory calls (#11665) #11693, Built-in memory and external provider both inject into system prompt when external provider has content #28796, feat(memory): add memory.suppress_builtin_when_external opt-in #29020

[teknium1]

Thanks for identifying a real configuration combination: current main still creates a MemoryStore when user_profile_enabled is true (agent/agent_init.py:1369-1375) but injects its memory target only when _memory_enabled is true (agent/system_prompt.py:460-469). Both current dispatch paths still call memory_tool without that guard (agent/tool_executor.py:1284-1296, agent/agent_runtime_helpers.py:2281-2293).

Problems

• The new raw target == "memory" checks miss target: null; memory_tool() normalizes null to "memory" at tools/memory_tool.py:980-984, so this still produces a dead write. Cover null in both paths.
• getattr(agent, "_memory_enabled", False) breaks the existing skip_memory=True memory-tool fixture, which still expects MEMORY_GUIDANCE (tests/run_agent/test_run_agent.py:1258-1262).
• build_system_prompt_parts() returns a dict (agent/system_prompt.py:145-159), so the new prompt test joins dict keys; the two disabled cases use assert True.

Suggested changes

• Normalize the effective target before guarding, preserve the established absent-attribute prompt behavior, and assert MEMORY_GUIDANCE directly in parts["stable"].

Automated hermes-sweeper review.

[teknium1]

memory_tool() treats target: null as the default "memory" target (tools/memory_tool.py:980-984), but this raw equality check does not. Normalize None before this guard and add a null-target regression; otherwise a model can still make the disabled dead write.

[teknium1]

Using False as the absent-attribute default breaks the existing skip_memory=True fixture that deliberately exposes the memory tool and expects MEMORY_GUIDANCE (tests/run_agent/test_run_agent.py:1258-1262). Preserve that compatibility behavior while testing an explicitly false _memory_enabled flag.

[GottZ]

This was generated by AI during triage.

Summary

Two PRs address the dead-write path when memory_enabled is false; #30814 and #34414 carry the same diff, adding guards to both dispatch paths and gating memory guidance, but both miss the explicit target: null case that the underlying memory tool normalizes to memory. Their prompt tests also do not actually verify guidance presence or absence, and the _memory_enabled fallback conflicts with an existing skip_memory=True fixture expectation.

Related pull requests

• #30814 related — (+246/-9) — keep open, revisions required: The diff addresses the reported cause in both sequential and concurrent dispatch and suppresses misleading guidance, but the contributor keep_open review on #30814 identifies concrete gaps: target: null bypasses both guards, the fallback changes existing fixture behavior, and two prompt tests are no-op assertions over incorrectly joined dict keys. Merge only after those points are addressed and tested.
• #34414 [closed] duplicate — (+246/-9) — closed duplicate, still relevant as exact-diff evidence: It implements the same guards, guidance gate, and tests as #30814, so it has the same null-target, compatibility, and ineffective-test deficiencies; the author closed it specifically to update the original PR instead.

Duplicates

#34414 is an exact duplicate of #30814 in the supplied diff and was closed by its author in favor of updating #30814.

Suggested consolidation

Merge #30814 only after revising it to normalize the effective target before guarding, preserve the documented existing fixture behavior, and replace the no-op prompt assertions with checks against the returned structure. This follows, rather than overrides, the contributor keep_open review on #30814; keep #34414 closed as the duplicate superseded by #30814.

Complex graph

flowchart LR
    classDef open fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
    classDef merged fill:#dcfce7,stroke:#15803d,color:#14532d
    classDef closed fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    classDef unverified fill:#f3f4f6,stroke:#9ca3af,color:#374151
    classDef best stroke-width:3px,stroke:#b45309
    classDef target stroke-width:3px,stroke:#4338ca
    subgraph Dup30814 ["PRs duplicating each other"]
        P30814["PR #30814 (open)"]
        P34414["PR #34414 (closed)"]
    end
    class P30814 open
    class P34414 closed
    class P30814 target
    click P30814 "https://github.com/NousResearch/hermes-agent/pull/30814"
    click P34414 "https://github.com/NousResearch/hermes-agent/pull/34414"

Loading

Graph: solid arrow = fixes / best fix, dashed arrow = partial or unverified (see edge label); boxed group = PRs duplicating each other; amber border = best fix; indigo border = target; gray node = closed (state tag in the node label).

Cross-PR triage: Reviewed 2 pull requests and 0 issues in this complex. Each diff was read against this issue; Assessment working set: 26 kB of PR diffs, 4 kB of issue/PR text, 1 kB of discussion (2 comments), 0 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.