[Bug]: Desktop app becomes extremely slow (suspected memory leak) after repeated Excel edits + browser screenshots across concurrent sessions

The payload names the bundled xlsx skill's scripts/recalc.py, scripts/office/unpack.py and pack.py, plus the screenshot-to-workbook embedding path, but no heap profile or failing test. Start by reproducing the loop of about ten edit and screenshot rounds in one session and capturing a heap snapshot to see what is retained. Done means the retention point is identified and a fix or follow-up issue is filed.

Product or interface

Desktop app

Version

Desktop app 3.1.6 (build 3.1.6.195)

Platform

macOS

OS version and architecture

macOS 27.0.1, arm64 (Apple Silicon)

Issue area

Agent stuck / slow / repeated loop

Desktop log upload ID (optional)

Not available at the time of filing. Happy to upload a diagnostic bundle / logs if you tell me which ones you need.

Steps to reproduce

1. Open the Desktop app and run two sessions in parallel, both working on spreadsheet files at the same time.
2. In each session, repeat the following loop roughly 10 times:
   1. Send a normal instruction that triggers a search (web search / fetch).
   2. Ask the agent to fill data into an .xlsx workbook (Excel edit).
   3. Take a browser screenshot and paste / embed the image into the same workbook.
   4. Send another instruction, then go back to step 1.
3. Tools involved in the loop:
   • Excel editing: the bundled xlsx skill (pandas + openpyxl, plus scripts/recalc.py and scripts/office/unpack.py / pack.py for the workbook ZIP package).
   • Browser screenshot, including embedding the screenshot image into the workbook.
   • ZIP pack / unpack of the workbook package.

Expected and actual behavior

Expected: memory usage per session stays roughly flat over repeated iterations, and each round of the loop completes at a consistent speed.

Actual: after roughly 10 rounds in each session, the whole app becomes extremely slow. Every action (sending a command, running a tool call, editing the workbook) is visibly delayed, and the slowdown does not recover on its own. It feels like a memory leak, but I have not yet captured a heap profile, so I cannot confirm where the retention happens.

Observations so far:

• The degradation is cumulative and roughly proportional to the number of edit + screenshot rounds, not to the size of the workbook or the number of rows written.
• It affects both concurrent sessions at the same time, which makes it look app-wide / process-wide rather than limited to one session.
• No error, crash, or warning is surfaced. The app just gets slower, with no obvious signal about which tool call is responsible.
• Starting fresh sessions (or restarting the app) restores normal speed, which suggests something is retained for the lifetime of the running process / session.

Redacted error summary

No error output. This is a performance / suspected-leak report, so there is no stack trace to share. I can capture a heap snapshot or the diagnostic bundle if that is the right next step — please let me know which artifact you need.

Suspected areas (guesses, not confirmed)

I may be wrong about the component, so please treat this section as hypotheses:

1. Excel path — the bundled xlsx skill. Each edit spawns Python (pandas / openpyxl), scripts/recalc.py launches headless LibreOffice (soffice), and the pack/unpack step extracts the workbook package to a temp directory. Possible causes: lingering soffice child processes or LibreOffice profile state accumulating across recalcs, extracted temp directories / cached workbook copies never being cleaned up, or the workbook package being held in memory by the runtime.
2. Screenshot path — screenshots are returned as base64 image payloads inside tool results and are additionally embedded into the workbook as PNGs. Possible causes: screenshot payloads retained in the conversation / tool-result history of each session, or the asset / session-asset store accumulating every screenshot and embedded image without eviction.
3. Combination — with two sessions running the same loop concurrently, whichever of the above retains data is multiplied by two.

What would help to triage

• Which diagnostic artifact you want from the Desktop app (Settings → General → Upload logs, or a heap snapshot) and where it should be sent.
• Whether the Desktop app exposes a memory-usage counter, or an action to clear session data / cached assets, that I should try between iterations to confirm the retention point.
• Whether repeated LibreOffice recalculation (soffice) inside one long-running session is expected to stay cheap, or whether it is known to accumulate.

Before submitting

• I have searched existing issues.
• I have included my version and removed sensitive information.