.git/index.lock stuck with "Resource busy" (EBUSY) — opencode holds `.git` dir open on encrypted APFS volume

[swayll]

Description

What happened

While working in a repository on an encrypted APFS volume, opencode performed git
operations (status/diff/log, then later a commit attempt). A .git/index.lock file
appeared and became permanently stuck:

• rm, mv, and python os.unlink() on .git/index.lock all fail with
  Resource busy (errno 16 / EBUSY).
• lsof .git/index.lock (and a search by inode) reports no holder.
• The lock file is 0 bytes.

Evidence / diagnosis

• The opencode process holds the repository root and the .git directory open as
  directory file descriptors (e.g. 49r, 54r, 55r → .git and repo cwd),
  even when it is not actively running a git command.
• The 0-byte lock suggests a git process created it via O_CREAT|O_EXCL and was
  interrupted before writing its content.
• On this encrypted APFS volume, unlinking a file inside a directory that another
  process keeps open (combined with fseventsd/mds activity) returns EBUSY, so the
  lock cannot be cleared without terminating the holder.

Workaround

Bypassed the lock by pointing git at a temporary index file:

export GIT_INDEX_FILE=/tmp/idx-myproject
git read-tree HEAD
git add <file>
git write-tree
git commit-tree <tree> -p HEAD
git update-ref HEAD <commit>

This works, but every subsequent normal git invocation inside the repo still hits
the stuck lock.

Questions / requested behavior

1. Does opencode keep the .git directory open as a directory watcher? If so, is it
   expected that this prevents .git/index.lock from being unlinked on macOS?
2. Should opencode clean up stray .git/index.lock files (or detect a dead lock)
   before running git operations?
3. Any known interaction with encrypted APFS volumes causing EBUSY on unlink?

Plugins

No response

OpenCode version

1.18.18 (installed via Homebrew, /opt/homebrew/bin/opencode)

Steps to reproduce

1. On macOS, clone a repository onto an encrypted APFS volume (Cryptomator WebDav)
   (/Volumes/CRYPT/...).
2. Open the repo with opencode (opencode, v1.18.18) and let it run its normal
   startup git inspection (git status, git diff, git log).
3. Attempt a commit from within the opencode session (e.g. git add + git commit)
   while opencode is still running.
4. Interrupt / let the session move on — a .git/index.lock file is left behind
   (0 bytes).
5. Observe:
   • ls -la .git/index.lock → file present, 0 bytes.
   • rm .git/index.lock → rm: .git/index.lock: Resource busy.
   • python3 -c "import os; os.unlink('.git/index.lock')" → OSError: [Errno 16] Resource busy.
   • lsof .git/index.lock → no output (no visible holder).
6. Confirm opencode still holds the .git directory open:
   lsof -p <opencode-pid> | grep '\.git' → DIR fds on .git and repo cwd.
7. Any subsequent git add/git commit inside the repo now fails with
   fatal: Unable to create '.../.git/index.lock': File exists..
   av(

Screenshot and/or share link

No response

Operating System

macOS 15.7.9, Apple Silicon

Terminal

No response

[github-actions]

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

• Orphaned index.lock in snapshot gitdir causes blocking snapshot queue on Windows (Git Bash / mintty) #29413: Similar symptom of an orphaned .git/index.lock left by opencode that cannot be removed without manual intervention. That issue focuses on the snapshot gitdir on Windows, but the root cause (opencode leaving a stale lock and holding git-related directory fds open) overlaps with what you describe here.

If your issue is specifically about the user repo's .git/index.lock being unremovable due to opencode keeping the .git directory open as a file descriptor (rather than the internal snapshot gitdir), it is likely a distinct but related bug and worth tracking separately.

[swayll]

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

• Orphaned index.lock in snapshot gitdir causes blocking snapshot queue on Windows (Git Bash / mintty) #29413: Similar symptom of an orphaned .git/index.lock left by opencode that cannot be removed without manual intervention. That issue focuses on the snapshot gitdir on Windows, but the root cause (opencode leaving a stale lock and holding git-related directory fds open) overlaps with what you describe here.

If your issue is specifically about the user repo's .git/index.lock being unremovable due to opencode keeping the .git directory open as a file descriptor (rather than the internal snapshot gitdir), it is likely a distinct but related bug and worth tracking separately.

Here is a clear, concise summary in English stating that the issues are analogous but not identical:

---

The two issues are analogous but not identical.

Both involve OpenCode leaving behind orphaned/stale .git/index.lock files, which then block subsequent Git operations and degrade performance. However, they differ in several key aspects:

• Orphaned index.lock in snapshot gitdir causes blocking snapshot queue on Windows (Git Bash / mintty) #29413 occurs on Windows (Git Bash/mintty), affects OpenCode's internal snapshot repository, and is triggered by abrupt process termination (closing the terminal, Ctrl+C). The lock file causes the snapshot queue to hang, making OpenCode appear frozen.

• actual occurs on macOS (encrypted APFS volumes), affects the user's working repository, and is caused by OpenCode holding open file descriptors on the .git directory, which prevents the OS from removing the lock file (resulting in EBUSY). This makes manual Git commands fail.

In short: same symptom (stale index.lock), same underlying category of problem (poor lock handling), but different environments, locations, and trigger mechanisms. They are related but distinct bugs.