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