hermes - 💡(How to fix) Fix [Bug]: TUI /clear blocks on session finalization and appears to reload previous context [1 pull requests]

Bug Description

In hermes --tui, running /clear can hang for a while and then the previous conversation context remains visible or appears to be loaded again. From the user's perspective, /clear feels ineffective.

This is especially noticeable inside zellij, but the root cause appears to be in the TUI session lifecycle rather than zellij itself.

Steps to Reproduce

1. Run hermes --tui inside zellij.
2. Have a non-empty TUI conversation with enough history for session finalization/memory commit to do work.
3. Run /clear.
4. Confirm the destructive action prompt.
5. Observe that the UI can stay stuck for a while before returning, and the old context may still appear visible during the delay.

Expected Behavior

/clear should promptly detach from the current session, clear the visible transcript, and start a fresh session. Slow old-session finalization, memory commit, hook execution, or worker cleanup should not block the UI from switching to the new session.

Actual Behavior

/clear waits for the old session's close/finalize path. If that path is slow, the TUI appears stuck and the previous context remains visible long enough that the command looks ineffective.

Affected Component

CLI (interactive chat), Agent Core (conversation loop, context compression, memory)

Messaging Platform (if gateway-related)

No response

Debug Report

https://paste.rs/4nBrE
https://dpaste.com/9BQM829HV
https://dpaste.com/FB54TNMY3

Operating System

Ubuntu 24.04

Python Version

3.11.15

Hermes Version

Hermes Agent v0.13.0 (2026.5.7)

Additional Logs / Traceback (optional)

No traceback observed. The symptom is an interactive hang/delay in the TUI when clearing a session.

Root Cause Analysis (optional)

The TUI frontend /clear path calls session.close before creating the new session.

In tui_gateway/server.py, session.close synchronously calls _finalize_session(session). _finalize_session() may call agent.commit_memory_session(history) when history exists. If memory commit or finalization is slow, the JSON-RPC response to session.close is delayed, so the frontend cannot immediately proceed to session.create.

Relevant path:

• ui-tui/src/app/slash/commands/core.ts: /clear calls ctx.session.newSession(...)
• ui-tui/src/app/useSessionLifecycle.ts: newSession() awaits closeSession(getUiState().sid) before calling session.create
• tui_gateway/server.py: session.close synchronously finalizes and releases resources
• tui_gateway/server.py: _finalize_session() may synchronously call agent.commit_memory_session(history)

This makes a destructive UI command depend on old-session persistence latency.

Proposed Fix (optional)

Make session.close detach the old session from _sessions and return promptly, then finalize and release old-session resources in a background thread.

A focused regression test can simulate a slow commit_memory_session() and assert that session.close returns quickly instead of blocking on the memory commit.

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR