文章目录分析1. WSL 被设计成 Windows 的一部分而不是沙箱2. Windows 权限模型本来就在保护系统文件3. WSL 最初的目标用户不是 AI Agent从今天2026的角度看规避手段或解决方法推荐方式WSL 文件到底存在哪里VS Code 能正常工作吗Docker Desktop 也是这样工作的如何彻底禁止访问 /mnt/c我个人更推荐哪种分析问题核心为什么微软默认把整个 Windows 系统盘挂载到/mnt/c而不是只挂载用户目录因为实际上/mnt/c/ ├── Windows/ ├── Program Files/ ├── Program Files(x86)/ ├── Users/ ├── ProgramData/ └──...WSL 看到的是整个 C 盘而不是/mnt/c/Users/xxx所以理论上你完全可以sudorm-rf/mnt/c/Windows或者sudorm-rf/mnt/c/Program Files这确实比仅共享用户目录危险得多。原因主要有三个。1. WSL 被设计成 Windows 的一部分而不是沙箱微软的设计理念是Windows Linux 一个开发环境而不是Windows ↓ 虚拟机 ↓ Linux他们希望 Linux 程序能够像 Windows 程序一样访问整个文件系统。例如cd/mnt/c/Windows/System32grepsomething *.logfind/mnt/c-name*.dll对于系统管理员、运维、开发者来说这种能力是有价值的。如果只开放C:\Users很多运维场景就做不了了。2. Windows 权限模型本来就在保护系统文件微软可能认为Linux 进程最终也是以 Windows 用户身份访问文件。例如rm/mnt/c/Windows/explorer.exe实际上会经过 Windows 的 NTFS 权限检查。很多关键文件属于TrustedInstaller SYSTEM Administrators普通用户并没有删除权限。所以很多危险操作会失败。但是——这只能保护一部分文件。用户有权限的内容C:\Users C:\Downloads C:\Documents仍然可以被删掉。因此风险依然存在。3. WSL 最初的目标用户不是 AI Agent这一点很关键。WSL 最早发布于 2016 年。当时微软假设的用户是Linux 开发者DevOps运维工程师程序员而不是Claude Code OpenAI Codex Cursor Agent Gemini CLI这种能够自动执行命令的 Agent。在 2016 年的设计视角里rm-rf/mnt/c/Windows属于“用户自己作死”。因为默认认为执行命令的人理解自己在做什么。而今天情况变了。很多人已经开始Agent ↓ Shell ↓ WSL ↓ /mnt/c这时候风险确实明显上升。从今天2026的角度看如果让我重新设计 WSL我可能会这样做默认 /mnt/c/Users 高级模式 /mnt/c或者Agent Safe Mode 不挂载系统目录 Developer Mode 挂载整个磁盘这样更符合现在 AI Agent 大量执行 Shell 命令的现实。但 WSL 的设计比 Claude Code、Cursor、Codex 这些产品早了接近十年当时几乎没人考虑过“自动化 Agent 误删主机系统”这个问题。所以你的直觉其实没错对于 AI Agent 时代来说默认暴露整个/mnt/c确实是一种偏危险的设计。很多使用 Claude Code 的开发者现在会刻意~/projects工作在 WSL 自己的 ext4 文件系统里甚至直接禁用自动挂载原因正是为了降低 Agent 或脚本误操作影响到 Windows 主机的风险。规避手段或解决方法不要把项目放在 Windows 文件系统/mnt/c/...里而是放在 WSL 自己的 Linux 文件系统里。很多人刚开始这样用/mnt/c/Users/yourname/projects/my-app实际上对应C:\Users\yourname\projects\my-appClaude Code、Cursor、Agent、脚本操作的是真实的 Windows 文件。如果 Agent 失控rm-rf../*删掉的可能是C:\Users\yourname\Documents C:\Users\yourname\Downloads C:\Users\yourname\Pictures甚至更糟。推荐方式项目放到/home/username/projects例如mkdir-p~/projectscd~/projectsgitclone https://github.com/xxx/my-app.git目录变成Ubuntu └── /home/xiang/projects/my-app而不是Windows └── C:\Users\xiang\projects\my-app此时pwd显示/home/xiang/projects/my-app而不是/mnt/c/Users/xiang/projects/my-appWSL 文件到底存在哪里实际上存储在一个虚拟磁盘文件里ext4.vhdx位置通常类似C:\Users\user\AppData\Local\Packages\ CanonicalGroupLimited... \LocalState\ ext4.vhdx你在 Linux 看到的是/home /etc /var /usr这些都在这个虚拟磁盘里面。因此rm-rf~/projects/test只会影响 Linux 环境。不会直接删除C:\Users C:\Windows C:\Program FilesVS Code 能正常工作吗完全没问题。推荐这样启动cd~/projects/my-app code.VS Code 会自动连接 WSL。左下角会显示WSL: Ubuntu此时Python 在 WSL 运行Node.js 在 WSL 运行Git 在 WSL 运行Claude Code 在 WSL 运行全部都在 Linux 环境。这是目前最推荐的开发方式。Docker Desktop 也是这样工作的你前面提到Windows └── WSL2 Ubuntu ├── Claude Code ├── Python ├── Node.js ├── Git └── Docker CLI其实 Docker Desktop 官方推荐也是~/projects而不是/mnt/c/projects因为文件 IO 更快inode 支持完整文件权限正常watch 机制稳定Git 性能更好如何彻底禁止访问/mnt/c如果你非常担心 Agent 误删 Windows 文件可以关闭自动挂载。编辑sudonano/etc/wsl.conf写入[automount] enabled false保存后退出。然后在 Windows PowerShellwsl--shutdown重新打开 Ubuntu。此时ls/mnt结果大概是空目录或者c 不存在这时候cd/mnt/c会直接报错。Claude Code 也无法访问 Windows 系统盘。我个人更推荐哪种对于使用 Claude Code 的开发者我更推荐✓ 项目放在 ~/projects ✓ Git 仓库放在 ~/projects ✓ Docker Engine 运行在 Docker DesktopDocker CLI 运行在 WSL ✓ VS Code Remote WSL ✗ 不关闭 /mnt/c可能有副作用原因是日常仍可访问下载目录复制文件方便不影响 Docker Desktop 集成不影响 VS Code只要养成一个习惯cd~/projects而不是cd/mnt/c/Users/xxx/project那么 Claude Code、Agent、脚本绝大部分操作都会被限制在 Linux 的 ext4 虚拟磁盘里误伤 Windows 的概率会大幅降低。真正会关闭/mnt/c自动挂载的人其实不多通常是安全要求较高的开发环境或者经常运行高权限自动化 Agent 的用户。
WSL2危险设计：默认挂载/mnt/c，易误删系统文件导致系统崩溃（附解决方法）（关闭自动挂载（不推荐关闭））/etc/wsl.conf
发布时间：2026/6/4 17:32:20
文章目录分析1. WSL 被设计成 Windows 的一部分而不是沙箱2. Windows 权限模型本来就在保护系统文件3. WSL 最初的目标用户不是 AI Agent从今天2026的角度看规避手段或解决方法推荐方式WSL 文件到底存在哪里VS Code 能正常工作吗Docker Desktop 也是这样工作的如何彻底禁止访问 /mnt/c我个人更推荐哪种分析问题核心为什么微软默认把整个 Windows 系统盘挂载到/mnt/c而不是只挂载用户目录因为实际上/mnt/c/ ├── Windows/ ├── Program Files/ ├── Program Files(x86)/ ├── Users/ ├── ProgramData/ └──...WSL 看到的是整个 C 盘而不是/mnt/c/Users/xxx所以理论上你完全可以sudorm-rf/mnt/c/Windows或者sudorm-rf/mnt/c/Program Files这确实比仅共享用户目录危险得多。原因主要有三个。1. WSL 被设计成 Windows 的一部分而不是沙箱微软的设计理念是Windows Linux 一个开发环境而不是Windows ↓ 虚拟机 ↓ Linux他们希望 Linux 程序能够像 Windows 程序一样访问整个文件系统。例如cd/mnt/c/Windows/System32grepsomething *.logfind/mnt/c-name*.dll对于系统管理员、运维、开发者来说这种能力是有价值的。如果只开放C:\Users很多运维场景就做不了了。2. Windows 权限模型本来就在保护系统文件微软可能认为Linux 进程最终也是以 Windows 用户身份访问文件。例如rm/mnt/c/Windows/explorer.exe实际上会经过 Windows 的 NTFS 权限检查。很多关键文件属于TrustedInstaller SYSTEM Administrators普通用户并没有删除权限。所以很多危险操作会失败。但是——这只能保护一部分文件。用户有权限的内容C:\Users C:\Downloads C:\Documents仍然可以被删掉。因此风险依然存在。3. WSL 最初的目标用户不是 AI Agent这一点很关键。WSL 最早发布于 2016 年。当时微软假设的用户是Linux 开发者DevOps运维工程师程序员而不是Claude Code OpenAI Codex Cursor Agent Gemini CLI这种能够自动执行命令的 Agent。在 2016 年的设计视角里rm-rf/mnt/c/Windows属于“用户自己作死”。因为默认认为执行命令的人理解自己在做什么。而今天情况变了。很多人已经开始Agent ↓ Shell ↓ WSL ↓ /mnt/c这时候风险确实明显上升。从今天2026的角度看如果让我重新设计 WSL我可能会这样做默认 /mnt/c/Users 高级模式 /mnt/c或者Agent Safe Mode 不挂载系统目录 Developer Mode 挂载整个磁盘这样更符合现在 AI Agent 大量执行 Shell 命令的现实。但 WSL 的设计比 Claude Code、Cursor、Codex 这些产品早了接近十年当时几乎没人考虑过“自动化 Agent 误删主机系统”这个问题。所以你的直觉其实没错对于 AI Agent 时代来说默认暴露整个/mnt/c确实是一种偏危险的设计。很多使用 Claude Code 的开发者现在会刻意~/projects工作在 WSL 自己的 ext4 文件系统里甚至直接禁用自动挂载原因正是为了降低 Agent 或脚本误操作影响到 Windows 主机的风险。规避手段或解决方法不要把项目放在 Windows 文件系统/mnt/c/...里而是放在 WSL 自己的 Linux 文件系统里。很多人刚开始这样用/mnt/c/Users/yourname/projects/my-app实际上对应C:\Users\yourname\projects\my-appClaude Code、Cursor、Agent、脚本操作的是真实的 Windows 文件。如果 Agent 失控rm-rf../*删掉的可能是C:\Users\yourname\Documents C:\Users\yourname\Downloads C:\Users\yourname\Pictures甚至更糟。推荐方式项目放到/home/username/projects例如mkdir-p~/projectscd~/projectsgitclone https://github.com/xxx/my-app.git目录变成Ubuntu └── /home/xiang/projects/my-app而不是Windows └── C:\Users\xiang\projects\my-app此时pwd显示/home/xiang/projects/my-app而不是/mnt/c/Users/xiang/projects/my-appWSL 文件到底存在哪里实际上存储在一个虚拟磁盘文件里ext4.vhdx位置通常类似C:\Users\user\AppData\Local\Packages\ CanonicalGroupLimited... \LocalState\ ext4.vhdx你在 Linux 看到的是/home /etc /var /usr这些都在这个虚拟磁盘里面。因此rm-rf~/projects/test只会影响 Linux 环境。不会直接删除C:\Users C:\Windows C:\Program FilesVS Code 能正常工作吗完全没问题。推荐这样启动cd~/projects/my-app code.VS Code 会自动连接 WSL。左下角会显示WSL: Ubuntu此时Python 在 WSL 运行Node.js 在 WSL 运行Git 在 WSL 运行Claude Code 在 WSL 运行全部都在 Linux 环境。这是目前最推荐的开发方式。Docker Desktop 也是这样工作的你前面提到Windows └── WSL2 Ubuntu ├── Claude Code ├── Python ├── Node.js ├── Git └── Docker CLI其实 Docker Desktop 官方推荐也是~/projects而不是/mnt/c/projects因为文件 IO 更快inode 支持完整文件权限正常watch 机制稳定Git 性能更好如何彻底禁止访问/mnt/c如果你非常担心 Agent 误删 Windows 文件可以关闭自动挂载。编辑sudonano/etc/wsl.conf写入[automount] enabled false保存后退出。然后在 Windows PowerShellwsl--shutdown重新打开 Ubuntu。此时ls/mnt结果大概是空目录或者c 不存在这时候cd/mnt/c会直接报错。Claude Code 也无法访问 Windows 系统盘。我个人更推荐哪种对于使用 Claude Code 的开发者我更推荐✓ 项目放在 ~/projects ✓ Git 仓库放在 ~/projects ✓ Docker Engine 运行在 Docker DesktopDocker CLI 运行在 WSL ✓ VS Code Remote WSL ✗ 不关闭 /mnt/c可能有副作用原因是日常仍可访问下载目录复制文件方便不影响 Docker Desktop 集成不影响 VS Code只要养成一个习惯cd~/projects而不是cd/mnt/c/Users/xxx/project那么 Claude Code、Agent、脚本绝大部分操作都会被限制在 Linux 的 ext4 虚拟磁盘里误伤 Windows 的概率会大幅降低。真正会关闭/mnt/c自动挂载的人其实不多通常是安全要求较高的开发环境或者经常运行高权限自动化 Agent 的用户。
