You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Activity
liangbaikaia commentedon Feb 7, 2026
还存在删除的时候报filename too long
liangbaikaia commentedon Feb 7, 2026
删除沙盒对话报错
liangbaikaia commentedon Feb 8, 2026
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.
liangbaikaia commentedon Feb 13, 2026
为什么还不修复
github-actions commentedon May 2, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.