Session resume: zero-message startup stubs pile up; resume list re-scans every .jsonl on each cold start

[shixiehe82]

Area

Agent core, TUI

Problem

Running prime-agent 0.9.1 on Linux aarch64 (proot on Android, local daemon). Two friction points around session resume:

1. Every CLI launch writes a session file even when no message is ever sent.
The session header block (session, model_change, thinking_level_change, service_tier_change, session_state) is appended at startup, before the first user input. If the CLI is closed without chatting (or crashes), a 5-6 line ~1 KB stub remains and is never cleaned up — there is no GC for stubs anywhere. In my sessions dir 32 of 53 files are zero-message stubs (~60%), and they clutter the resume picker.

2. The resume list is rebuilt by full-scanning every session file on every cold start.
listSessionsFromDir → readSessionInfo → scanSessionInfo streams and JSON-parses every line of every .jsonl (lines >1 MB are skipped from parsing but still read) to extract preview / message count / last activity / status. sessionInfoCache is in-memory only and keyed by (size, mtime), so each fresh process re-scans the whole store — 53 files / 24 MB in my case. On phone/proot filesystems this is very noticeable before you can even pick a session.

Proposed direction

1. Stub hygiene — either create the session file lazily on the first user message, or GC zero-message stubs older than N days, or at least filter zero-message sessions out of the resume picker by default (with an opt-in flag to show them).
2. Persistent session index — keep a compact sidecar index (one entry per session: id, size, mtime, first-message preview, message count, last activity, status), updated incrementally when a session file is appended. On listing, only rescan files whose (size, mtime) changed since the last index write. A single sessions.index.jsonl would do.
3. Large-session resume — resuming a multi-MB session (my largest: 5.3 MB, ~350k tokens of message text) reloads the full file and rebuilds the index before anything else, and the first model call can trigger auto-compaction on top. Reusing the existing compaction summary when present, or offering a "resume-lite" mode that starts from the summary, would cut time-to-first-response a lot.

Alternatives considered

Workarounds today:

• manually deleting zero-message stub files (works, but every launch creates new ones);
• avoiding resume of large sessions entirely — starting a fresh session and persisting important context into memories/files instead. Both lose the convenience resume is supposed to provide.

Additional context

Measured on the local store: 53 sessions / 24.1 MB total, 32 zero-message stubs. Largest session: 5.3 MB, 2899 entries, ~1.13M chars of message text. A full-store scan in a plain local script takes ~30 ms (Python, this device), so the perceived slowness is mostly the Node async line-streaming + per-entry JSON parse on every cold start, not raw disk speed. Happy to profile more in the aarch64/proot environment if useful.