工作区报错bug #8778

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

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

Originally assigned to: @adamdotdevin on GitHub.

windows 最新版的opencode 桌面版 启用工作区后 创建了woektree目录 后来删除的时候无法删除 提示无权限,实际上是有的,无法删除的原因是虽然删除了worktree下面的数据,但是worktrae自己的目录被占用了无法删除,导致删除报错,再次点击删除工作区的时候提示找不到了

Originally created by @liangbaikaia on GitHub (Feb 7, 2026). Originally assigned to: @adamdotdevin on GitHub. windows 最新版的opencode 桌面版 启用工作区后 创建了woektree目录 后来删除的时候无法删除 提示无权限,实际上是有的,无法删除的原因是虽然删除了worktree下面的数据,但是worktrae自己的目录被占用了无法删除,导致删除报错,再次点击删除工作区的时候提示找不到了
yindo added the windowsweb labels 2026-02-16 18:10:49 -05:00
Author
Owner

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

还存在删除的时候报filename too long

@liangbaikaia commented on GitHub (Feb 7, 2026): 还存在删除的时候报filename too long
Author
Owner

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

删除沙盒对话报错

@liangbaikaia commented on GitHub (Feb 7, 2026): 删除沙盒对话报错
Author
Owner

@liangbaikaia commented on GitHub (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 commented on GitHub (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.
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#8778