[BUG] File corruption on VirtualBox shared folders (vboxsf) when writing settings files

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?

Description

Claude Code corrupts files it keeps open (e.g., .claude/settings.json, .claude/settings.local.json, .claude/skills/) when running on VirtualBox shared folders (vboxsf). This happens because vboxsf doesn't fully support POSIX file semantics — specifically, the atomic-replace write pattern (write to temp file → rename over original) breaks when the original file is held open by the process.

Environment

• Host: Windows (NTFS)
• Guest: Ubuntu (VirtualBox/Vagrant) - Claude Code is running inside VM
• Filesystem: vboxsf (VirtualBox shared folders)

What Should Happen?

Claude should edit the settings file without an error.

Error Messages/Logs

● Update(.claude/settings.json)
  ⎿  Error: ENOENT: no such file or directory, open '/vagrant/project/.claude/settings.json'

Steps to Reproduce

Steps to Reproduce

1. Run Claude Code on a project directory mounted via VirtualBox shared folder
2. Use /config to change a setting (e.g., output style)
3. The file's inode gets corrupted on the host filesystem

Root Cause

The standard safe-write pattern (write temp file → atomic rename over original) doesn't work correctly on vboxsf. When a file is held open and then replaced via rename, the old file handle points to a stale inode, corrupting the file from the host's perspective.

Affects any file Claude Code keeps open while also writing to:

• .claude/settings.json
• .claude/settings.local.json
• ~/.claude.json

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude Code v2.1.63

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

IntelliJ IDEA terminal

Additional Information

Current Workaround

Symlink the affected files to storage inside the VM (not on the shared folder):

# With Claude Code stopped:
mv /vagrant/project/.claude/settings.local.json ~/settings.local.json
ln -s ~/settings.local.json /vagrant/project/.claude/settings.local.json

Possible Fix

• Detect vboxsf (via /proc/mounts or stat -f) and use in-place writes (truncate + write) instead of atomic replace for settings files.
• Or: don't keep settings files open — read on demand and release the handle, so the write pattern doesn't matter.