WSL2危险设计：默认挂载/mnt/c，易误删系统文件导致系统崩溃（附解决方法）（关闭自动挂载（不推荐关闭））/etc/wsl.conf

文章目录

分析
- - [1. WSL 被设计成 Windows 的一部分，而不是沙箱](#1. WSL 被设计成 Windows 的一部分，而不是沙箱)
  - [2. Windows 权限模型本来就在保护系统文件](#2. Windows 权限模型本来就在保护系统文件)
  - [3. WSL 最初的目标用户不是 AI Agent](#3. WSL 最初的目标用户不是 AI Agent)
  - 从今天（2026）的角度看
规避手段或解决方法
- 推荐方式
- [WSL 文件到底存在哪里？](#WSL 文件到底存在哪里？)
- [VS Code 能正常工作吗？](#VS Code 能正常工作吗？)
- [Docker Desktop 也是这样工作的](#Docker Desktop 也是这样工作的)
- [如何彻底禁止访问 `/mnt/c`](#如何彻底禁止访问 /mnt/c)
- 我个人更推荐哪种？

分析

问题核心：

为什么微软默认把整个 Windows 系统盘挂载到 /mnt/c，而不是只挂载用户目录？

因为实际上：

bash 复制代码

/mnt/c/
├── Windows/
├── Program Files/
├── Program Files (x86)/
├── Users/
├── ProgramData/
└── ...

WSL 看到的是整个 C 盘，而不是：

bash 复制代码

/mnt/c/Users/xxx

所以理论上你完全可以：

bash 复制代码

sudo rm -rf /mnt/c/Windows

或者：

bash 复制代码

sudo rm -rf "/mnt/c/Program Files"

这确实比仅共享用户目录危险得多。

原因主要有三个。

1. WSL 被设计成 Windows 的一部分，而不是沙箱

微软的设计理念是：

text 复制代码

Windows + Linux = 一个开发环境

而不是：

text 复制代码

Windows
  ↓
虚拟机
  ↓
Linux

他们希望 Linux 程序能够像 Windows 程序一样访问整个文件系统。

例如：

bash 复制代码

cd /mnt/c/Windows/System32

bash 复制代码

grep something *.log

bash 复制代码

find /mnt/c -name "*.dll"

对于系统管理员、运维、开发者来说，这种能力是有价值的。

如果只开放：

text 复制代码

C:\Users

很多运维场景就做不了了。

2. Windows 权限模型本来就在保护系统文件

微软可能认为：

Linux 进程最终也是以 Windows 用户身份访问文件。

例如：

bash 复制代码

rm /mnt/c/Windows/explorer.exe

实际上会经过 Windows 的 NTFS 权限检查。

很多关键文件属于：

text 复制代码

TrustedInstaller
SYSTEM
Administrators

普通用户并没有删除权限。

所以很多危险操作会失败。

但是------

这只能保护一部分文件。

用户有权限的内容：

text 复制代码

C:\Users
C:\Downloads
C:\Documents

仍然可以被删掉。

因此风险依然存在。

3. WSL 最初的目标用户不是 AI Agent

这一点很关键。

WSL 最早发布于 2016 年。

当时微软假设的用户是：

Linux 开发者
DevOps
运维工程师
程序员

而不是：

text 复制代码

Claude Code
OpenAI Codex
Cursor Agent
Gemini CLI

这种能够自动执行命令的 Agent。

在 2016 年的设计视角里：

bash 复制代码

rm -rf /mnt/c/Windows

属于"用户自己作死"。

因为默认认为：

执行命令的人理解自己在做什么。

而今天情况变了。

很多人已经开始：

text 复制代码

Agent
  ↓
Shell
  ↓
WSL
  ↓
/mnt/c

这时候风险确实明显上升。

从今天（2026）的角度看

如果让我重新设计 WSL，我可能会这样做：

text 复制代码

默认：
    /mnt/c/Users

高级模式：
    /mnt/c

或者：

text 复制代码

Agent Safe Mode
    不挂载系统目录

Developer Mode
    挂载整个磁盘

这样更符合现在 AI Agent 大量执行 Shell 命令的现实。

但 WSL 的设计比 Claude Code、Cursor、Codex 这些产品早了接近十年，当时几乎没人考虑过"自动化 Agent 误删主机系统"这个问题。

所以你的直觉其实没错：

对于 AI Agent 时代来说，默认暴露整个 /mnt/c 确实是一种偏危险的设计。

很多使用 Claude Code 的开发者现在会刻意：

bash 复制代码

~/projects

工作在 WSL 自己的 ext4 文件系统里，甚至直接禁用自动挂载，原因正是为了降低 Agent 或脚本误操作影响到 Windows 主机的风险。

规避手段或解决方法

不要把项目放在 Windows 文件系统（/mnt/c/...）里，而是放在 WSL 自己的 Linux 文件系统里。

很多人刚开始这样用：

bash 复制代码

/mnt/c/Users/yourname/projects/my-app

实际上对应：

text 复制代码

C:\Users\yourname\projects\my-app

Claude Code、Cursor、Agent、脚本操作的是真实的 Windows 文件。

如果 Agent 失控：

bash 复制代码

rm -rf ../*

删掉的可能是：

text 复制代码

C:\Users\yourname\Documents
C:\Users\yourname\Downloads
C:\Users\yourname\Pictures

甚至更糟。

WSL 文件到底存在哪里？

实际上存储在一个虚拟磁盘文件里：

text 复制代码

ext4.vhdx

位置通常类似：

text 复制代码

C:\Users\<user>\AppData\Local\Packages\
CanonicalGroupLimited...
\LocalState\
ext4.vhdx

你在 Linux 看到的是：

bash 复制代码

/home
/etc
/var
/usr

这些都在这个虚拟磁盘里面。

因此：

bash 复制代码

rm -rf ~/projects/test

只会影响 Linux 环境。

不会直接删除：

text 复制代码

C:\Users
C:\Windows
C:\Program Files

VS Code 能正常工作吗？

完全没问题。

推荐这样启动：

bash 复制代码

cd ~/projects/my-app
code .

VS Code 会自动连接 WSL。

左下角会显示：

text 复制代码

WSL: Ubuntu

此时：

Python 在 WSL 运行
Node.js 在 WSL 运行
Git 在 WSL 运行
Claude Code 在 WSL 运行

全部都在 Linux 环境。

这是目前最推荐的开发方式。

Docker Desktop 也是这样工作的

你前面提到：

text 复制代码

Windows
 └── WSL2 Ubuntu
       ├── Claude Code
       ├── Python
       ├── Node.js
       ├── Git
       └── Docker CLI

其实 Docker Desktop 官方推荐也是：

bash 复制代码

~/projects

而不是：

bash 复制代码

/mnt/c/projects

因为：

文件 IO 更快
inode 支持完整
文件权限正常
watch 机制稳定
Git 性能更好

如何彻底禁止访问 `/mnt/c`

如果你非常担心 Agent 误删 Windows 文件，可以关闭自动挂载。

编辑：

bash 复制代码

sudo nano /etc/wsl.conf

写入：

ini 复制代码

[automount]
enabled = false

保存后退出。

然后在 Windows PowerShell：

powershell 复制代码

wsl --shutdown

重新打开 Ubuntu。

此时：

bash 复制代码

ls /mnt

结果大概是：

text 复制代码

空目录

或者：

text 复制代码

c 不存在

这时候：

bash 复制代码

cd /mnt/c

会直接报错。

Claude Code 也无法访问 Windows 系统盘。

我个人更推荐哪种？

对于使用 Claude Code 的开发者，我更推荐：

text 复制代码

✓ 项目放在 ~/projects

✓ Git 仓库放在 ~/projects

✓ Docker Engine 运行在 Docker Desktop，Docker CLI 运行在 WSL

✓ VS Code Remote WSL

✗ 不关闭 /mnt/c（可能有副作用）

原因是：

日常仍可访问下载目录
复制文件方便
不影响 Docker Desktop 集成
不影响 VS Code

只要养成一个习惯：

bash 复制代码

cd ~/projects

而不是：

bash 复制代码

cd /mnt/c/Users/xxx/project

那么 Claude Code、Agent、脚本绝大部分操作都会被限制在 Linux 的 ext4 虚拟磁盘里，误伤 Windows 的概率会大幅降低。

真正会关闭 /mnt/c 自动挂载的人其实不多，通常是安全要求较高的开发环境或者经常运行高权限自动化 Agent 的用户。

WSL2危险设计：默认挂载/mnt/c，易误删系统文件导致系统崩溃（附解决方法）（关闭自动挂载（不推荐关闭））/etc/wsl.conf

文章目录

分析

1. WSL 被设计成 Windows 的一部分，而不是沙箱

2. Windows 权限模型本来就在保护系统文件

3. WSL 最初的目标用户不是 AI Agent

从今天（2026）的角度看

规避手段或解决方法

推荐方式

WSL 文件到底存在哪里？

VS Code 能正常工作吗？

Docker Desktop 也是这样工作的

如何彻底禁止访问 /mnt/c

我个人更推荐哪种？

如何彻底禁止访问 `/mnt/c`