opencode eating 70gb of memory?

Description

Left opencode session on background (tmux session) not doing anything but an existing session open.

OpenCode version

1.0.141

Steps to reproduce

No response

Screenshot and/or share link

Operating System

macOS 26.1

Terminal

Ghostty + tmux

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

Single opencode session is consuming 23+GB of memory #3995: Single opencode session is consuming 23+GB of memory
Uses a huge amount of memory #3013: Uses a huge amount of memory
OpenTUI causes crashes and heavy memory usage #3798: OpenTUI causes crashes and heavy memory usage
Memory stays unbounded: ACP session map + compacted tool outputs #4315: Memory stays unbounded: ACP session map + compacted tool outputs
Excessive memory usage. #3530: Excessive memory usage (closed)
High RAM usage in latest release #2805: High RAM usage in latest release

Feel free to ignore if none of these address your specific case.

yeah same, it is asking for that much access, i cant use the unlimt command in linux, and i suspect memory leak too. i have to close the opencode completely after some hour and restart it otherwise it would get hang

yeah same , Macbook M1 , macos 26.1 (25B78) . eating 7GB of memory .

Can anyone share a session causing this?

opencode export > session.json

You can dm privately too

I can't replicate this

Can anyone share a session causing this?

opencode export > session.json

You can dm privately too

I can't replicate this

how/where do I dm you sir?

x or discord? click my gh profile for details

x or discord? click my gh profile for details

don't have x, I do have discord but link on profile says invalid.

dm:

aidenc9727 on discord

Same issue. Opencode consumed 15Gb Memory in one instance. With multiple parallel instances, ended up crashing my Xserver (Ubuntu 24.04) with 128Gb memory

Common pattern across all sessions:

2-3 opencode instances per git repo
Average 2-3 compactions per session
All running parallel

Same issue. Mac using Sequoia 15.7.2. node balloons to >70GB within 30 seconds... suspect it is b/c one of the sub-folders w/in the folder I start in has many large files, so my bad 😓

For me it also was rust. I mean rust_analyzer can take up it's ram. And I've seen opencode spawning multiple LSP instances at the same time. It would make sense that the ram is stacking up, allthough that would probably be another process (unless they are using a WASM / embedded build of rust_analyzer, I doubt).

So maybe it is rust_analyzer spamming opencode with LSP things which opencode just keeps around for no real reason?

same using the bun install command

Same issue with RAM usage here on a daily basis now. I have opencode working on PHP projects, no rust involved. Unfortunately not really useable right now.

same using the bun install command

Is that just bun install hanging? I had the same at some point but didn't check the ram usage.

I'm also getting it on macos (as the initial issue also was)

same using the bun install command

Is that just bun install hanging? I had the same at some point but didn't check the ram usage.

I'm also getting it on macos (as the initial issue also was)

Not at all when installing using Bun after running it runs under Bun process for some reason.

I just experienced the memory spike issue, opencode inside Docker container. The CPU went 100%, the MacBook fans started spinning like crazy and the memory use kept climbing up to 5 GB. I switched to new session and it was still going.

In my case the issue was with LSP server, specifically pyright-langserver. I've managed to capture htop output:

Once the CPU burn calmed down it's still using tons of RAM:

This RAM usage displayed in the opencode debug apparently does not take LSP servers into account:

Opencode 1.1.53, I forgot to update this morning, so if this is known issue / no longer helpful then apologies for the noise.

我在使用opencode+oh-my-opencode时，被吃掉80G内存后，强制让omo创建新任务时复用会话，内存不再增长了。opencode在会话结束后不会清理会话，导致内存泄漏。

the facts that this issue still hasn't been addressed is beyond me.

the facts that this issue still hasn't been addressed is beyond me.

The issue now is partially resolved for TUI, now after SQL migration it uses lesser memory (But now another issue is there, which dax says will be resolved in future, that we can't see the whole chat history)

same here 20gb

same :(

@rekram1-node

@rekram1-node

I been dealing with this for a few weeks with my personal machine(128gb macos) and my work machine (24gb macos). I have to go and clear opencode every now and then and i will have a few different issues.

I will have the proceses of past opencode run still in my task list but i dont see in the terminal more or less feels like an orphaned processes
if i look at lsof for a large opencode session i will see tons of file pointers open tty everything it feels like it is not doing a good job of its internal house keeping.

I typically will see the system start at 750mb of ram usage for reopening an existing session. When ever a command is issued i start getting new tile handlers open if i do lsof -p <process group> i will have my repo root (where i open the opencode tui) multiple times open and multiple /dev/ttyd022 open. There are are a lot of unix sockets open. What i see less of but still multiple are connections to the same sqlite databse files

This may be caused by bash-language-server's hardcoded --external-sources flag triggering unbounded ShellCheck memory growth. We hit the same pattern — 73 concurrent shellcheck processes consuming 17.8 GB, with individual processes growing to 3-5 GB RSS.

The upstream root cause fix has been merged: bash-lsp/bash-language-server#1376 adds a shellcheckExternalSources config option. Setting it to false omits --external-sources entirely.

Immediate workaround — set this env var before running opencode:

SHELLCHECK_EXTERNAL_SOURCES=false

Once opencode bumps its bash-language-server dependency to include this change, the config will be available natively. See also #16269 for the full analysis and #16271 for the OPENCODE_DISABLE_LSP mitigation PR.

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

Navigation Menu

Repository navigation

opencode eating 70gb of memory? #5363

Description

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

17 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

opencode eating 70gb of memory? #5363

Description

Description

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Activity

github-actions commented on Dec 11, 2025

ham-zax commented on Dec 11, 2025

supersongssr commented on Dec 11, 2025

rekram1-node commented on Dec 11, 2025

albertilagan commented on Dec 12, 2025

rekram1-node commented on Dec 12, 2025

albertilagan commented on Dec 12, 2025

rekram1-node commented on Dec 12, 2025

PSU3D0 commented on Dec 12, 2025

noneatarrival commented on Dec 18, 2025

17 remaining items

Sharktheone commented on Jan 22, 2026

beingsuz commented on Jan 23, 2026

jfkr commented on Jan 23, 2026

Sharktheone commented on Jan 23, 2026

beingsuz commented on Jan 24, 2026

d4rky-pl commented on Feb 11, 2026

zmlgit commented on Feb 25, 2026

aniel300 commented on Feb 25, 2026

dhruvkej9 commented on Feb 25, 2026

itxtoledo commented on Mar 2, 2026

code-xhyun commented on Mar 3, 2026

wojons commented on Mar 5, 2026

marcusquinn commented on Mar 6, 2026

thdxr commented on Apr 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions