[BUG] Filesystem Connector Write Operations Failing Silently

Resolved 💬 6 comments Opened Dec 22, 2025 by i-am-matt-fairchild Closed Feb 28, 2026

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

  1. Start Claude Desktop with Filesystem connector enabled
  2. Attempt to write a file using Filesystem:write_file to any path within an allowed directory
  3. Tool returns success (no error message)
  4. Verify file does not exist on filesystem using terminal ls command
  5. Observe that the file was not created despite successful tool response

Expected Behavior

  • Filesystem:write_file should 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

  1. Early in session: Write operations worked successfully (one file was created and persisted)
  2. Mid-session: All subsequent write operations began failing silently across all directories
  3. After Claude Desktop restart: Issue persisted
  4. After enabling Full Disk Access: Issue persisted
  5. After computer restart: Issue persisted
  6. 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_directories configuration is correct
  • ✅ Tested write operations to multiple different paths
  • ✅ Attempted to use bash_tool as workaround (also fails)

Result: None of these steps resolved the issue.

Additional Observations

  1. bash_tool also affected: The bash_tool exhibits identical behavior (reports success, no file created), suggesting this is a deeper issue in Claude Desktop's execution environment, not just the Filesystem connector
  2. Read operations unaffected: All read operations work correctly throughout the entire session
  3. No error logging: No errors appear in macOS Console.app when filtering for "Claude"
  4. 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

  1. Investigate why write operations succeed initially but fail later in the session
  2. Add proper error handling and error messages when write operations fail
  3. Consider adding a verification step that checks if files were actually created
  4. Investigate if this is specific to certain macOS configurations or permissions
  5. Determine why bash_tool is 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:

  1. The tool should create the file with the specified content on disk
  2. The file should be immediately visible and accessible via filesystem commands (e.g., ls, cat)
  3. The tool should return a success response
  4. Subsequent Filesystem:read_file calls should return the written content
  5. 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.):

  1. The tool should return an error response with a descriptive error message
  2. No success response should be returned
  3. The error should be visible to both the AI and the user
  4. 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:

  1. Work consistently throughout a session (not work initially then fail later)
  2. Work reliably across application restarts
  3. Work for all paths within configured allowed_directories
  4. Behave independently of session state or conversation history
  5. 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:

  1. Success response = file was actually created on disk
  2. Error response = file was not created, with explanation why
  3. Never return success when the operation failed

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce

Prerequisites

  1. Install Claude Desktop for Mac (version 1.0.2339 or later)
  2. Enable the Filesystem extension (built-in)
  3. Configure at least one allowed directory in the Filesystem extension settings
  4. Grant Full Disk Access to Claude.app in macOS System Settings > Privacy & Security

Reproduction Steps

  1. Start a new conversation in Claude Desktop
  2. 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'"
  1. Observe that Claude reports the file was written successfully
  2. Open Terminal and navigate to the target directory
  3. Run ls -la to list directory contents
  4. Observe that the file does NOT exist despite Claude's success message

Alternative Reproduction (Direct Tool Call)

If able to trigger tool calls directly:

  1. Call Filesystem:write_file with:
  • path: A valid path within an allowed directory (e.g., "/Users/username/allowed-dir/test.txt")
  • content: Any string content (e.g., "test content")
  1. Observe the tool returns a success response
  2. 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_file and Filesystem:create_directory
  • The bash_tool exhibits identical symptoms when attempting file writes via echo "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_file returns 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_tool exhibits 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.provenance extended 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.json maintains correct structure after reinstall
  • allowed_directories array 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:

  1. Write verification step (check if file exists after write attempt)
  2. Detailed logging of all write operations (success and failure)
  3. Error logging when write system calls fail
  4. Session state tracking for filesystem operations
  5. Telemetry on write operation success rates

View original on GitHub ↗

This issue has 6 comments on GitHub. Read the full discussion on GitHub ↗