delete worktree error #8830

Open
opened 2026-02-16 18:10:57 -05:00 by yindo · 3 comments
Owner

Originally created by @liangbaikaia on GitHub (Feb 8, 2026).

Originally assigned to: @adamdotdevin on GitHub.

Title:
Worktree directory cannot be deleted after removing a workspace, leading to "filename too long" and sandbox errors

Description:
After enabling the Workspace feature in the latest OpenCode Desktop (Windows) and creating a worktree directory, attempting to delete the workspace fails with a permission denied error—even though the user has full permissions.

Further investigation shows that while the contents inside worktree can be deleted, the worktree directory itself remains because it is locked/in-use by the system or OpenCode process. This prevents the directory from being removed.

Subsequent attempts to delete the workspace then produce different errors:

The workspace appears "missing" but still exists in an inconsistent state.
Operations fail with filename too long errors.
In sandboxed conversations, related file operations also throw errors.

This suggests a resource leak or improper cleanup when removing a workspace, leaving behind a locked worktree directory that blocks future operations and causes cascading failures.

Steps to Reproduce:

Install the latest version of OpenCode Desktop on Windows.
Enable the Workspace feature in settings.
Create a new workspace (which automatically generates a worktree directory).
Attempt to delete the workspace via the UI.

Expected: Workspace and worktree directory are fully removed.
Actual: Deletion fails with "permission denied" despite user having full control permissions.

Manually delete all files/subdirectories inside worktree (if possible), but leave the empty worktree folder.
Try deleting the workspace again.

Observed errors:

Workspace listed as "not found" but still partially exists.
filename too long errors appear in logs/UI.
Sandbox conversations involving file operations fail with similar path-related errors.

Expected Behavior:

Workspace deletion should completely remove the worktree directory and all associated resources.
No residual locks or directory handles should remain after deletion.
Subsequent workspace operations should function normally without path-length or permission errors.

Actual Behavior:

The worktree directory remains after deletion attempt, locked by a process (likely OpenCode or a system service).
Follow-up deletion attempts fail with misleading errors (filename too long, "workspace not found").
Sandboxed conversations encounter file operation failures due to the lingering directory/path issues.

Environment:

OS: Windows (latest version, e.g., Windows 11 23H2 or newer)
OpenCode Desktop Version: Latest (as of 2026-02-08)
Feature Flag: Workspace enabled
Relevant Settings: Sandbox mode enabled (if applicable)

Possible Root Causes (Speculative):

File Handle Leak: OpenCode or a child process (e.g., file indexer, git operation) keeps an open handle to the worktree directory after workspace deletion, preventing removal.
Path Length Issue: Windows MAX_PATH limitation (260 chars) may be exceeded during cleanup, causing filename too long errors when trying to delete nested remnants.
Sandbox Isolation: Sandboxed conversations may inherit or re-trigger the locked path issue, propagating errors to sandboxed file operations.

Additional Notes:

Manual deletion of the worktree folder via command line (e.g., rmdir /s) also fails while the app is running, confirming a handle lock.
Restarting OpenCode may allow deletion, indicating the lock is held by the app process.
Logs from OpenCode (if available) likely show failed cleanup attempts or lingering git/worktree operations.

Suggested Fixes (for maintainers):

Ensure all file handles to the worktree directory are closed before marking the workspace as deleted.
Implement a forced cleanup routine (e.g., retry deletion with handle release on app shutdown).
Consider using extended-length paths (\?\ prefix) to bypass Windows path limits during cleanup.
Add explicit error handling for ERROR_DIR_NOT_EMPTY, ERROR_ACCESS_DENIED, and ERROR_FILENAME_EXCED_RANGE during workspace removal.

Attachments:

Screenshots of error messages (if available).
Relevant log excerpts from OpenCode (e.g., %APPDATA%\OpenCode\logs).

Please let me know if additional details or logs are needed to reproduce or diagnose this issue.

Originally created by @liangbaikaia on GitHub (Feb 8, 2026). Originally assigned to: @adamdotdevin on GitHub. Title: Worktree directory cannot be deleted after removing a workspace, leading to "filename too long" and sandbox errors Description: After enabling the Workspace feature in the latest OpenCode Desktop (Windows) and creating a worktree directory, attempting to delete the workspace fails with a permission denied error—even though the user has full permissions. Further investigation shows that while the contents inside worktree can be deleted, the worktree directory itself remains because it is locked/in-use by the system or OpenCode process. This prevents the directory from being removed. Subsequent attempts to delete the workspace then produce different errors: The workspace appears "missing" but still exists in an inconsistent state. Operations fail with filename too long errors. In sandboxed conversations, related file operations also throw errors. This suggests a resource leak or improper cleanup when removing a workspace, leaving behind a locked worktree directory that blocks future operations and causes cascading failures. Steps to Reproduce: Install the latest version of OpenCode Desktop on Windows. Enable the Workspace feature in settings. Create a new workspace (which automatically generates a worktree directory). Attempt to delete the workspace via the UI. Expected: Workspace and worktree directory are fully removed. Actual: Deletion fails with "permission denied" despite user having full control permissions. Manually delete all files/subdirectories inside worktree (if possible), but leave the empty worktree folder. Try deleting the workspace again. Observed errors: Workspace listed as "not found" but still partially exists. filename too long errors appear in logs/UI. Sandbox conversations involving file operations fail with similar path-related errors. Expected Behavior: Workspace deletion should completely remove the worktree directory and all associated resources. No residual locks or directory handles should remain after deletion. Subsequent workspace operations should function normally without path-length or permission errors. Actual Behavior: The worktree directory remains after deletion attempt, locked by a process (likely OpenCode or a system service). Follow-up deletion attempts fail with misleading errors (filename too long, "workspace not found"). Sandboxed conversations encounter file operation failures due to the lingering directory/path issues. Environment: OS: Windows (latest version, e.g., Windows 11 23H2 or newer) OpenCode Desktop Version: Latest (as of 2026-02-08) Feature Flag: Workspace enabled Relevant Settings: Sandbox mode enabled (if applicable) Possible Root Causes (Speculative): File Handle Leak: OpenCode or a child process (e.g., file indexer, git operation) keeps an open handle to the worktree directory after workspace deletion, preventing removal. Path Length Issue: Windows MAX_PATH limitation (260 chars) may be exceeded during cleanup, causing filename too long errors when trying to delete nested remnants. Sandbox Isolation: Sandboxed conversations may inherit or re-trigger the locked path issue, propagating errors to sandboxed file operations. Additional Notes: Manual deletion of the worktree folder via command line (e.g., rmdir /s) also fails while the app is running, confirming a handle lock. Restarting OpenCode may allow deletion, indicating the lock is held by the app process. Logs from OpenCode (if available) likely show failed cleanup attempts or lingering git/worktree operations. Suggested Fixes (for maintainers): Ensure all file handles to the worktree directory are closed before marking the workspace as deleted. Implement a forced cleanup routine (e.g., retry deletion with handle release on app shutdown). Consider using extended-length paths (\\?\ prefix) to bypass Windows path limits during cleanup. Add explicit error handling for ERROR_DIR_NOT_EMPTY, ERROR_ACCESS_DENIED, and ERROR_FILENAME_EXCED_RANGE during workspace removal. Attachments: Screenshots of error messages (if available). Relevant log excerpts from OpenCode (e.g., %APPDATA%\OpenCode\logs). Please let me know if additional details or logs are needed to reproduce or diagnose this issue.
yindo added the windowsweb labels 2026-02-16 18:10:57 -05:00
Author
Owner

@github-actions[bot] commented on GitHub (Feb 8, 2026):

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

  • #12606: 工作区报错bug (Chinese report of the exact same Windows workspace deletion issue with locked worktree directory that cannot be deleted)
  • #10257: OpenCode Desktop consumes lots of CPU cycles on Mac M4 & freezes completely while trying new WorkSpace feature (related workspace feature issues on Desktop)
  • #4656: Executing run command in worktree reports 'file already exists' error (Windows worktree file system issues)

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

@github-actions[bot] commented on GitHub (Feb 8, 2026): This issue might be a duplicate of existing issues. Please check: - #12606: 工作区报错bug (Chinese report of the exact same Windows workspace deletion issue with locked worktree directory that cannot be deleted) - #10257: OpenCode Desktop consumes lots of CPU cycles on Mac M4 & freezes completely while trying new WorkSpace feature (related workspace feature issues on Desktop) - #4656: Executing run command in worktree reports 'file already exists' error (Windows worktree file system issues) Feel free to ignore if none of these address your specific case.
Author
Owner

@liangbaikaia commented on GitHub (Feb 8, 2026):

same like #12606

@liangbaikaia commented on GitHub (Feb 8, 2026): same like #12606
Author
Owner

@liangbaikaia commented on GitHub (Feb 13, 2026):

为啥还不修复

@liangbaikaia commented on GitHub (Feb 13, 2026): 为啥还不修复
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#8830