Snapshot git add runs indefinitely on worktrees with large non-code files

[ihubanov]

Description

When opencode is used in a workspace that contains large non-code files (media files, datasets, ML models, etc.), the snapshot system's git add . can run indefinitely, consuming excessive CPU and memory.

The snapshot system maintains a separate git repo to track worktree state. It runs git add . against the full worktree on every agentic step (via the add effect in snapshot/index.ts). When the worktree contains large directories with binary/media files, this operation never completes in a reasonable time.

Steps to reproduce

1. Open opencode in a workspace containing a large directory (e.g. 500MB+ of media files, datasets, or ML model weights)
2. Start a session and interact with the assistant
3. Observe git add . and git pack-objects processes consuming high CPU/memory indefinitely

Observed behavior

• git add . ran for 3+ hours at ~90% CPU
• The subsequent hourly git gc (snapshot cleanup) consumed ~3.7GB of RAM trying to repack the bloated snapshot repo
• The system became sluggish and required manual process killing

Expected behavior

The snapshot system should handle large worktrees gracefully — either by timing out and excluding large/binary files, or by respecting size limits.

Environment

• OS: Linux (Ubuntu)
• opencode version: v1.2.27

[github-actions]

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

• [BUG] Snapshot module ignores 'watcher.ignore' config, causing excessive disk usage and performance degradation #8887: Snapshot module ignores watcher.ignore config, causing the same git add . performance degradation on large files/directories
• Very slow session due to 98GB of git snapshots #3182: Very slow session due to git snapshots processing large binary/dependency files (same root cause)

[ihubanov]

Thanks for flagging these — #8887 and #3182 are definitely the same root cause.

#8887 proposes respecting the existing watcher.ignore config in the snapshot module, which makes sense as a proactive fix. Our PR (#18069) takes a complementary approach with a runtime safety net: a 15-second timeout on git add . that triggers automatic exclude generation only when the operation is actually slow. This handles cases where users haven't configured watcher.ignore (which seems common given #3182).

Ideally both approaches could be combined — respect watcher.ignore upfront (as #8887 suggests) AND have a timeout fallback for unconfigured workspaces. Happy to update the PR to incorporate the watcher.ignore integration from #8887 if the maintainers prefer a combined fix.

Linking: this also fixes #8887 and #3182.

[00sapo]

Any temporary workaround?