Perf: ~3s hang + memory leak when switching workspaces (Linux, Claude Code)

[aabidos]

First, a thank you for this project !

---

Summary

After a fresh install with just 2 workspaces running Claude Code, and 20 minutes, memory is already at ~2.7 GB. Switching between workspaces causes a ~3 second UI freeze, and memory appears to grow continuously over the session rather than stabilizing.

---

Environment

OS	KDE neon 24.04 (Ubuntu 24.04 base), kernel 6.14.0-36-generic
CPU	Intel Core Ultra 7 155H
RAM	64 GB total — 2.7 GB used by Pane with just 2 Claude Code workspaces
Pane version	Latest release
Agent in panes	Claude Code
Number of workspaces	2 (minimal use)

---

Behavior

Steps to reproduce:

1. Fresh install of Pane on Linux
2. Create 2 workspace, each running a Claude Code session
3. Switch between workspaces

Observed:

• Memory usage: ~2.7 GB with only 2 workspace
• Switching workspaces causes a ~3 second freeze before the new workspace becomes responsive
• Memory appears to grow over time 1 Go at first , then 2.1Go, 2.7Go, ..

Expected:

• Workspace switching < 100ms
• Memory usage proportional to actual content, not unbounded growth

[parsakhaz]

@aabidos thx for flagging, investigating!

[parsakhaz]

@aabidos can you share your latest w/ the latest release? a screenshot of this UI would be great so you can see how much each terminal/cc is taking

[parsakhaz]

shipped in v1.1.116 (#145). turned out to be a stack of 5 different leaks, not one.

the big ones:

1. AbstractCliManager had a closure that concatenated every byte of PTY output into a single string for the entire life of the process, used only as a tail for crash error reports. with 2 sessions running claude code for 20 min thats easily hundreds of MB per panel. bounded it to a 16KB tail now
2. gitFileWatcher was using fs.watch(path, { recursive: true }) which on linux registers an inotify watch descriptor for every subdirectory. on a real repo w/ node_modules thats tens of thousands of watches, and tearing one down + setting one up on workspace switch blocks the event loop, thats where the 3s freeze was coming from. replaced w/ chokidar using a function-form ignored that short-circuits descent into node_modules/.git/.next/.cache/etc
3. a whole class of cleanup methods (cleanupSessionPanels, clearSessionCache, stopRunCommands, webviewContextMap.delete) existed but had literally zero callers. every archived session permanently leaked its panels, git status cache, file watchers, and run command processes. wired them all into the archive path

plus two smaller things: throttle maps in the frontend that never drained on session delete, and a full SELECT * query that ran just to check if conversation history existed (swapped for COUNT(*)).

lmk if the memory/freeze behavior improves for you on v1.1.116