[BUG] Filesystem Connector Write Operations Failing Silently
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Bug Report: Filesystem Connector Write Operations Failing Silently
Environment
- Application: Claude Desktop for Mac
- Version: 1.0.2339 (1782e2) 2025-12-16T19:35:52.000Z
- Filesystem Connector: ant.dir.ant.anthropic.filesystem (built-in extension)
- Full Disk Access: Enabled
Issue Summary
The Filesystem connector in Claude Desktop is experiencing a critical bug where write operations report success but fail to persist files to disk. The Filesystem:write_file and Filesystem:create_directory tools execute without errors and return success responses, but no files or directories are actually created on the filesystem. This issue affects all configured allowed directories, even with Full Disk Access enabled. Read operations continue to work correctly, indicating the connector is running but only the write pathway is broken. The issue manifested mid-session (after successfully writing one file early in the conversation) and persists across Claude Desktop restarts, computer restarts, and even after completely uninstalling and reinstalling the Filesystem extension. The bash_tool exhibits the same behavior, suggesting the underlying write mechanism in Claude Desktop is broken rather than just the Filesystem connector specifically. This makes all file creation workflows completely non-functional, as the AI believes it has successfully written files when in reality nothing has been saved to disk.
Configuration
Filesystem extension configuration from:~/Library/Application Support/Claude/Claude Extensions Settings/ant.dir.ant.anthropic.filesystem.json
{
"isEnabled": true,
"userConfig": {
"allowed_directories": [
"/Users/[username]/notes-with-claude",
"/Users/[username]/work/requirements-core",
"/Users/[username]/work/client-requirements"
]
}
}
Reproduction Steps
- Start Claude Desktop with Filesystem connector enabled
- Attempt to write a file using
Filesystem:write_fileto any path within an allowed directory - Tool returns success (no error message)
- Verify file does not exist on filesystem using terminal
lscommand - Observe that the file was not created despite successful tool response
Expected Behavior
Filesystem:write_fileshould create files that persist to disk- OR the tool should return an error if the write operation fails
- Files created should be visible in the filesystem immediately
Actual Behavior
- Tool returns success response with no errors
- No file is created on disk
- No error message is generated in Claude interface
- Terminal verification shows file does not exist
- Read operations (
Filesystem:read_file,Filesystem:list_directory) continue to work correctly
Timeline of Issue
- Early in session: Write operations worked successfully (one file was created and persisted)
- Mid-session: All subsequent write operations began failing silently across all directories
- After Claude Desktop restart: Issue persisted
- After enabling Full Disk Access: Issue persisted
- After computer restart: Issue persisted
- After uninstalling and reinstalling Filesystem extension: Issue persisted
Evidence
Successful Write (Early Session)
- One file was successfully created early in the conversation session
- This file still exists and is readable via
Filesystem:read_file - Proves the connector can work under certain conditions
Failed Writes (Later Session)
All subsequent write attempts failed across multiple directory levels:
- Root of allowed directory
- Subdirectories at various depths
- Both existing directories and new directories (via
create_directory) - Different allowed directories in the configuration
Troubleshooting Attempted
- ✅ Removed macOS extended attributes (
com.apple.provenance) from directories created via VS Code - ✅ Enabled Full Disk Access for Claude.app in macOS System Settings
- ✅ Restarted Claude Desktop application multiple times
- ✅ Restarted computer completely
- ✅ Uninstalled and reinstalled the Filesystem extension
- ✅ Verified
allowed_directoriesconfiguration is correct - ✅ Tested write operations to multiple different paths
- ✅ Attempted to use
bash_toolas workaround (also fails)
Result: None of these steps resolved the issue.
Additional Observations
- bash_tool also affected: The
bash_toolexhibits identical behavior (reports success, no file created), suggesting this is a deeper issue in Claude Desktop's execution environment, not just the Filesystem connector - Read operations unaffected: All read operations work correctly throughout the entire session
- No error logging: No errors appear in macOS Console.app when filtering for "Claude"
- Session state suspected: The fact that writes worked initially then stopped suggests some session state corruption
Impact
Severity: High
This bug makes the Filesystem connector completely unusable for any write operations, preventing:
- File creation workflows
- Requirements authoring
- Code generation and file output
- Any AI-assisted file management tasks
The silent failure is particularly problematic because the AI believes it has successfully completed the requested operation when nothing has actually been saved.
Logs
From ~/Library/Logs/Claude/main.log (showing connector initialization):
[info] MCP Server connection requested for: Filesystem
[info] Secure MCP Filesystem Server running on http://127.0.0.1:[port] with allowed_directories set from server args
No errors are logged when write operations are attempted.
Suggested Next Steps
- Investigate why write operations succeed initially but fail later in the session
- Add proper error handling and error messages when write operations fail
- Consider adding a verification step that checks if files were actually created
- Investigate if this is specific to certain macOS configurations or permissions
- Determine why
bash_toolis also affected (suggests issue at execution environment level)
What Should Happen?
What Should Happen
Successful Write Operation
When Filesystem:write_file is called with valid parameters to a path within an allowed directory:
- The tool should create the file with the specified content on disk
- The file should be immediately visible and accessible via filesystem commands (e.g.,
ls,cat) - The tool should return a success response
- Subsequent
Filesystem:read_filecalls should return the written content - The file should persist across application restarts
Failed Write Operation (Expected Error Handling)
When a write operation cannot be completed (due to permissions, disk space, invalid path, etc.):
- The tool should return an error response with a descriptive error message
- No success response should be returned
- The error should be visible to both the AI and the user
- The error message should indicate the specific reason for failure (e.g., "Permission denied", "Directory does not exist", "Disk full")
Consistent Behavior
Write operations should:
- Work consistently throughout a session (not work initially then fail later)
- Work reliably across application restarts
- Work for all paths within configured
allowed_directories - Behave independently of session state or conversation history
- Function the same whether it's the first write or the hundredth write in a session
Proper Tool Response Contract
The tool response should accurately reflect reality:
- Success response = file was actually created on disk
- Error response = file was not created, with explanation why
- Never return success when the operation failed
Error Messages/Logs
Steps to Reproduce
Steps to Reproduce
Prerequisites
- Install Claude Desktop for Mac (version 1.0.2339 or later)
- Enable the Filesystem extension (built-in)
- Configure at least one allowed directory in the Filesystem extension settings
- Grant Full Disk Access to Claude.app in macOS System Settings > Privacy & Security
Reproduction Steps
- Start a new conversation in Claude Desktop
- Ask Claude to write a file to a directory within the configured allowed directories
- Example: "Please write a test file to [allowed-directory-path]/test.txt with the content 'hello world'"
- Observe that Claude reports the file was written successfully
- Open Terminal and navigate to the target directory
- Run
ls -lato list directory contents - Observe that the file does NOT exist despite Claude's success message
Alternative Reproduction (Direct Tool Call)
If able to trigger tool calls directly:
- Call
Filesystem:write_filewith:
path: A valid path within an allowed directory (e.g., "/Users/username/allowed-dir/test.txt")content: Any string content (e.g., "test content")
- Observe the tool returns a success response
- Verify via terminal that no file was created at the specified path
Reproduction Rate
- Initial write in session: May succeed (inconsistent)
- Subsequent writes in same session: Fails 100% of the time
- After application restart: Fails 100% of the time
- After computer restart: Fails 100% of the time
Expected Result
The file should exist on disk at the specified path with the specified content.
Actual Result
- Claude reports success
- No file is created
- Terminal verification shows the file does not exist
- No error message is displayed
Additional Notes
- The issue may not manifest on the very first write attempt in a fresh session
- Once the issue appears, it persists indefinitely regardless of restarts
- The issue affects both
Filesystem:write_fileandFilesystem:create_directory - The
bash_toolexhibits identical symptoms when attempting file writes viaecho "content" > file.txt
Claude Model
Sonnet (default)
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
1.0.2339 (1782e2)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
Additional Technical Details That May Help Diagnosis
Tool Response Behavior
Filesystem:write_filereturns what appears to be a valid success response- No exception or error object is returned
- The response does not indicate any failure occurred
- This creates a "silent failure" where the AI has no indication anything went wrong
Timing and State Observations
- First successful write: Occurred early in conversation (within first 10-15 minutes)
- Failure onset: All writes after the first one failed, suggesting a state change
- No recovery: Once failures begin, no action restores functionality
- Consistent failure pattern: Every single write attempt fails after the initial success
Tool Interaction Pattern
- Read operations (
Filesystem:read_file,Filesystem:list_directory) work throughout entire session - Mixed read/write workflows fail at the write step
- The connector appears "half-functional" - reads work, writes don't
Cross-Tool Contamination
bash_toolexhibits identical behavior (silent write failures)- Suggests the issue may be at a lower level than the Filesystem connector itself
- Possible sandbox or process execution layer problem
- Both tools report success but produce no filesystem changes
macOS-Specific Context
- Directories created via VS Code had
com.apple.provenanceextended attribute - Removing this attribute did not resolve the issue
- Full Disk Access permission alone did not resolve the issue
- Combination of Full Disk Access + clean directories still failed
Configuration File Integrity
ant.dir.ant.anthropic.filesystem.jsonmaintains correct structure after reinstallallowed_directoriesarray is properly formatted and accessible- Extension shows as enabled (
"isEnabled": true) - No manual edits were made to configuration files
Comparison to Working State
The one successful write operation proves:
- The Filesystem connector CAN write files
- Permissions are correctly configured
- The allowed directories configuration is valid
- There's no fundamental OS-level block
This suggests:
- The issue is not a configuration problem
- The issue is not a permissions problem
- The issue appears to be a runtime state corruption
- Something changes during the session that breaks write operations
Reproducibility Concerns
- Issue may be difficult to reproduce in a fresh install/test environment
- The "works once, then breaks" pattern suggests a race condition or state corruption
- May require extended testing session to trigger
- May be related to specific conversation patterns or tool call sequences
Missing Error Information
Notable absence of error messages in:
- Claude Desktop UI (no error notifications)
- macOS Console.app (no Claude-related errors)
~/Library/Logs/Claude/main.log(write attempts not logged)- Terminal output from bash commands (commands appear to succeed)
This complete absence of error logging makes debugging extremely difficult.
Suggested Diagnostic Additions
To help diagnose this issue in future versions, consider adding:
- Write verification step (check if file exists after write attempt)
- Detailed logging of all write operations (success and failure)
- Error logging when write system calls fail
- Session state tracking for filesystem operations
- Telemetry on write operation success rates
This issue has 6 comments on GitHub. Read the full discussion on GitHub ↗