[bug:critical] Linux: app freezes with 12GB+ RAM usage during normal use

[GoDiao]

Summary

A user reported in #8 that running DreamCoder on Linux causes RAM usage to spike to 12 GB+, with the app freezing to the point of being unclickable even after configuring swap.

"It was using too much ram like 12gb+ and i work on linux even tho i created a swap memory to run it but it was still freezing and i couldnt click anywhere on the app."
— @Kafkacodes, #8 (comment)

This is a critical bug. A desktop app cannot ship to Linux users in this state.

Severity: critical

• 12 GB RSS for a Tauri + Bun app is at least an order of magnitude beyond expected behaviour. Steady-state on Windows is in the hundreds of MB.
• The freeze is total — the user could not click anywhere. So Linux users have effectively zero usable workflow today.
• This is the first feedback we have from a Linux user trying to contribute. If we don't fix it, we lose every future Linux contributor the same way.

Honest disclosure of investigation state

DreamCoder is currently developed and verified by the maintainer on Windows x64 only. The codebase includes Linux platform branches (#[cfg(target_os = "linux")]) but the maintainer does not run Linux day-to-day, so:

• We do not have a confirmed reproduction yet.
• We cannot bisect this against a "known good" Linux baseline because no such baseline has been established.
• Investigation will need help from Linux users who can run the app and attach diagnostics.

This does not lower the severity. It just means the path to a fix runs through community collaboration rather than a maintainer hot-fix.

Likely suspects (hypotheses, not assertions)

1. WebKitGTK behaviour: Tauri uses WebKitGTK on Linux instead of WebView2. Some WebKitGTK versions have runaway-memory patterns under HMR + large bundles in dev mode.
2. Sidecar process leak: dreamcoder-sidecar is a compiled bun bundle. On Linux it's launched as a child via portable-pty. PTY buffer / session state leaks would balloon over time.
3. Computer Use mode: screenshot mode allocates large image buffers. It should be off by default on Linux but the gating may not be tight.
4. MCP server lifecycle: spawn-but-never-reap.
5. Bun runtime memory under long-lived servers — known rough edges.

What we need from Linux users to reproduce

If you hit this, the following information would massively accelerate the fix:

• Distro + kernel (uname -a, cat /etc/os-release)
• Desktop environment + display server (X11 / Wayland)
• WebKitGTK version (pkg-config --modversion webkit2gtk-4.1 or similar)
• DreamCoder source: dev mode (bun run dev) vs an installed binary? Commit SHA or version?
• When did the freeze happen: first launch? After loading a project? After an extended session? With Computer Use enabled?
• Snapshot of ps aux | grep -iE "dreamcoder|sidecar|claude" near the freeze, if obtainable

Acceptance / fix criteria

• Reliable reproduction on at least one mainstream Linux distro (Ubuntu 22.04 / 24.04 LTS, Fedora, Arch).
• Root cause identified: which process is leaking, and why.
• Fix lands and steady-state RSS on Linux is comparable to Windows (under 1 GB during a normal session).
• A Linux user re-runs the build and confirms the fix.

Related

• Reported by @Kafkacodes in [good first issue] Add dark-mode screenshots to README via <picture> tag #8.
• Surfaces a broader truth about platform coverage; tracking that separately as a docs PR (Platform Support table for README).

[Kafkacodes]

@GoDiao Sir i was tired yesterday so i didnt told you the problem in brief
the major issues i faced was

Dependencies not installed - node_modules and Tauri packages were missing initially.

Tauri CLI missing - Running bun run tauri dev failed because the Tauri CLI was not yet installed locally.

Sidecar binary missing - DreamCoder required a compiled sidecar executable (dreamcoder-sidecar-*) that had not been built.

Missing dist/ folder - Tauri expected frontend build files in dist/, but they did not exist initially.

High memory usage - DreamCoder's WebKit process consumed around 9–10 GB of RAM, which is unusually high.

OOM (Out Of Memory) kill - Linux killed the WebKit process when memory ran out to protect the system.

Desktop freezing - Before swap was added, the app caused mouse lag and temporary system freezes due to memory pressure.

WebKit/Tauri rendering issues The app likely had compatibility problems with WebKitGTK on Arch Linux.

i'll try to re-run the app again after installing it again so i can track the logs and find the real culprits which are causing these issues

[yayacat]

I also have this problem using the Dreamcoder developer version on my Windows 10 system.
(5945529)

[GoDiao]

@Kafkacodes — first, I owe you an apology. The build failures you hit (missing dependencies, missing Tauri CLI, missing sidecar binary, missing dist/) were not your fault — they were caused by gaps in our CONTRIBUTING and README. The current docs only tell you to run bun install once, never mention bun run build:sidecars, and the README and CONTRIBUTING actually contradict each other on whether to run bun run dev or bun run tauri dev. That's on us, and I'm opening a docs PR to fix it today.

Could you try this exact sequence on a fresh clone? The four steps matter — skipping any one of them produces a different breakage:

git clone https://github.com/GoDiao/dreamcoder.git
cd dreamcoder

# Step 1: install root workspace deps
# (this is what feeds the sidecar — Anthropic SDK, AWS SDK, ink, etc.)
bun install

# Step 2: install desktop deps
# (this is what installs the Tauri CLI itself + React frontend deps)
cd desktop && bun install

# Step 3: compile the sidecar binary
# (without this, Tauri's externalBin step in step 4 will fail)
bun run build:sidecars

# Step 4: launch dev mode
bun run tauri dev

For Arch Linux specifically, you may also need the Tauri Linux prerequisites (webkit2gtk-4.1, libgtk-3, etc. — Arch package names will differ from the Debian ones in the docs). I haven't validated which exact pacman packages are needed because I don't run Arch myself; if you figure it out, that's a great PR.

If the four steps above get you to a running app without the build errors, please confirm here. If you also still hit the 9-10 GB WebKit RAM issue afterwards, that's a real bug we'll continue tracking in this issue (separately from the build problems above).

Thanks for sticking with this — your detailed writeup is exactly what we needed.

[GoDiao]

@yayacat — thanks for confirming. Same apology to you: our docs currently don't fully explain the source-build setup, so I want to double-check before we conclude what bug you actually hit.

Could you confirm:

How did you build it? Did you run all four of these steps, or only some?

git clone https://github.com/GoDiao/dreamcoder.git
cd dreamcoder
bun install                  # root deps (sidecar)
cd desktop && bun install    # desktop deps (Tauri CLI, frontend)
bun run build:sidecars       # compile dreamcoder-sidecar.exe
bun run tauri dev            # launch

A docs PR with the correct build steps is going up today. If you can re-run after that with the four steps above and tell me which process goes bloated, that gives us much sharper data than the current "something is using a lot of memory" picture.

Thanks for the report.

[Kafkacodes]

@GoDiao Sir im thinking abt making a PR including a Readable text file in which we can put the app installation processes of different OS like linux andd a section for known troubles and their solutions open for people to contribute different troubles and their solutions

so it will like app's own wiki for common troubleshoot guide.

lemme know if this a good idea or not.