Bug Description

When a foreground session undergoes context compression and is subsequently resumed (via hermes resume or by reopening the session), the model appears to re-execute the original first task instead of continuing from the compressed state. All progress encoded in the compression summary is ignored, and the model responds as if the session had just started.

This behavior has been observed in:

• New sessions opened after a compression cycle completes
• Resumed sessions restored via hermes resume

Expected Behavior

After context compression, a resumed session should:

1. Load the compression summary (containing ## Goal, ## Progress, ## Active Task, ## Next Steps)
2. Continue from ## Active Task / ## Next Steps as described in the summary
3. Treat the preserved original first user message in the tail as historical context — not as an active instruction to execute

Actual Behavior

The model responds to the original first user message preserved in the tail, effectively restarting the first task from scratch. The compression summary is either ignored or overridden by the model's tendency to respond to the most prominent user message in context.

Technical Background

How compression is structured (from official documentation)

From the official context compression docs, after a compression cycle the message list has this structure:

[0] system:     (with compaction note appended)
[1] user:       "original first user request"   ← preserved in tail
[2] assistant:  "[CONTEXT COMPACTION] Summary:
                ## Goal: ...
                ## Progress: ...
                ## Active Task: ...
                ## Next Steps: ..."
[3] user:       "latest user message"

The design intention is: the model reads ## Active Task / ## Next Steps and continues from there, while the preserved tail messages serve as historical context.

What I observe in affected sessions

I traced a 6-session compression chain where each session ended in compression over ~18 hours. Every child session carried the identical original first user message, as if no progress had been made across the entire chain. The compression summaries described completed work, yet on resume the model appeared to restart from the preserved first message.

I also verified that parent_session_id in the SQLite sessions table shows NULL for sessions that are clearly part of a compression chain — which may indicate the session lineage is not being properly tracked, or that new sessions are being created instead of resumed ones during the compression handoff.

Related Issues and PRs

PR #17301 — "fix: exempt memory and skills from 'background reference' label in context compaction"

(Opened today by HiddenPuppy)

This PR addresses a related but distinct issue: after compaction, the SUMMARY_PREFIX instruction causes the agent to treat its own persistent memory and skills as "background reference," making them effectively inaccessible. This results in the agent "forgetting" facts about the session after restart.

My issue and PR #17301 may share a common root cause — both involve the SUMMARY_PREFIX / compression handoff being interpreted too broadly by the model. PR #17301 exempts memory and skills; the fix needed for my issue may require clarifying how the model should treat the preserved first user message in the tail.

Reference: #17301

Issue #17251 — "Context Compaction Demotes Memory to Background Reference"

(Opened today by ifearghal)

Reporter describes identical symptoms: after gateway restart / context compaction, the agent "wakes up with no memory of the session," doesn't know key infrastructure details, and asks the user to re-explain everything. This confirms the issue is not isolated to my environment.

Reference: #17251

Questions and Offer to Assist

1. Is there an intended mechanism that should prevent the model from responding to the preserved original first user message after compression? Or is the model expected to self-regulate by reading ## Active Task?

2. Could the role-merge logic (summary and tail getting merged when they share the same role) be causing the ## Active Task section to lose prominence in the model's attention?

3. Would PR fix: exempt memory and skills from 'background reference' label in context compaction #17301's fix (adding EXCEPTIONS to SUMMARY_PREFIX) also address this variant, or does this require a separate fix targeting how the preserved first user message is handled?

4. Is the parent_session_id = NULL behavior in the compression chain expected? This may be contributing to sessions being reopened as "new" instead of "resumed."

I am happy to provide any additional session data, traces, or diagnostic information that would help. If this is best addressed via a PR, I am also willing to work on a fix — please let me know which failure point you recommend targeting first.