allow_cowork_file_delete tool returns "Permission denied" without showing permission dialog

I am experiencing the same regression bug and it is very disruptive, I tried many changes to the application permissions at the macos level along with cache resets and it still persist making the agent prone to error. Fixing this would be amazing

Looks like this happens only for folders that need admin perms. This also happens on Windows 11.

I think it happens for more than admin folders, it seems to be all folders.

I've fighting this for few days here are all the steps I took:
Issue Reproduction & Troubleshooting Summary:
I am experiencing the same silent "Permission denied" failure with the allow_cowork_file_delete tool. To isolate whether this was a macOS system issue or an internal application bug, I ran through a comprehensive permission reset protocol.

Here are the steps taken that did not resolve the issue, confirming this is an internal bug in Claude Desktop rather than an OS-level restriction:

macOS TCC Reset: Used tccutil reset All com.anthropic.claudefordesktop to clear macOS Transparency, Consent, and Control caches.

Clean Reinstall & Cache Wipe: Performed a complete removal of the app, including wiping the Application Support and hidden ~/.claude directories before reinstalling.

Directory Ownership Reset: Ran recursive chown and chmod on the project directories to ensure the application wasn't hitting an admin/root escalation wall.

Fresh Directory Testing: I created a brand new test folder inside my standard Documents directory. While this action successfully triggered the initial macOS system-level folder access prompt (which I granted), Claude's internal allow_cowork_file_delete tool still failed instantly with "Permission denied" without ever showing its own internal execution dialog.

Result: The failure persists even immediately after macOS folder permissions are freshly and successfully granted. The desktop UI is entirely swallowing the internal tool's permission dialog, confirming the block is strictly internal to the current build of the application.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

I am having this issue with both dispatch and cowork desktop.

I tried this:

i just tried this:

Me: craete a test file and delete it

Claude:
Ran a command
Ran a command
Confirmed — I can create files in your folder but deletion is blocked by the sandbox, regardless of who created the file. You'll need to delete lu381uvr5.tmp manually from File Explorer.

I never get a prompt or anything, I have had to manually deleete things or dig through directories to find ranaom temp/ lock files.

Same symptom reproduced on Windows 11 Pro 25H2 (Claude Desktop 1.18286.0, MSIX install, local NTFS drive) — the deletion permission dialog never appears and allow_cowork_file_delete is denied silently, in both "Ask before acting" and "Act without asking" modes.

Filed as a separate issue for Windows platform tracking with full repro steps and environment details:
https://github.com/anthropics/claude-code/issues/74324

Since this issue is marked stale but the bug still reproduces on another platform, it may warrant re-triage — the failure is likely platform-independent (dialog rendering / permission IPC layer rather than OS-specific).

Similar symptom here, but scoped to a specific folder (real path) and fully persistent.

Summary
All mcp__workspace__* tools (bash, web_fetch) return "Permission to use mcp__workspace__bash has been denied." in every session that selects one particular folder. No permission dialog is ever shown.

Environment

• Claude Desktop / Cowork on Windows
• Model: Fable 5 (also reproduced with Opus 5 sessions)

Reproduction / What I ruled out

• Manual-approval mode: denied immediately, no dialog shown (screenshot available)
• Auto-approval mode, brand-new chat: still denied
• Selecting the same folder via a directory junction (different path, same target): denied — the block seems to be keyed to the resolved real path
• Sessions with no folder selected: bash works fine
• Sessions selecting a different real folder: bash works fine
• Session restart / app restart / PC reboot: no effect
• Built-in tools (Read/Grep/Write/WebSearch) work normally in the affected sessions
• Repo-level .claude/settings.json has no deny rules for these tools

Possible trigger
Both occurrences started immediately after running a log-compression workflow that issues a large number of consecutive bash calls. It looks as if a deny was silently recorded (dialog suppressed) and then persisted at app/account level, bound to the folder's real path.

Impact
No workaround found — the folder is unusable for any shell-dependent work in Cowork. We currently route all repo writes through Claude Code (CLI), which is unaffected.

Happy to provide screenshots or logs if useful.