[Bug] Worker memory remains high after concurrent resumed sessions

[WadohS]

Environment

• CodeNomad 0.20.0 — Tauri, Linux
• OpenCode 2.0.18

Description

I ran a heavy workload with several worker sessions running simultaneously, including large sessions that were resumed multiple times.

Over time, CodeNomad / its OpenCode workers consumed a significant amount of memory. The important problem is that the memory did not seem to return to a reasonable level after the work had finished.

Restarting or killing the CodeNomad desktop application alone did not reclaim it. The only reliable recovery I found was:

1. Stop all workers.
2. Log out of my Linux user session.
3. Log back in and start CodeNomad again.
4. Resume the worker sessions.

No session history was intentionally deleted in this process.

Expected behavior

Long-running and concurrent worker sessions should have bounded memory use, or at least release unused memory after they become idle or are stopped. Restarting the desktop client should not leave an unexpectedly large worker memory footprint behind.

Questions / possible improvements

I am not sure whether this is primarily in CodeNomad, the OpenCode V2 shared service, or the interaction between both. Have you already observed a similar problem with many concurrent or resumed worker sessions?

Possible improvements that would help heavy users:

• explicit per-worker and global memory limits;
• automatic cleanup/eviction for idle workers and inactive session data;
• a visible memory usage view per worker/session;
• a safe UI action to stop unused workers and reclaim their resources without logging out;
• clearer distinction between closing CodeNomad and stopping the OpenCode worker/service processes.

This may be related to the broader memory-management work discussed in #553, but the reproduction here is specifically multiple simultaneous workers and repeated session resumes on Linux/OpenCode V2.

Thanks again for the great work on CodeNomad. I hope this real-world heavy-workload report is useful.

[pascalandr]

Thanks for the report. I merged #648 before 0.20.0 to bound client-side transcript memory, but that budget does not cover the shared OpenCode service or tool/MCP processes. Closing CodeNomad intentionally leaves that service running.

Could you share this output during high memory use, then after stopping the workers and closing CodeNomad?

ps -eo pid,ppid,comm,rss --sort=-rss | head -20

Please also mention roughly how many sessions were running, which tools/MCPs were involved, and how you stopped the workers. This should help me identify which process retains memory before suggesting a specific build or fix.

[WadohS]

ok i test that tomorow ;)
a toutes ;)

[WadohS]

Additional observation from today.

I restarted my workers last night and let them run throughout the night. RAM usage was still around 20% this morning, but it has since climbed to 94%.

Current process snapshot (RSS, in KiB):

    PID    PPID COMMAND           RSS
 621223    4009 opencode        52338768
 625592  625533 WebKitWebProces 1482292
 626654  626264 brave           379096
 624105    4009 gnome-shell     225964
 626211  626012 brave           222176
 625813  625799 MainThread      191044
 627181  626264 brave           179396
 626832  626264 brave           168068
 627172  626264 brave           160448
 999886    4009 gnome-character 160112
 632874  626264 brave           150472
 627425  626264 brave           138860
 631280  626264 brave           128608
 626424  626264 brave           126560
 626597  626264 brave           120308
1000233    4009 ptyxis          119280
 977529  624105 gjs             117440
 626380  626264 brave           115328
 626884  626264 brave           114792

The OpenCode process alone is currently using about 50 GiB RSS (52,338,768 KiB), which appears to be the main source of memory pressure. This makes the issue look more related to long-running worker/service memory than to the CodeNomad renderer alone.

[WadohS]

More context about the workload:

• One work session currently contains six concurrent workers.
• They process recipe content and layout before importing it into recipe-management software.
• The source is scanned recipe material, but the OCR has already been processed before the workers receive it.
• There are no MCP tools involved; the workflow uses only a web API.

Worker roles:

• Four workers perform the same recipe-processing work in parallel.
• One worker handles potential blockers or exceptions.
• One worker imports completed recipe records once they are ready.

So this is a sustained parallel text-processing and formatting workload, with repeated worker/session resumes, rather than a workload dominated by local tools or MCP output.

[pascalandr]

Thanks, that identifies OpenCode as the main memory consumer. Could you try these steps once it is safe to interrupt the work?

1. Stop/cancel all six workers, leave CodeNomad open, and wait about a minute. Please mention how you stopped them.
2. Open a terminal on Linux and paste this command, then share its output:

ps -eo pid,ppid,comm,rss --sort=-rss | head -20

3. In that same terminal, paste:

opencode service restart

This restarts OpenCode's background service, not the desktop app, and interrupts any remaining active sessions. No logout or session-history deletion is needed. If the command fails or says command not found, please share the error.

4. Before resuming the workers, run the first ps command again and share that output too.

I want to check how much memory remains while idle and whether restarting just OpenCode reclaims it.

[WadohS]

Follow-up observation: since my previous message, memory has not saturated again, even after increasing the workload to 12 concurrent workers.

There was a pause during the night, so I cannot tell whether memory increased and then decreased while I was away. However, since this morning, total memory usage has risen by only about 18 percentage points.

This behavior is rather surprising compared with the previous run, where usage climbed to 94%. It may indicate that the growth depends on a specific worker/session state, a resume pattern, or some cleanup that occurs after an idle period.

[pascalandr]

If memory usage becomes excessive again, I’ve added a Restart OpenCode service button under Settings → OpenCode → Troubleshooting for the next dev build (#844).

It restarts the background opencode process without deleting session history.