Skip to content

Critical: Unbounded heap growth (37+ GB RSS) + orphaned processes on Linux #15348

Closed
Closed
Critical: Unbounded heap growth (37+ GB RSS) + orphaned processes on Linux#15348
Assignees
thdxr
Labels
coreAnything pertaining to core functionality of the application (opencode server stuff)perfIndicates a performance issue or need for optimization

Description

@WietRob
WietRob
opened on Feb 27, 2026

Summary

opencode exhibits unbounded heap memory growth on Linux, reaching 37+ GB RSS within ~30 minutes of normal usage. Additionally, orphaned opencode processes (TTY "?") remain running and continue consuming RAM/CPU even after terminal sessions end.

Critical finding: Private_Dirty memory accounts for 99.9% of RSS - this is heap memory allocated by opencode itself, not LSP children.

Environment

  • OS: Linux (KDE/Wayland), x86_64
  • opencode: 1.1.53 (installed via brew)
  • Repo: Medium/large monorepo with JS/TS + Python + Rust build artifacts

Evidence: Memory Analysis

Process 1: Active terminal session (most critical)

PID:        390314
PPID:       388470
TTY:        pts/8 (active terminal)
STAT:       Sl+
%CPU:       41-42% (continuous)
%MEM:       38-54% of 64GB system
RSS:        37.9 GB (growing)
VSZ:        164.7 GB
Runtime:    26+ minutes

smaps_rollup (the smoking gun):

Rss:            37965896 kB    (~37.9 GB total)
Pss_Anon:       37925564 kB    (~37.9 GB anonymous memory)
Private_Dirty:  37827316 kB    (~37.8 GB dirty heap)
Pss_File:          10269 kB    (~10 MB file-mapped)

→ 99.9% of memory is Private_Dirty heap, not file cache or shared memory.

Process 2: Orphaned process (lifecycle bug)

PID:        316456
PPID:       1541 (systemd/init)
TTY:        ?        ← No controlling terminal!
STAT:       Sl
%CPU:       35%
%MEM:       13.2%
RSS:        13 GB
Runtime:    59+ minutes

smaps_rollup:

Rss:            13071736 kB    (~13 GB)
Private_Dirty:  13039964 kB    (~13 GB heap)

This process has no TTY and continues running independently.

File descriptor counts

  • PID 390314: 118 open files
  • PID 316456: 78 open files

→ Not a file descriptor leak.

Process tree (PID 390314)

opencode,390314
  |-node,422681 .../biome lsp-proxy --stdio
  |   |-biome,422690 lsp-proxy --stdio (16 threads)
  |-opencode,396294 run .../pyright-langserver.js --stdio

→ Memory is in parent opencode process, not LSP children.

Reproduction Steps

  1. Start opencode in repository (my-project)
  2. Work normally for 10-30 minutes (navigation, search, agent runs)
  3. Observe ps aux --sort=-rss: opencode processes continuously grow RSS
  4. Exit terminal or start new sessions - some processes remain (TTY "?")
  5. Eventually system hits memory pressure, OOM killer terminates other apps

Repository Characteristics (possible triggers)

Path Size Notes
backend.log 126 MB Large log file
backend_restart.log 23 MB Large log file
orchestra/apps/desktop/src-tauri/target/debug/build/* 15-21 MB each Rust build artifacts
Multiple node_modules/ Unknown JS dependencies
Python .venv/ Unknown Python environment

Hypothesis

  1. Indexer/cache unbounded growth: opencode may be indexing files without respecting .gitignore/.ignore or without memory limits
  2. Heap leak: Continuous allocation without deallocation (possibly in file watcher, cache, or search index)
  3. Process lifecycle bug: Detached processes (TTY "?") not receiving shutdown signals

Questions for Maintainers

  1. Does opencode have a memory cap for indexes/cache?
  2. Are .gitignore and .ignore files respected during indexing?
  3. Is there a file size limit for indexing?
  4. What is the expected process lifecycle - should detached processes (TTY "?") auto-terminate?
  5. Where in the codebase should we look for unbounded cache/index growth?

Request

This makes opencode unusable for production work on Linux with medium+ repositories. Please advise:

  • Immediate workaround (config options to limit memory?)
  • Where in the codebase to investigate (indexer? cache? watcher?)
  • Whether a PR for memory bounds would be accepted

I'm happy to test patches, provide additional diagnostics, or help reproduce.

Diagnostics collected: 2026-02-27 10:56 CET
Evidence commands used:

ps aux --sort=-rss | head -20
cat /proc/$PID/smaps_rollup
pstree -ap $PID
lsof -p $PID | wc -l

Activity

  1. github-actions
    assigned
    thdxr
    on Feb 27, 2026
  2. github-actions
    added
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    perfIndicates a performance issue or need for optimization
    on Feb 27, 2026

  3. github-actions commented on Feb 27, 2026

    @github-actions
    github-actionsBot
    on Feb 27, 2026 – with GitHub Actions
    Contributor

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

    If your issue is distinct from the above, please clarify what differentiates it (e.g., a specific new reproduction path or additional data not covered by those reports).

  4. OmerFarukOruc commented on Feb 27, 2026

    @OmerFarukOruc
    OmerFarukOruc
    on Feb 27, 2026

    Workaround: oc-cleanup script

    I wrote a small script to manage this issue until it's fixed upstream. It finds and kills orphaned opencode processes (those with no TTY that survive terminal close).

    Quick install

    curl -fsSL https://gist.githubusercontent.com/OmerFarukOruc/d1bf2bb1f6f4f01c3a0e63288ada7c94/raw/oc-cleanup -o ~/.local/bin/oc-cleanup
chmod +x ~/.local/bin/oc-cleanup

    Usage

    oc-cleanup          # List orphaned processes
oc-cleanup kill     # Kill them all
oc-cleanup watch    # Monitor all opencode processes

    What it looks like

    ╭──────────────────────────────────────────────────────────╮
│ ⚠  Orphaned OpenCode Processes                          │
├──────────────────────────────────────────────────────────┤
│  💀 2681180    49 MB   0.1%  █░░░░░░░░░░░░░░░   0.2%   │
│  💀 2869680   250 MB   9.4%  █░░░░░░░░░░░░░░░   0.8%   │
├──────────────────────────────────────────────────────────┤
│  Total wasted: 298 MB (1.0% of system RAM)              │
│  Run oc-kill to free it                                 │
╰──────────────────────────────────────────────────────────╯

    Optional auto-cleanup via cron

    (crontab -l 2>/dev/null; echo "*/30 * * * * $HOME/.local/bin/oc-cleanup kill >/dev/null 2>&1") | crontab -

    Full gist with README: https://gist.github.com/OmerFarukOruc/d1bf2bb1f6f4f01c3a0e63288ada7c94

  5. WietRob commented on Mar 2, 2026

    @WietRob
    WietRob
    on Mar 2, 2026
    Author

    Closing as duplicate. Consolidating evidence in #14504 which has the root cause analysis and proposed fix.

  6. WietRob
    closed this as completedon Mar 2, 2026
  7. herjarsa
    added a commit that references this issue on Apr 25, 2026

    fix(opencode): resolve heap unlimited + orphan processes on Linux

    e7673ab
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

coreAnything pertaining to core functionality of the application (opencode server stuff)perfIndicates 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