hermes - 💡(How to fix) Fix Feature: Auto-bridge context on manual /new in CLI/TUI — inject last session context

Problem

In CLI/TUI mode, users manually run /new when a session gets long and the model starts to degrade (context too large → slower, dumber responses). The new session starts with zero conversational context — the agent has no idea what was just being discussed.

Existing mechanisms don't cover this:

• Memory (~1400 chars) stores durable facts, not conversation flow
• session_search exists but requires the agent to proactively call it — the agent doesn't know it should
• #5810 proposes context_carry for auto-reset (gateway idle/daily timeout), not for manual /new
• #16661 is a community plugin, not built-in

User Story

"I /new because the session is slow. But now I have to re-explain what we were doing. The old session is still in the DB — just read it."

The TUI/CLI process is still running. Only the session ID changed. The previous session transcript is intact in state.db.

Proposed Solution

Add a built-in behavior (configurable, opt-in) where on manual /new//reset in CLI/TUI:

1. Before discarding the old session, extract the last N messages (or generate an LLM summary)
2. Inject them into the new session as system context, e.g.:

[Context from previous session (bridged on /new):
User: Can you fix the deployment pipeline?
Assistant: The staging deploy failed at 11:42 PM — health check timed out...
User: OK, let's fix that tomorrow.
]

Config

session_bridge:
  enabled: false        # opt-in, default off
  mode: messages        # "messages" (last N) or "summary" (LLM-generated)
  count: 10             # number of messages (or summary length)
  platforms: [tui, cli] # which platforms trigger this

Why not just rely on session_search?

Because the agent doesn't know it was just /new'ed. From the agent's perspective, every session starts the same way — it has no signal that "this is a continuation, go look." The bridge happens at the framework level before the agent's first turn, so context is ready.

Implementation Notes

• CLI new_session() already fires on_session_reset and _mm.on_session_switch — the new logic can hook in there
• state.db.get_session() + get_messages_as_conversation() on the old session ID before it's replaced
• Summary mode can reuse the auxiliary LLM client
• Should NOT fire for gateway auto-resets (those already have #5810 discussion) — only for explicit user-initiated /new

Related

• #5810 — Carry last N messages into new session on auto-reset (related but different trigger)
• #16661 — Plugin: context-resume (community plugin, same concept but not built-in)
• #12857 — Auto-reset parent session ID persistence (infrastructure)