Bug Description

A resumed Hermes session can inherit a stale context-compaction handoff and start answering a completely unrelated current user message with instructions from an old ## Active Task.

In the failure mode I observed, a session lineage had previously been compacted and the preserved handoff block told the model that the current task was defined by ## Active Task. Later, when the user asked an unrelated question in the same resumed lineage, Hermes answered with content from that old task instead of the new message.

This was not caused by persistent memory, a skill, or user profile data. Inspecting the stored session history showed that the stale task came from an inherited compaction block inside the resumed session chain.

Why this seems distinct from generic "forgot context" bugs

This is not just loss of context after compression.

The problem is that an old task remains active enough in the resumed session context to hijack future replies. The model does not merely forget progress; it actively answers the wrong question because stale compaction content is still being treated as live intent.

Expected Behavior

After compaction and later resume/continuation:

• the latest real user message should be the only active instruction
• any prior ## Active Task inside a compaction summary should be treated as historical state only
• stale handoff text from a prior lineage should never outrank a fresh user ask

Actual Behavior

A resumed session can answer a new, unrelated user message with instructions from an earlier task preserved in compaction context.

Repro Shape

A likely repro shape is:

1. Start a session that works on task A
2. Let the session compact, producing a handoff with an ## Active Task
3. Continue/resume that lineage later
4. Ask about unrelated task B
5. Observe Hermes answer using instructions or status from task A

Investigation Notes

From local inspection of the stored session database and lineage:

• the repeated wrong answer was present in stored assistant messages, so this was not a rendering glitch
• the offending content was traceable to a prior compaction handoff in the same resumed lineage
• persistent memory / user profile / skills did not contain the stale task text
• the issue appears to be session-context contamination rather than memory contamination

I am intentionally omitting private message content, profile names, IDs, and filesystem details from this report, but I can help test a fix or provide a sanitized repro if useful.

Possibly Related Issues

This looks closely related to, but not obviously identical with:

• [Bug] Context compaction SUMMARY_PREFIX causes cross-session task leakage #14603 — context compaction SUMMARY_PREFIX causes cross-session task leakage
• Context compression + session resume causes model to re-execute the original first task instead of continuing from compressed state #17344 — compression + session resume re-executes earlier task state
• Context compaction can misread preserved todo/tool state as current user intent and leak MEDIA directives #14665 — compaction can misread preserved state as current user intent

The specific symptom here is: a stale compaction handoff in a resumed lineage can hijack later unrelated replies even when the stale task is not in memory/skills.

Suggested Fix Directions

• make the compaction handoff unambiguously historical, never active instruction
• ensure resumed sessions privilege the latest real user message over inherited handoff text
• add regression coverage for "old Active Task contaminates reply to unrelated new user message"
• consider surfacing or resetting contaminated lineage on resume when the inherited handoff conflicts with the latest user turn