Skip to content

Conversation

@elithrar
Copy link
Contributor

@elithrar elithrar commented Jan 2, 2026

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.

@elithrar elithrar marked this pull request as ready for review January 2, 2026 21:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant