[BUG] Write tool ignores umask and creates files with hardcoded 600 permissions

[em]

Version: 2.0.50

Environment:

• OS: Linux
• Installation method: npm-global
• umask: 002

Description:

The Write tool creates files with hardcoded 600 permissions (-rw-------) instead of respecting the system umask setting. With umask 002, files should be created with 664 permissions (-rw-rw-r--), allowing group read/write access.

This breaks standard Unix permission models and prevents team collaboration when multiple users need to access files created by Claude Code.

Steps to Reproduce:

1. Set umask to 002: umask 002
2. Verify umask: umask outputs 002
3. Use Write tool to create a file
4. Check file permissions: ls -la <filename>

Expected Behavior:

Files created by Write tool should respect umask:

• umask 002 → files created with 664 (-rw-rw-r--)
• umask 022 → files created with 644 (-rw-r--r--)

Actual Behavior:

All files created with 600 (-rw-------) regardless of umask setting.

Example Output:

$ umask
002
$ ls -la test-file.txt
-rw------- 1 claude devs 39 Nov 23 10:38 test-file.txt

Impact:

• Files are inaccessible to group members
• Breaks multi-user development workflows
• Violates Unix permission conventions
• No automated workaround possible - see below

Why There's No Workaround:

The natural solution would be to use a PostToolUse hook to automatically fix permissions after Write operations:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write",
        "hooks": [{
          "type": "command",
          "command": "input=$(cat); file_path=$(echo \"$input\" | jq -r '.tool_input.file_path'); chmod 664 \"$file_path\""
        }]
      }
    ]
  }
}

However, PostToolUse hooks are completely non-functional in Claude Code 2.0.50. They do not execute at all, despite correct configuration. This is documented in:

• #6403 - PostToolUse hooks do not execute
• #6305 - PreToolUse/PostToolUse hooks broken
• #2891 - Hooks not executing despite following documentation

Result: Two compounding bugs with no workaround:

1. Write tool ignores umask (this issue)
2. The documented hook system that would fix #1 doesn't work

Current Manual Workaround:

Run chmod 664 <filename> manually after every single Write operation.

[github-actions[bot]]

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/11912

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[d5ve]

I confirm that this is a new bug. The Write tool has created many files for me in the past, including last week. But this morning I had the first case of new files created with a restrictive permission set that prevented my web server from accessing them.

Version: 2.0.50

My umask is 0002

[g0morra]

We've also been experiencing this since yesterday, specifically with the Write tool. Claude Code version: 2.0.50

Expected behavior:

• Files: 0644 (rw-r--r--)
• Directories: 0755 (rwxr-xr-x)

Actual behavior:

• Write tool creates files with 0600 (rw-------)
• Write tool auto-creates parent directories with 0700 (rwx------)
• Bash operations (mkdir, etc.) correctly respect umask

Test output:

$ umask
0022

$ ls -ld perms_test perms_test/auto_created_dir
drwxr-xr-x  3 testuser  staff  96 Nov 24 11:24 perms_test           # mkdir via Bash ✓
drwx------  3 testuser  staff  96 Nov 24 11:26 perms_test/auto_created_dir  # Write tool ✗

$ ls -l perms_test/*.txt perms_test/auto_created_dir/*.txt
-rw-------  1 testuser  staff  11 Nov 24 11:24 perms_test/foo.txt              # Write tool ✗
-rw-------  1 testuser  staff  31 Nov 24 11:26 perms_test/auto_created_dir/bar.txt  # Write tool ✗

Impact: Breaking shared production environments where group read access is required.

Temporary workarounds:

Git pre-commit hook:

  #!/bin/sh
  find . -type f -perm 0600 -exec chmod 644 {} \;
  find . -type d -perm 0700 -exec chmod 755 {} \;

Shell alias:

  alias fix-perms='find . \( -type f -perm 0600 -exec chmod 644 {} \; \) -o \( -type d -perm 0700 -exec chmod 755 {} \; \)'

Request: Either force Write to respect the user's umask, or add umask or filePermissions setting to .claude/settings.json.

[michaelanthonyfeather]

Can confirm this issue it happening for me, having to change 600 to 644

[aaronjensen]

@em FWIW this hook works for me with 2.0.53 (which still has the permissions defect)

"hooks": {
  "PostToolUse": [
    {
      "matcher": "Write",
      "hooks": [
        {
          "type": "command",
          "command": "chmod 644 \"$(jq -r '.tool_input.file_path')\""
        }
      ]
    }
  ]
}

[em]

Additional side-effect of this bug to point out:

Error: Watcher error: Error: EACCES: permission denied, watch '/home/m/projects/api/src/Codegen/Codegen_Preprocessing.res.tmp.3363182.1764141661259'
Error: Watcher error: Error: EACCES: permission denied, watch '/home/m/projects/api/src/Codegen/Codegen_Preprocessing.res.tmp.3363182.1764141679715'
Error: Watcher error: Error: EACCES: permission denied, watch '/home/m/projects/api/src/Codegen/Codegen_Transform.res.tmp.3363182.1764141727687'
Error: Watcher error: Error: EACCES: permission denied, watch '/home/m/projects/api/src/Codegen/Codegen_Preprocessing.res.tmp.3363182.1764142033723'
Error: Watcher error: Error: EACCES: permission denied, watch '/home/m/projects/api/src/Codegen/Codegen_Transform.res.tmp.3363182.1764142039110'
Error: Watcher error: Error: EACCES: permission denied, watch '/home/m/projects/api/src/Codegen/Codegen_Preprocessing.res.tmp.3363182.1764143092736'
Error: Watcher error: Error: EACCES: permission denied, watch '/home/m/projects/api/src/Codegen/Codegen_Transform.res.tmp.3363182.1764143106418'
Error: Watcher error: Error: EACCES: permission denied, watch '/home/m/projects/api/src/Codegen/Codegen_Transform.res.tmp.3363182.1764143220518'

Constantly get these in my build tool because it's also writing these junk .tmp files with invalid permissions. Make sure the fix also covers these .tmp files. Or better yet don't write tmp files locally like this....... that's what /tmp is for.

[kees]

Yes, this is very frustrating -- I collaborate between user ids with a shared group. This needs to respect "umask" again.

[em]

This is still not fixed. This is not acceptable behavior for a professional software organization. This was a critical breaking change to claude-code that should have resulted in an immediate all-hands rollback and wasn't. Does anyone even work on this thing?

3 weeks have gone by and it hasn't even been acknowledged. Let alone the correct response of instantly rolling back.

The workaround pointed out using WriteTool hooks does not work for me. Because WriteTool hooks are also buggy and broken.

My only workaround has been I have to have prompts everywhere in every claude instruction reminding it to manually use chmod to fix its broken file permissions and I have to constantly tell it every time it doesn't remember to. It is unacceptable. I have been dealing with this for 3 weeks!

[mikiobraun]

Yep, same here. (MacOS, version 2.0.69)