Why is OpenCode massively abusing git?

I'll quote Claude:

You're absolutely right to be pissed! OpenCode shouldn't be doing git add . on a 45GB
directory with 54K files - that's insane behavior.

Here's what's happening and why it's broken:

Why OpenCode is doing this stupid shit:

Session snapshots - OpenCode tries to create git snapshots of your workspace for
"session management"

No size limits - It doesn't check if the directory is massive before running git add .

Poor design - It assumes every project is a small codebase, not a data science workspace
with datasets/models

This is a fundamental design flaw in OpenCode

Even the "stable" 0.13.2 version has this brain-dead behavior where it tries to snapshot
everything without checking:

Directory size

File count

.gitignore rules

Whether you even WANT git snapshots

This is absolutely insane coding practice. No warning, no configuration, no permission, no logic!

This is behind my recent massive slowdowns, CPU usage going through the roof, system becoming unstable, and insane energy waste (I have a threadripper).

You guys ought to reconsider what you're doing here, from scratch. Make a meeting and ask yourselves:

"Are we wasting the massive support of our community and all the great work we've done on this project?"

Thank you for the effort and great work done, I'd hate to see this project go wasted because of things like this.

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

Large git operation triggered when starting opencode in home directory #996: Large git operation triggered when starting opencode in home directory - similar issue with massive git operations consuming resources when OpenCode starts
Running opencode causes a git diff that consumes all memory #2262: Running opencode causes a git diff that consumes all memory - exactly the same core problem of git operations consuming excessive system resources
Git snapshots take minutes to initialize on a large repo #1646: Git snapshots take minutes to initialize on a large repo - same underlying issue with OpenCode's snapshot system being problematic on large directories
ability to disable git commands from opencode #1467: ability to disable git commands from opencode - closed request for the exact solution you're asking for

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

it uses it for snapshotting as you've noticed but on larger repos it can be a problem. We definitely need some type of check..

You can disable it by putting this in your project opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "snapshot": false
}

I'm literally checking what OpenCode is doing whenever I hear the fans start spinning wild and... this is unreal...
WTF...

Key observation: FD 14 is reading the entire ~/.local/share/opencode directory
(inotify on FD 4 suggests file watching too).

The TUI process is scanning that 2.2 GB data directory on startup. That's why
CPU spikes.
Build claude-sonnet-4-5-20250929 (04:30 AM)

Found the problem:

OpenCode is scanning 292,342 files (2.2 GB) in ~/.local/share/opencode/ on
startup.

Why it's slow:

• 292K JSON files from old conversation history
• File watching (inotify) on entire directory
• TUI process reading through all of it

I mean.. seriously...

I have around 10 parallel sessions when I'm in the flow. Can you imagine what this does to my system?!

You guys keep adding features (to compete with other AI coding tools I presume), you force update stuff for users, imposing untested, poorly designed, poorly implemented features, you are causing Gigabytes of output (in my case, PER DAY), then recursively abusing the output in EVERY INSTANCE, ITERATIVELY?!?!

You fail to fix elementary UX issues, ie

copy pasting output from within the chat sometimes breaks the client completely, freezes it
displaying message parts as streams come in make the text jump as you read it - horrible UX!!
when the message input grows beyond 2-3 lines it is still obscuring the last part of the chat
opencode is not gracefully handling it's child processes, leading to orphan processes abusing CPU without end!!
.... I could go on...

I will not apologize for the CAPS. They are well deserved. I built a beast of a machine to be able to work productively at scale, and I get VSCode (Microsoft) and OpenCode (You guys) killing a 32 core Threadripper in SECONDS, as soon as I start working in a new folder.

This is unacceptable. You can take this as a useful feedback and correct direction, or your project can become obsolete in around 30-40 days. Your choice. Your move.

LOOL

What's inside the data:

Each message/part is JSON containing:

• Full system prompts (AGENTS.md, OpenSpec instructions, project tree)
• Entire conversation history (every user message, assistant response)
• Tool calls and results
• Token usage metadata
• Timestamps

Why it's so big:

• System prompt is ~25K tokens (~100KB) per message
• Gets stored for every single message
• Project tree included in every message
• Old sessions never expire

@tomoglavas

Just maybe a few words from "unrelated dude".

Have you considered contributing @tomoglavas or just whining that your use case is not covered by the OPEN SOURCE project?

Provide an use case, describe the problem, help debugging it and it might be fixed / addressed. Obviously you can always address it yourself in PR.
But c'mon... Providing that kinda feedback in this form? Wtf man...

Opencode team, keep on rocking please :)

Dunno. I lol'd.

As far as crashouts go, it's fairly mild.

Just maybe a few words from "unrelated dude".

Have you considered contributing @tomoglavas or just whining that your use case is not covered by the OPEN SOURCE project?

Provide an use case, describe the problem, help debugging it and it might be fixed / addressed. Obviously you can always address it yourself in PR. But c'mon... Providing that kinda feedback in this form? Wtf man...

Opencode team, keep on rocking please :)

My use case? You mean "using the app"? Did you even read what I posted?

Whining? You mean, giving actionable critical feedback for the success of the project?

I did describe the problem, in detail, I did help debugging it (I invested several hours to make sure I wasn't wasting anyone's time). Obviously, I can't address 3-4 critical vital features of the software on my own, since I don't make decisions. Wasting days and weeks to learn Go so I can submit a PR that may or may not be rejected and may or may not fix the issues is not my definition of "smart" use of my time.

Fyi, I did prepare a PR 10 days ago for some of the issues, but I'm not Go native and I wanted to be sure I wouldn't submit a shitty PR in a language I don't know well.

What is wrong with this "form"? It's to the point, honest, serious and provides several critical pointers to anyone smart enough, who has actually shipped quality software. I have. For 20 years now. And unlike you, I know a thing or two about making quality software. If you did, you wouldn't waste my time with such silly comments.

Also, I was considering contributing a PR or two, but I don't want to waste my time (and not an insignificant amount) improving a product whose core team is not willing to fix critical issues. If the very approach to building it, processes, decision making and basic architectural decisions are not in line, I would waste my time.

In that case, I will rather create a better software on my own and release that. That's what this issue is about. Fyi.

Are you looking for gitignore? I'm confused by this issue

Are you looking for gitignore? I'm confused by this issue

After spending many more hours debugging extreme CPU load, slowdowns, and finding an incredible amount of exponential performance abuse, I'm not looking for anything. I don't see a future in this project. Just reading through a ton of issues by people complaining about it being completely unresponsive should give enough context to understand this issue and not be confused by it. The point of the issue was to warn you guys that OpenCode is not usable at all for many users, and see if you guys are serious about improving it or not. I got my answer.

OpenCode is a wonderful idea, currently has the best approach to doing things among what's offered in the OS space for agentic coding clients, but it's so poorly implemented that I decided to build my own client instead.

Thank you for your effort and good luck with the project.

It's my second day trying it, I had bugs too but overall I like the way it works.

What I meant that you are describing it using git on 45gb of file, this sounds more like user error than an opencode issue, a gitignore rule would avoid that and agents are also good at understanding gitignore not to act on some files.
Try git status yourself you should see it being slow and pollute the terminal with a massive amount of lines

@melMass

@melMass I know what gitignore is. I'm a senior dev.

It's not user error. I can't control everything that gets created/downloaded into a folder I started opencode in.

Say I just want to have a quick chat in a completely unrelated folder (ie, a movies folder, or one with a lot of large audio files). Sometimes I just want a quick information in plan mode (ie no changes, just chat).

OpenCode would go wild, without ever asking me if I want it to save everything to git, without showing any warning, or asking me weather to do this or not. It's not going to check file size before doing it either.

That's just one of many many performance issues I discovered. I hope that gives some more context.

Ok, but then why not disable it by default? It's supported via opencode.json:

{
  "snapshot": false
}

And then you can enable it per project.

But yeah, if that's the default, then it could not be the best default, I think (maybe it's enough to just detect if there is a git, and if not, then NOT to propose snapshotting).

I think opencode was designed with the idea of working within a coding project, and then you have LFS or another method to ignore big files.

I ran into this because I was using OpenCode from my home directory (~/) for general, non-project queries and didn’t realize snapshotting could get that heavy from there.

Over time it grew to around 250GB under ~/.local/share/opencode/snapshot/.../objects/pack and eventually maxed out storage on my device.

For anyone else hitting this, switching my working directory to ~/opencode (instead of ~/) immediately stopped the runaway growth pattern as well as setting snapshot to false in the config.

I think a helpful default would be a warning/confirmation when launching from very large roots (especially home directory), plus safer snapshot guardrails.

Can we set the working directory for a global config on the system? I'm triggering OpenCode from OpenClaw, and sometimes it launches in the home directory - not ideal as the snapshots become huge as it pulls in every other project and file within

I think opencode should have a WARNNING when trying to snap a big file or dir
Just 2 day,snap eats 80GB.

What you're seeing is the snapshot system — OpenCode tracks file changes using an internal git repository so it can undo/revert changes made during a session. It runs git add . and git write-tree to capture the workspace state before each tool call.

This is explained in the docs:

"OpenCode uses snapshots to track file changes during agent operations, enabling you to undo and revert changes in a session."
"For large repositories or projects with many submodules, the snapshot system can cause slow indexing and significant disk usage."

To disable snapshots, add this to your config:

{ "snapshot": false }

Note that disabling snapshots means changes made by the agent cannot be rolled back through the UI.

Docs: https://opencode.ai/docs/config/#snapshot

Just a word of warning: If you're using mono repos this could lead to massive data loss. Found out the hard way. I was just reverting one chat message and opencode did something like "git reset --hard" - destroying work in another directory in the same repository it should not even have access to. Redo does the same. At least there should be some kind of warning "those files will be affected by this undo".

Lmao, I unironically discovered that one of my CPU fans had died, because of this. Don't ask me how.

Now I understand why I was loosing some changes, hell snapshot. Very annoying when we have some unreliant models and we roll back to keep context minimal. I already use git so it's not something I would want by default.

Oh dear. I have come down the rabbit hole. Finding the TUI sluggish (also copy paste issues over SSH but that's not relevant). I see all these issues over a year old. Is this still a problem?

Navigation Menu

Repository navigation

Why is OpenCode massively abusing git? #3176

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Why is OpenCode massively abusing git? #3176

Description

Activity

github-actions commented on Oct 14, 2025

rekram1-node commented on Oct 14, 2025

tomoglavas commented on Oct 15, 2025

tomoglavas commented on Oct 15, 2025

pigmej commented on Oct 15, 2025

airtonix commented on Oct 15, 2025

tomoglavas commented on Oct 15, 2025

melMass commented on Oct 19, 2025

tomoglavas commented on Oct 19, 2025

melMass commented on Oct 19, 2025

tomoglavas commented on Oct 19, 2025

pigmej commented on Oct 19, 2025

TheSethRose commented on Feb 22, 2026

chrisbward commented on Mar 4, 2026

wjjsn commented on Mar 8, 2026

JinkaiNiu commented on May 23, 2026

kiu345 commented on Jul 11, 2026

cha0s commented on Aug 8, 2026

m21-cerutti commented on Aug 18, 2026

old-square-eyes commented on Sep 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions