feat(filesystem): add --ignore-write option to block writes to sensit…

[SOURABHMISHRA5221]

Title:
feat(filesystem): add --ignore-write option to block writes to sensitive files (#1869)

Description:
This PR addresses issue #1869 by adding a flexible mechanism to prevent accidental overwrites of sensitive files (such as .env) in the Filesystem MCP server.

Summary of changes:

• Added a --ignore-write <pattern1> <pattern2> ... command-line argument to the filesystem server.
• The server now blocks write operations to any file matching the provided patterns (supports globs like .env, .env.*, *.secret, etc.), even if the file is within an allowed directory.
• Updated the README.md to document the new option and provide usage examples.
• Improved security and user control over which files are protected from write operations.

Motivation:
Previously, the server could overwrite sensitive files (e.g., .env) without confirmation, risking data loss. This change allows users to specify which files should never be overwritten, improving safety and flexibility.

Testing:

• Manually tested with various ignore patterns and confirmed that write operations to matching files are blocked with an appropriate error.
• Verified that normal write operations to non-matching files still succeed.

Documentation:

• Updated README.md with usage instructions and security notes for the new --ignore-write option.

Checklist:

• Thoroughly tested changes
• Documentation updated
• Linked to issue Filesystem MCP server modified .env without permission and did not back it up #1869
• No breaking changes

[SOURABHMISHRA5221]

Hi @tadasant
Could you please review this PR when you have a chance? Thank you!

[SOURABHMISHRA5221]

Hi! @olaservo please review.

[SOURABHMISHRA5221]

Hi @olaservo... Do you think we need to change something in this?

[olaservo]

Hi @olaservo... Do you think we need to change something in this?

Hi @SOURABHMISHRA5221 ! Thanks for the ping and sorry for the wait. I've started reviewing this and other filesystem PRs that relate to file exclusion patterns and restrictions, since there are a few out there, and we've also been doing some security hardening on this server. I expect to leave feedback on these soon, but if you don't hear back next week feel free to @ me again. We had a huge backlog of Readme updates that were adding some noise to mentions but I will keep an eye out. Thanks!

[SOURABHMISHRA5221]

Hi @olaservo!... Hope you're doing well. Just wanted to follow up on the PR review when you get a chance.

[olaservo]

Closing this PR — it has merge conflicts due to the major architecture refactoring (Nov 2025) and would need a full rewrite for the current registerTool() API.

Apologies for the long delay in getting back to you on this — I acknowledged your pings in July and then got pulled into other work. That's on me.

The feature request (issue #1869) is still valid, but there are some design considerations for a fresh implementation:

• The write guard should cover all mutating tools (write_file, edit_file, move_file), not just write_file
• The current codebase already has minimatch as a dependency, which would be better than hand-rolled glob matching
• The MCP protocol's ToolAnnotations (readOnlyHint, destructiveHint) may offer a protocol-level approach to this

Thank you for the contribution and your patience — the underlying need to protect sensitive files is real and we'll keep issue #1869 open.

This comment was posted by Claude Code on behalf of @olaservo.