claude-code - 💡(How to fix) Fix [BUG] Filesystem write_file tool does not preserve file permissions [3 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#47099Fetched 2026-04-13 05:41:30
View on GitHub
Comments
3
Participants
3
Timeline
6
Reactions
0
Timeline (top)
commented ×3labeled ×3

The Filesystem:write_file tool resets file permissions to a default (likely 644) when writing, even when overwriting an existing file that has non-default permissions set. This causes silent breakage when the tool is used to update executable scripts.

Permissions are reset to 644 on every write, stripping the execute bit. The file is silently non-executable.

Error Message

Error Messages/Logs

Root Cause

The Filesystem:write_file tool resets file permissions to a default (likely 644) when writing, even when overwriting an existing file that has non-default permissions set. This causes silent breakage when the tool is used to update executable scripts.

Permissions are reset to 644 on every write, stripping the execute bit. The file is silently non-executable.

Code Example



---

echo '#!/usr/bin/env bash\necho hello' > ~/test.sh
      chmod +x ~/test.sh
      ls -l ~/test.sh  # -rwxr-xr-x

---

ls -l ~/test.sh  # -rw-r--r-- — execute bit gone

---

import os, stat
existing_perms = stat.S_IMODE(os.stat(path).st_mode) if os.path.exists(path) else 0o644
# ... write file ...
os.chmod(path, existing_perms)
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

Summary

The Filesystem:write_file tool resets file permissions to a default (likely 644) when writing, even when overwriting an existing file that has non-default permissions set. This causes silent breakage when the tool is used to update executable scripts.

Permissions are reset to 644 on every write, stripping the execute bit. The file is silently non-executable.

Impact

  • Shell scripts updated via write_file silently lose their execute bit
  • The failure mode is downstream and non-obvious: the script exists, the content is correct, but it won't run
  • In this specific case: ~/Developer/claude-wrapper/bin/claude-wrapper (a symlink target) had +x stripped, causing claude (which symlinks to it) to fail silently on the next invocation
  • This has caused repeated debugging sessions across multiple conversations

What Should Happen?

write_file should preserve the existing file's permission bits when overwriting. If no prior file exists, 644 is a reasonable default.

Error Messages/Logs

Steps to Reproduce

  1. Create an executable script:

       echo '#!/usr/bin/env bash\necho hello' > ~/test.sh
       chmod +x ~/test.sh
       ls -l ~/test.sh  # -rwxr-xr-x
  2. Use Filesystem:write_file to update the file content

  3. Check permissions:

       ls -l ~/test.sh  # -rw-r--r-- — execute bit gone

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.104

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

Suggested Fix

Before writing, stat the existing file and restore its permission bits after the write:

import os, stat
existing_perms = stat.S_IMODE(os.stat(path).st_mode) if os.path.exists(path) else 0o644
# ... write file ...
os.chmod(path, existing_perms)

Or alternatively, expose an optional permissions parameter so callers can explicitly set mode bits when they know the file should be executable.

extent analysis

TL;DR

The Filesystem:write_file tool should be modified to preserve the existing file's permission bits when overwriting, or an optional permissions parameter should be exposed to allow callers to explicitly set mode bits.

Guidance

  • Before writing to a file, check if the file exists and retrieve its current permissions using os.stat() to preserve the execute bit.
  • After writing to the file, use os.chmod() to restore the original permissions.
  • Consider adding an optional permissions parameter to Filesystem:write_file to allow callers to explicitly set the mode bits when updating executable scripts.
  • Verify the fix by checking the file permissions after writing, using ls -l to confirm the execute bit is preserved.

Example

import os, stat
def write_file(path, content):
    existing_perms = stat.S_IMODE(os.stat(path).st_mode) if os.path.exists(path) else 0o644
    # write file content
    with open(path, 'w') as f:
        f.write(content)
    os.chmod(path, existing_perms)

Notes

This fix assumes that the Filesystem:write_file tool has access to the file system and can use os module functions. The suggested fix is a minimal modification to preserve the existing file permissions.

Recommendation

Apply workaround: Modify the Filesystem:write_file tool to preserve the existing file's permission bits when overwriting, as this is a more straightforward solution that does not require exposing additional parameters.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Filesystem write_file tool does not preserve file permissions [3 comments, 3 participants]