[Bug] Memory management issues. #5412

Activity

1. john-sarria

   added

   bugSomething isn't workingSomething isn't working

   on Oct 22, 2026
2. openchamber-bot commented on Oct 22, 2026

   

   openchamber-botBot

   on Oct 22, 2026

   Contributor

   More actions

   For the maintainer: needs-reporter — waiting on the per-process breakdown and growth data.

   Duplicate check: not a duplicate. The tracker's past memory reports each had a specific, fixed mechanism on older versions (#3350/#3358/#4053 MCP fleet respawns, #3710 orphaned remote servers, #3764 leaked worktree instances, #4862 main-process OOM, #2265/#2587 renderer OOM). None matches a 2.5.0 macOS desktop report of ~41 GB, so it stays open.

   What the evidence shows: the screenshot is the macOS "run out of application memory" dialog listing OpenChamber at 40.90 GB, but that view aggregates the whole app and does not say which process grew. I read the obvious session-retention path and it is bounded: the live sync state trims the session list to a limit (packages/ui/src/sync/event-reducer.ts:758 trimSessions) and drops a removed session's caches (event-reducer.ts:777 → session-cache.ts dropSessionCaches); message prefetches are capped (session-prefetch-cache.ts, #2102). So "sessions not being garbage-collected" in the UI session list is not supported by the code, and this report contains nothing that discriminates between the plausible reservoirs (renderer retention, Electron main, terminal replay buffers, the managed opencode serve child fleet). No single cause can be traced from this report.

   Questions the code cannot answer:

   1. In Activity Monitor (Memory tab, sorted by Memory — not the Force Quit dialog), which process holds the gigabytes: OpenChamber (main), OpenChamber Helper (Renderer), or a separate opencode/node process? A screenshot of that list would settle it.
   2. Growth pattern: does memory climb steadily during use and stay high after closing sessions/projects, or only after very heavy use? Roughly how many projects and sessions are open, and does a relaunch reset it?
   3. Are local MCP servers configured (Settings → MCP)? Several earlier memory issues were respawning MCP fleets, and that changes where to look first.

   The Logs section of the report is empty; logs covering the growth period would help once (1) identifies the process.
3. openchamber-bot

   added

   platform:macosmacOS desktop (Electron/Tauri)macOS desktop (Electron/Tauri)

   needs-infoNeeds more info from reporter to reproduceNeeds more info from reporter to reproduce

   on Oct 22, 2026
4. john-sarria commented on Oct 22, 2026

   

   john-sarria

   on Oct 22, 2026

   Author

   More actions

   Thanks for looking into this. Here's what I could pull from the logs. I couldn't catch the per-process breakdown this time because the app had already been quit, but I'll attach an Activity Monitor screenshot if it happens again.

   Correction: this happened at ~12:40 PM CEST (10:40 UTC), not AM. I quit the app from the macOS out-of-memory dialog at 12:42:14 (clean shutdown in main.log) and relaunched at 12:43:34.

   1. Which process

   Unknown for this occurrence. After relaunch everything is normal:

   Process	Footprint
   OpenChamber (main)	156 MB
   OpenChamber Helper (Renderer)	412 MB (peak 620 MB)
   OpenChamber Helper (GPU)	276 MB (peak 761 MB)
   opencode serve	192 MB

   2. Growth pattern

   • The instance that blew up had been running ~21h (since the 2.5.0 update restart, 2026-10-21 15:40 CEST), with Keep awake enabled, so it ran overnight.
   • A relaunch resets it to ~1 GB total.
   • 8 projects, ~95 sessions. Up to ~11 project/worktree directories were open at once during that run. The largest session has ~4.8k parts (~16 MB).

   3. MCP servers: yes

   • Local (stdio): codegraph, aws-mcp (uvx mcp-proxy-for-aws)
   • Remote: whimsical, atlassian-rovo, scrapfly, wpa-mcp-prd/stg

   Each opened directory gets its own MCP set. During the 21h run each server logged ~68 mcp connected events. aws-mcp/wpa-mcp failed auth every hour (mcp http authentication rejected, OAuth token-hook errors), so they kept reconnecting all night.

   Timeline before the dialog (CEST)

   Time	Event
   10:00–11:10	Mostly idle
   11:16–11:26	Agent session ran dotnet test and committed
   12:15	Two directories reopened, each spawning a full MCP set
   12:20–12:27	Older directory instances evicted
   12:26	[session-work] turn-end check failed: timed out after 4000ms, the only slowness warning in the logs
   12:30–12:38	Agent ran tsc, lint, build and vitest run ×3. The last run finished cleanly at 12:38:31 (1855 tests, 6.35s)
   12:39	Last agent action (edited a file)
   12:39–12:42	opencode serve idle, only one 503 from /api/experimental/generate (session-assist)
   12:42:14	Quit from the OOM dialog

   So no agent tool processes were running when the dialog appeared, and the server was idle. That suggests the memory was held by OpenChamber's own processes (Renderer/main/GPU) and built up over the long run, not by spawned commands.

   No memory/heap/OOM errors in ~/Library/Logs/OpenChamber/main.log or ~/.local/share/opencode/log/opencode.log, and no crash report was written. I can share trimmed logs for run eaadd859 (2026-10-21T14:27Z → 2026-10-22T10:42Z) if useful.
5. yulia-ivashko

   assigned

   btriapitsyn

   on Oct 22, 2026