Freezing startup due to many expanded shape groups

[Wildzekat]

Preflight Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

You must agree to search and the code of conduct. You must fill in this entire template. If you delete part/all or miss parts out your issue will be closed.

Describe the bug
Starting up drawio results in a freezed program (Image 1). The process almost completely halts once this view gets visible. It can stay that way for more than 20 minutes, requiring me to end, sometimes kill the processes.
Sadly, there is no error output on the command line.
If trying to use STRG+SHIFT+I during startup, the process freezes in a glitched loading wheel instead, not opening the Inspection Tool but not rendering either. State remains practically the same, except for the view seen in Video 1 with the glitching loading wheel.

Honestly, this is partially my fault, but the severity of this issue should still be fixed. As of now, drawio seems unusable and I probably need to either find the configuration file or purge and freshly install it.

To Reproduce
I did some work before, which has led to this issue I believe. This needs to be done before:

• Start up
• Add many (all?) shape groups
• Expand many (all?) shape groups
  Afterwards, I closed it.

1. Open drawio
2. Wait
3. Wait (longer)
4. See… waiting
5. See the screen you'd expect - frozen.
6. Try to do anything. Nothing.

How did this happen?
I did a funky little RAM usage experiment by expanding a lot of shape groups in the left panel. This had expected results (RAM going up a LOT) but I didn't think much more of it.
So I closed it without collapsing these groups.

Expected behavior
I expected them to appear closed on the next startup, as it happened in older versions of drawio.

What actually happened
It apparently saved my "choice" and tried to load ALL contents at once. This went kinda fine at first, with one thread keeping one of my cores completely busy while loading.
But then it just froze. So I decided to inspect what happened.

1. It starts like normal, opening the complete chain of subprocesses
2. It starts to load all the groups, occupying a core with one of its threads
3. Memory starts to get occupied as well, at an estimate rate of 50MB/s
4. The Memory usage hits precisely 2.76GB (2.69GB when having pressed STRG+SHIFT+I before)
5. The process freezes.
   Slight processor usage can be noticed, but these apparently are usages by other threads reacting to WM Events and trying to call into the frozen Thread. They only slightly appear on Interaction and no result can be observed.

Screenshots
Image 1

Video 1
https://github.com/user-attachments/assets/0a67db3e-5fab-47f7-bf7f-8cc819c5be3a

draw.io version (In the Help->About menu of the draw.io editor):

• draw.io version 30.0.4

Desktop (please complete the following information):

• OS: Debian GNU/Linux 13 (trixie)
• Kernel: Linux 6.12.90

Additional context
Yes, I have set the cause myself. But that's still an issue. It can easily happen on accident or out of curiosity and it WILL brick installations.

Could you tell me where I find the saved configuration for the open shape groups? If I could close them manually that would help a lot!

[draw-io-triage-bot]

👋 Thank you for opening this issue!

---

Summary: draw.io desktop freezes on startup (hitting ~2.76GB memory cap) because it persists the expanded state of all shape library groups in the sidebar, and attempting to render all of them simultaneously on launch causes the application to become unresponsive. The user is also asking where the configuration file is stored so they can manually reset the sidebar state.

---

📝 Additional Information Needed

To help us investigate this more effectively, could you please provide:

• As an immediate workaround, you can try resetting the draw.io configuration. On Linux, the configuration is typically stored in ~/.config/draw.io/ (or ~/.config/drawio-desktop/). Look for files like storage or .config in that directory. You could try deleting or renaming the entire config directory (back it up first!) and restarting draw.io to get a fresh state. Alternatively, look for a JSON config file in that directory and search for keys related to sidebar/library expansion state — removing those entries may fix the issue without a full reset.
• Have you tried launching draw.io with the --disable-gpu flag or any other Electron flags to see if behavior changes?
• Could you check if the config directory ~/.config/draw.io/ exists and report what files are in it? This would help others facing the same issue locate the relevant configuration to reset.

📋 Bug Report Template

**Environment:**
- draw.io version: [e.g., web app / desktop 24.x.x / Confluence plugin]
- Browser (if web): [e.g., Chrome 120, Firefox 121]
- OS: [e.g., Windows 11, macOS 14, Ubuntu 22.04]

**Steps to Reproduce:**
1. Go to ...
2. Click on ...
3. See error

**Expected Behavior:**
What you expected to happen.

**Actual Behavior:**
What actually happened.

**Screenshots/Files:**
If applicable, add screenshots or attach the .drawio file.

---

---

_{🤖 This is an automated response to help with initial triage. A human maintainer will review this issue. If you've provided all the requested information, no further action is needed - we'll get back to you soon!}

[Wildzekat]

Little update to this situation:
While I was not able to access the content of the leveldb files in ~/.config/draw.io/Local Storage/leveldb/, deleting the content of this folder resets the shape sidebar issue but kept the content of my scratchpad alive. So I am now able to access draw.io desktop again.

[alderg]

We'll speed up the loading of those sidebars and add a right-click Collapse All option in the sidebar section titles.