Skip to content

Opencode (1.2.24) leaks memory (until it's killed) #17237

Closed
Closed
Opencode (1.2.24) leaks memory (until it's killed)#17237
Assignees
thdxr
Labels
bugSomething isn't workingperfIndicates a performance issue or need for optimization

Description

@snajjar
snajjar
opened on Mar 12, 2026

Description

I've been hitting a recurring issue where opencode seems to keep growing in memory until it eventually gets killed by the Linux OOM killer.

When that happens, the terminal window is often left in a broken state. Mouse movement and key presses start showing up as raw escape sequences, the pointer can feel trapped inside the window, and the only reliable way out is to force-close it.

At first I thought this was a Hyprland problem, but after looking through logs and tracking memory over time, it looks more like opencode is the thing going wrong first, and the terminal/input breakage happens afterwards.

Environment

  • Lenovo laptop
  • Arch Linux / Kernel: 6.18.13-arch1-1
  • Hyprland
  • Kitty terminal
  • opencode 1.2.24 / no plugin
  • node 22.20.0
  • bun 1.3.10

What happens

The issue is not easy to trigger on demand. It tends to happen after opencode has been running for a while.

From what I could gather:

  • opencode keeps increasing its memory usage over time
  • eventually the machine goes into memory pressure
  • the kernel OOM killer selects .opencode
  • after that, the terminal is sometimes left in a corrupted input state

I attached memory graphs instead of pasting a wall of numbers, but the overall pattern is a clear upward trend followed by process death.

Image Image

Why I think opencode is the root cause

I originally suspected either Hyprland or terminal mouse/input handling, because the visible symptom is a terminal that looks half-frozen and keeps printing control sequences.

But the logs consistently point to .opencode being OOM-killed, and the broken terminal state seems to happen after that abrupt termination.

So my current understanding is:

  1. opencode grows in memory over time
  2. the system hits heavy memory pressure
  3. .opencode gets killed by the OOM killer
  4. the terminal is left behind in a bad raw/input state

That makes the issue look compositor-related from the outside, but the trigger seems to be inside opencode.

Expected behavior

  • opencode should not keep growing in memory during normal use
  • even if it crashes or gets terminated, it should not leave the terminal in a broken state

Actual behavior

  • memory usage keeps increasing over time
  • the process eventually gets killed by OOM
  • the terminal may become unusable afterwards and require force-closing

Activity

  1. snajjar
    added
    bugSomething isn't working
    on Mar 12, 2026
  2. github-actions
    assigned
    thdxr
    on Mar 12, 2026
  3. github-actions
    added
    perfIndicates a performance issue or need for optimization
    on Mar 12, 2026

  4. github-actions commented on Mar 12, 2026

    @github-actions
    github-actionsBot
    on Mar 12, 2026 – with GitHub Actions
    Contributor

    This issue might be a duplicate of existing issues. Please check:

    If your issue is distinct or adds new information not covered by the above, feel free to keep it open and note what differentiates it.

  5. snajjar
    changed the title [-]Opencode leaks memory (until it's killed)[/-] [+]Opencode (1.2.24) leaks memory (until it's killed)[/+] on Mar 12, 2026

  6. binarydoubling commented on Mar 13, 2026

    @binarydoubling
    binarydoubling
    on Mar 13, 2026

    Yep... yeah this is a major major major issue right now. I'm really sorry. I enjoyed using OpenCode and unfortunately cannot until this gets resolved... there's probably a LOT of places where memory is leaking, and it's ultimately up to the maintainers to triage everything, since they know the codebase best.

  7. jnorthrup commented on Mar 21, 2026

    @jnorthrup
    jnorthrup
    on Mar 21, 2026

    🚨 URGENT: Cross-Project Memory Leak Crisis - Hardware Damage Risk

    We investigated memory leaks across WebKit-based runtimes (Bun, Claude Code, OpenCode) and found a critical pattern affecting all embedders.

    Hardware Risk Statement

    On Apple Silicon Macs:

    • Memory exhaustion → kernel panic → forced power cycle
    • SOC (System on Chip) is non-replaceable ($500-1500 hardware loss)
    • Sustained memory pressure can cause thermal damage

    On Linux servers:

    • OOM kills → data corruption from unclean shutdowns
    • Kernel soft lockups (356s+) → system death requiring hard reset
    • Database corruption from abrupt termination

    Our Investigation Findings

    Bun Runtime (WebKit JSC):

    • 4 unique JSC GC memory leaks identified
    • JSC::SlotVisitor::drainFromShared race condition (7,214 frames)
    • WTF::HashTable::removeIterator (7,214 frames)
    • WTF::Vector<>::operator= (7,220 frames)
    • JSC::ASTBuilder::createForOfLoop (713 frames)

    OpenCode (from your issues):

    Common Root Cause

    WebKit JavaScriptCore parallel GC marking phase:

    • Multiple threads drain shared work queues
    • Race condition in SlotVisitor::drainFromShared
    • Iterator invalidation during concurrent access
    • Objects marked but not properly tracked → leak

    Upstream References

    Issue Project Status
    WPEWebKit #1622 SlotVisitor::drain crash Open
    WebKit #200863 SlotVisitor::visitChildren crash Open
    LLVM #115992 LSAN false positives Open
    Bun #28343 JSC GC tracking Open

    Tool We Built

    We created test/asan_tracker.zig (760 lines) that:

    • Parses ASAN/LSAN logs automatically
    • Classifies leaks by component (JSC, WTF, Bun, System)
    • Auto-symbolicates with source locations
    • Exports JSON for CI monitoring

    Happy to share this tool with OpenCode maintainers.

    Urgency: Auto-Close Bot Pattern

    We observed issues #17837 and #17185 were closed by github-actions bot within 2 hours for "contributing guidelines" - despite containing:

    • Detailed technical analysis
    • Reproduction steps
    • Root cause identification
    • PR with fixes

    This pattern is dangerous for memory safety issues:

    1. High-quality bug reports dismissed before maintainer review
    2. Hardware damage risk ignored
    3. Cross-project coordination blocked

    Recommended Actions

    Immediate:

    1. ⚠️ Disable auto-close for perf and bug labels
    2. ⚠️ Extend contribution window from 2h to 48h for complex bugs
    3. ⚠️ Require maintainer review before closing memory issues

    Short-term:

    1. Merge PR fix: multiple memory leaks in long-running sessions #10913 (4 leak fixes)
    2. Add RSS monitoring to CI
    3. Implement graceful degradation on memory pressure

    Long-term:

    1. Coordinate with WebKit upstream on GC fixes
    2. Share ASAN tracker tool across embedders
    3. Establish memory safety triage process

    Cross-Project Coordination

    We're coordinating with:

    Memory leaks don't respect project boundaries - this is an ecosystem-wide crisis.

    Evidence:

    Please prioritize this over formatting requirements.

  8. jnorthrup commented on Mar 21, 2026

    @jnorthrup
    jnorthrup
    on Mar 21, 2026

    🚨 URGENT: Cross-Project Memory Leak Crisis - Hardware Damage Risk

    We investigated memory leaks across WebKit-based runtimes (Bun, Claude Code, OpenCode) and found a critical pattern affecting all embedders.

    Hardware Risk Statement

    On Apple Silicon Macs:

    • Memory exhaustion → kernel panic → forced power cycle
    • SOC (System on Chip) is non-replaceable ($500-1500 hardware loss)
    • Sustained memory pressure can cause thermal damage

    On Linux servers:

    • OOM kills → data corruption from unclean shutdowns
    • Kernel soft lockups (356s+) → system death requiring hard reset
    • Database corruption from abrupt termination

    Our Investigation Findings

    Bun Runtime (WebKit JSC):

    • 4 unique JSC GC memory leaks identified via ASAN tracker
    • JSC::SlotVisitor::drainFromShared race condition (7,214 frames)
    • WTF::HashTable::removeIterator (7,214 frames)
    • WTF::Vector<>::operator= (7,220 frames)
    • JSC::ASTBuilder::createForOfLoop (713 frames)

    OpenCode (from your issues):

    Common Root Cause

    WebKit JavaScriptCore parallel GC marking phase:

    • Multiple threads drain shared work queues
    • Race condition in SlotVisitor::drainFromShared
    • Iterator invalidation during concurrent access
    • Objects marked but not properly tracked → leak

    Upstream References

    Issue Project Status
    WPEWebKit #1622 SlotVisitor::drain crash Open
    WebKit #200863 SlotVisitor::visitChildren crash Open
    LLVM #115992 LSAN false positives Open

    Tool We Built

    We created an ASAN tracker (760 lines of Zig) that:

    • Parses ASAN/LSAN logs automatically
    • Classifies leaks by component (JSC, WTF, Bun, System)
    • Auto-symbolicates with source locations
    • Exports JSON for CI monitoring

    Happy to share this tool with OpenCode maintainers.

    Urgency: Auto-Close Bot Pattern

    We observed issues #17837 and #17185 were closed by github-actions bot within 2 hours for "contributing guidelines" - despite containing:

    • Detailed technical analysis
    • Reproduction steps
    • Root cause identification
    • PR with fixes

    This pattern is dangerous for memory safety issues:

    1. High-quality bug reports dismissed before maintainer review
    2. Hardware damage risk ignored
    3. Cross-project coordination blocked

    Recommended Actions

    Immediate:

    1. ⚠️ Disable auto-close for perf and bug labels
    2. ⚠️ Extend contribution window from 2h to 48h for complex bugs
    3. ⚠️ Require maintainer review before closing memory issues

    Short-term:

    1. Merge PR fix: multiple memory leaks in long-running sessions #10913 (4 leak fixes)
    2. Add RSS monitoring to CI
    3. Implement graceful degradation on memory pressure

    Long-term:

    1. Coordinate with WebKit upstream on GC fixes
    2. Share ASAN tracker tool across embedders
    3. Establish memory safety triage process

    Cross-Project Coordination

    We're coordinating with:

    Memory leaks don't respect project boundaries - this is an ecosystem-wide crisis.

    Evidence:

    Please prioritize this over formatting requirements.

  9. thdxr commented on Apr 2, 2026

    @thdxr
    thdxr
    on Apr 2, 2026
    Member

    Closing in favor of #20695 where we're collecting all memory-related problems. Please follow that issue for updates.

  10. thdxr
    closed this as completedon Apr 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingperfIndicates a performance issue or need for optimization

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions