Skip to content

snapshot: corrupt index causes repeated capture failures and unresponsive service #42237

Closed as not planned

Description

@ugur-murat-alt

Summary

Snapshot capture writes into per-workspace snapshot git repositories under
~/.local/share/opencode/snapshot/<project.id>/<hash>. When the service is
restarted (including automatic next channel updates) mid-capture, the
repository's .git/index is left corrupt (signature 0x00000000). From then
on every capture attempt fails with Git.OperationError: hatalı imza 0x00000000 / fatal: indeks dosyası hasarlı, producing thousands of warnings
per hour and eventually making the web UI (and service) unresponsive after
roughly 10-30 conversation steps.

Environment

  • opencode version: 0.0.0-next-17400 (observed failures also on 0.0.0-next-17292..17296)
  • OS: Linux 7.0.0-28-generic fix(install): check if the path export command already exists #28~24.04.1-Ubuntu SMP x86_64
  • Terminal: TERM=xterm-256color
  • Shell: /bin/bash
  • Install/channel: npm, next (auto-update observed: 13:57Z, 14:07Z, 14:17Z, 14:35Z, 14:46Z)
  • Active plugins: /home/ugur/Projects/opencode-omni/dist/plugin.js, /home/ugur/Projects/opencode-rust-coder

Reproduction

  1. Trigger a service restart while a session is active (e.g. opencode2 service restart, or wait for an automatic next update which restarts the service).
  2. Send a message in the web UI / any session. The snapshot capture runs per event and writes the snapshot repo index.
  3. If the restart interrupted a capture, subsequent captures keep failing: each event logs failed to capture snapshot with Git.OperationError: error: hatalı imza 0x00000000\nfatal: indeks dosyası hasarlı.
  4. After roughly 10-30 steps (5-20 minutes), the web UI stops responding.

Expected Behavior

  • Snapshot index writes should be atomic (temp file + rename) and/or capture should self-heal a corrupt index (e.g. recreate it) instead of failing forever.
  • A corrupt index should not accumulate failures to the point where the service becomes unresponsive.

Actual Behavior

  • packages/core/src/snapshot.ts has no atomic write pattern (no writeFile/rename) and no self-heal for a corrupt index.
  • Capture runs git subprocesses (packages/core/src/git.ts:192 run(cwd, proc)), so an interrupted write leaves a partial index.
  • 13,780 failed to capture snapshot warnings accumulated between 14:25Z and 19:24Z on 2026-08-12; the web UI became unresponsive in this window.
  • Manual repair (rm .git/index && git reset in the affected snapshot repos) stopped the failures completely: 0 failures after 19:24:33Z over 8+ hours.

Additional Context

  • Snapshot repos live at ~/.local/share/opencode/snapshot/<project.id>/<hash>; the git repository root is the session dir itself (branches/config/HEAD/index present, no nested .git).
  • Snapshot can be disabled via config ("snapshots": false, checked via Config.latest(config, "snapshots") !== false in snapshot.ts), but default-on should be resilient.
  • The affected repo index signature was 0x00000000 (4-byte check of the index file).
  • Workaround that resolved it: recreate the corrupt index files in the snapshot directories (rm index && git reset) and restart the service.

Activity

  1. github-actions commented on Aug 13, 2026

    @github-actions
    Contributor

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

  2. github-actions commented on Oct 13, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

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

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions