anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 10:15:31 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Why is OpenCode massively abusing git? #2106

New Issue
Open
opened 2026-02-16 17:34:10 -05:00 by yindo · 13 comments
yindo commented 2026-02-16 17:34:10 -05:00
Owner
Copy Link
Copy Source

Originally created by @tomoglavas on GitHub (Oct 14, 2025).

Originally assigned to: @thdxr on GitHub.

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:

  1. Session snapshots - OpenCode tries to create git snapshots of your workspace for
    "session management"
  2. No size limits - It doesn't check if the directory is massive before running git add .
  3. 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.

Originally created by @tomoglavas on GitHub (Oct 14, 2025). Originally assigned to: @thdxr on GitHub. 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: > > 1. Session snapshots - OpenCode tries to create git snapshots of your workspace for > "session management" > 2. No size limits - It doesn't check if the directory is massive before running git add . > 3. 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.
yindo commented 2026-02-16 17:34:11 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Oct 14, 2025):

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

  • #996: Large git operation triggered when starting opencode in home directory - similar issue with massive git operations consuming resources when OpenCode starts
  • #2262: Running opencode causes a git diff that consumes all memory - exactly the same core problem of git operations consuming excessive system resources
  • #1646: Git snapshots take minutes to initialize on a large repo - same underlying issue with OpenCode's snapshot system being problematic on large directories
  • #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.

@github-actions[bot] commented on GitHub (Oct 14, 2025): This issue might be a duplicate of existing issues. Please check: - #996: Large git operation triggered when starting opencode in home directory - similar issue with massive git operations consuming resources when OpenCode starts - #2262: Running opencode causes a git diff that consumes all memory - exactly the same core problem of git operations consuming excessive system resources - #1646: Git snapshots take minutes to initialize on a large repo - same underlying issue with OpenCode's snapshot system being problematic on large directories - #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.
yindo commented 2026-02-16 17:34:11 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Oct 14, 2025):

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
}
@rekram1-node commented on GitHub (Oct 14, 2025): 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 } ```
yindo commented 2026-02-16 17:34:11 -05:00
Author
Owner
Copy Link
Copy Source

@tomoglavas commented on GitHub (Oct 14, 2025):

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.

@tomoglavas commented on GitHub (Oct 14, 2025): 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.
yindo commented 2026-02-16 17:34:11 -05:00
Author
Owner
Copy Link
Copy Source

@tomoglavas commented on GitHub (Oct 14, 2025):

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 commented on GitHub (Oct 14, 2025): 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 >
yindo commented 2026-02-16 17:34:11 -05:00
Author
Owner
Copy Link
Copy Source

@pigmej commented on GitHub (Oct 15, 2025):

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 :)

@pigmej commented on GitHub (Oct 15, 2025): 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 :)
yindo commented 2026-02-16 17:34:11 -05:00
Author
Owner
Copy Link
Copy Source

@airtonix commented on GitHub (Oct 15, 2025):

Dunno. I lol'd.

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

@airtonix commented on GitHub (Oct 15, 2025): Dunno. I lol'd. As far as crashouts go, it's fairly mild.
yindo commented 2026-02-16 17:34:11 -05:00
Author
Owner
Copy Link
Copy Source

@tomoglavas commented on GitHub (Oct 15, 2025):

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.

@tomoglavas commented on GitHub (Oct 15, 2025): > Just maybe a few words from "unrelated dude". > > Have you considered contributing [@tomoglavas](https://github.com/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.
yindo commented 2026-02-16 17:34:11 -05:00
Author
Owner
Copy Link
Copy Source

@melMass commented on GitHub (Oct 19, 2025):

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

@melMass commented on GitHub (Oct 19, 2025): Are you looking for gitignore? I'm confused by this issue
yindo commented 2026-02-16 17:34:11 -05:00
Author
Owner
Copy Link
Copy Source

@tomoglavas commented on GitHub (Oct 19, 2025):

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.

@tomoglavas commented on GitHub (Oct 19, 2025): > 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.
yindo commented 2026-02-16 17:34:11 -05:00
Author
Owner
Copy Link
Copy Source

@melMass commented on GitHub (Oct 19, 2025):

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 commented on GitHub (Oct 19, 2025): 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
yindo commented 2026-02-16 17:34:11 -05:00
Author
Owner
Copy Link
Copy Source

@tomoglavas commented on GitHub (Oct 19, 2025):

@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.

@tomoglavas commented on GitHub (Oct 19, 2025): @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.
yindo commented 2026-02-16 17:34:11 -05:00
Author
Owner
Copy Link
Copy Source

@pigmej commented on GitHub (Oct 19, 2025):

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.

@pigmej commented on GitHub (Oct 19, 2025): 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.
yindo commented 2026-02-16 17:34:11 -05:00
Author
Owner
Copy Link
Copy Source

@taoshengshi commented on GitHub (Jan 7, 2026):

opencode could try gitdata: https://dev.gitdata.ai

@taoshengshi commented on GitHub (Jan 7, 2026): opencode could try gitdata: https://dev.gitdata.ai
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#2106
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?