Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix TUI sessions lost on reconnect — gateway returns 'No session found' for existing session [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#60549•Fetched 2026-04-08 02:49:45
View on GitHub
Comments
0
Participants
1
Timeline
0
Reactions
0
Author
beebeebotbeebeebot
Participants
beebeebotbeebeebot

When using openclaw tui --session main, closing and reopening the TUI frequently results in a completely new session instead of resuming the existing one. The gateway's sessions.resolve call returns "No session found" even though the session file exists on disk.

This is extremely disruptive — conversation context is lost mid-work, requiring the user to re-explain everything.

Root Cause

When using openclaw tui --session main, closing and reopening the TUI frequently results in a completely new session instead of resuming the existing one. The gateway's sessions.resolve call returns "No session found" even though the session file exists on disk.

This is extremely disruptive — conversation context is lost mid-work, requiring the user to re-explain everything.

Fix Action

Fix / Workaround

  1. In-memory session store eviction is too aggressive
  2. TUI reconnect generates a new session key instead of reusing the existing one
  3. Gateway restart (e.g., from config.patch) clears in-memory session state without reloading from disk
  4. Race condition between stale session pruning and active session resolution

Code Example

06:32:55 [ws] sessions.resolve ✗ errorMessage=No session found: acc5b238-a006-44ac-97ec-cb44bd76b426

---

06:42:39 [sessions/store] pruned stale session entries
RAW_BUFFERClick to expand / collapse

Summary

When using openclaw tui --session main, closing and reopening the TUI frequently results in a completely new session instead of resuming the existing one. The gateway's sessions.resolve call returns "No session found" even though the session file exists on disk.

This is extremely disruptive — conversation context is lost mid-work, requiring the user to re-explain everything.

Environment

  • OpenClaw version: 2026.4.1 (da64a97)
  • OS: macOS (Darwin 25.3.0 arm64)
  • Node: v25.8.1
  • Model: anthropic/claude-opus-4-6
  • Session config:
    • dmScope: main
    • reset.mode: daily (atHour: 4)
    • maintenance.mode: enforce
    • maintenance.pruneAfter: 14d
    • maintenance.maxEntries: 400

Steps to Reproduce

  1. Start the TUI: openclaw tui --session main
  2. Have a conversation (10-20 messages)
  3. Close the TUI (Ctrl+C or quit)
  4. Reopen: openclaw tui --session main
  5. Expected: Resume previous session with history
  6. Actual: Fresh session with no history — previous conversation is orphaned

Evidence from Gateway Logs

06:32:55 [ws] sessions.resolve ✗ errorMessage=No session found: acc5b238-a006-44ac-97ec-cb44bd76b426

The session file acc5b238-a006-44ac-97ec-cb44bd76b426.jsonl exists on disk with full conversation history, but the in-memory session store has lost track of it.

Multiple orphaned sessions created today

Three separate session files created within ~1 hour of TUI usage:

  • d255b660 (20+ messages, 7:36 AM) — orphaned
  • 62a58265 (16 messages, 7:50 AM) — orphaned
  • acc5b238 (current, 1327 lines) — eventually became current but lost earlier context

Possibly related: pruned stale session entries log

06:42:39 [sessions/store] pruned stale session entries

This happened around the same time sessions were being lost. The pruning may be too aggressive — evicting sessions from the in-memory store that are still active.

Impact

  • Users lose conversation context mid-work
  • Agent loses all progress and decisions from the session
  • Extremely frustrating during interactive debugging/ops work
  • Memory flush (compaction) can't save context if the session is already gone

Possible Causes

  1. In-memory session store eviction is too aggressive
  2. TUI reconnect generates a new session key instead of reusing the existing one
  3. Gateway restart (e.g., from config.patch) clears in-memory session state without reloading from disk
  4. Race condition between stale session pruning and active session resolution

extent analysis

TL;DR

  • Adjusting the maintenance.pruneAfter setting to a longer duration or implementing a more conservative pruning strategy may help mitigate the issue of losing conversation context due to aggressive session pruning.

Guidance

  • Review the maintenance.pruneAfter setting to ensure it's not too aggressive for the typical conversation duration and adjust it if necessary.
  • Investigate the session pruning logic to determine if there's a way to differentiate between truly stale sessions and those that are still active but temporarily inactive due to TUI closure.
  • Consider implementing a mechanism to reload session state from disk upon gateway restart to prevent loss of in-memory session data.
  • Examine the TUI reconnect process to ensure it's attempting to reuse the existing session key instead of generating a new one.

Example

  • No specific code example is provided due to the lack of direct code references in the issue, but adjusting the maintenance.pruneAfter value in the session config could look something like changing "maintenance.pruneAfter": "14d" to "maintenance.pruneAfter": "30d" to reduce pruning frequency.

Notes

  • The exact cause of the issue isn't certain without further investigation, but the symptoms suggest a problem with session management and pruning.
  • Any changes to the pruning strategy or session management should be thoroughly tested to avoid unintended consequences, such as excessive memory usage.

Recommendation

  • Apply workaround: Adjust the maintenance.pruneAfter setting to a longer duration to reduce the frequency of session pruning and potentially mitigate the loss of conversation context. This is a temporary measure to alleviate the immediate issue while a more permanent solution is developed.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#conversation history#callback error#memory management#API rate limit#retriever error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING