fix: clear FileTime cache when sessions are deleted
Clears per-session file read timestamps when sessions are deleted, preventing memory accumulation during long-running sessions.
This is fairly low impact, but non-zero. The leak only occurs within a single opencode process lifetime and is cleared on exit via Instance.disposeAll().
Quantified growth rates:
- Daily restarts (typical): <1 MB peak, reset on exit
- 8-hour extended session: 1-5 MB peak
- Week-long session without restart: 20-50 MB peak (unlikely usage pattern)
- 128 MB threshold: Would require ~2,150 complex tasks (each spawning 5 subtasks reading ~30 files) in a single session - approximately one task every 2 minutes for 72 hours straight
The leak scales with # of sessions × # of unique files read, at ~160 bytes per file entry. Subtasks are the primary driver since each creates a new sessionID, so sub-task heavy users/agents are likely to see this happen more.
note: this was a bit of an exploration to see what memory leaks existed and could be tested for. I was only looking for leaks that could genuinely accumulate >= 128MB of RAM over typical-to-heavy usage, not a few KB a day. I've seen things get slow across long-running / multi-day processes and went looking for potential fixes.