[Bug]: Desktop app becomes extremely slow (suspected memory leak) after repeated Excel edits + browser screenshots across concurrent sessions
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 15/100
- Type d'issue
- Bug
- Clarté
- À clarifier
- Activité
- Active
- Stack technique
- macos, python
- Domaine
- desktop-dev, performance
Piste de recherche
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.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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
- Open the Desktop app and run two sessions in parallel, both working on spreadsheet files at the same time.
- In each session, repeat the following loop roughly 10 times:
- Send a normal instruction that triggers a search (web search / fetch).
- Ask the agent to fill data into an
.xlsxworkbook (Excel edit). - Take a browser screenshot and paste / embed the image into the same workbook.
- Send another instruction, then go back to step 1.
- Tools involved in the loop:
- Excel editing: the bundled
xlsxskill (pandas + openpyxl, plusscripts/recalc.pyandscripts/office/unpack.py/pack.pyfor the workbook ZIP package). - Browser screenshot, including embedding the screenshot image into the workbook.
- ZIP pack / unpack of the workbook package.
- Excel editing: the bundled
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:
- Excel path — the bundled
xlsxskill. Each edit spawns Python (pandas/openpyxl),scripts/recalc.pylaunches headless LibreOffice (soffice), and the pack/unpack step extracts the workbook package to a temp directory. Possible causes: lingeringsofficechild 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. - 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.
- 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.
- Langage dominant
- TypeScript
- Étoiles
- 2.1k
- Forks
- 271
- Merge moyen
- 9 h 55 min
- PR mergées (30 j)
- 52
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Propose un modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de MiniMax-AI/minimax-code
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
MiniMax-AI/minimax-code#507 ·
Les mainteneurs répondent en général sous 1 jour
-
bug needs-triage tui
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
MiniMax-AI/minimax-code#481 · 1 commentaire ·
Les mainteneurs répondent en général sous 1 jour
-
bug cli documentation needs-triage
Difficulté 2/5 1-3 heures Accessibilité débutants 84/100
MiniMax-AI/minimax-code#299 · 3 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 4/5 3-5 jours Accessibilité débutants 42/100
MiniMax-AI/minimax-code#551 ·
Les mainteneurs répondent en général sous 1 jour
-
enhancement needs-triage tui
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 25/100
MiniMax-AI/minimax-code#549 ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de MiniMax-AI/minimax-code
Issues similaires
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
gnosis/gnosis_vpn#661 ·
Les mainteneurs répondent en général sous 1 jour
-
content-freshness: staleOwnedContent doc comments still say 'complete receipt' (follow-up to #7912)Ouvertetriage:bug-verified
Difficulté 1/5 Moins d'une heure Accessibilité débutants 92/100
Les mainteneurs répondent en général sous 1 jour
-
fix: reject sourceStorage/packagedStorage bucket that differs from the stack default (fail loud)Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
Eyevinn/open-videocore#1300 ·
Les mainteneurs répondent en général sous 1 jour
-
nextjs-tracking
Difficulté 2/5 1-3 heures Accessibilité débutants 67/100
cloudflare/vinext#4390 ·
Les mainteneurs répondent en général sous 1 jour
-
kind/bug
Difficulté 2/5 1-3 heures Accessibilité débutants 82/100
kubernetes-sigs/headlamp#8175 ·
Les mainteneurs répondent en général sous 2 jours