1. 为什么 /mnt/c 是 WSL2 里最容易被忽略的雷
WSL2 默认会把整个 Windows 系统盘挂到/mnt/c，你打开 Ubuntu 终端敲一句ls /mnt/c，看到的不只是自己的用户目录，而是Windows、Program Files、ProgramData这些系统级目录全都在里面。这个设计本身是为了让 Linux 侧能像 Windows 程序一样访问整个文件系统，对运维和跨平台开发确实方便，但对现在大量跑 AI 工具、Agent、自动化脚本的人来说，风险被放大了。
问题不在于你手动去删，而在于脚本和 Agent 执行命令时不会像人一样犹豫。一个rm -rf写错路径、一个变量拼接出错、一个 Agent 误判工作目录，落在/mnt/c/Users/xxx下面删掉的就是真实的 Windows 文件，不是 WSL 虚拟磁盘里的副本。更麻烦的是，很多 AI 编码工具默认把项目放在/mnt/c/Users/你的名字/projects这种路径下，Agent 操作的就是货真价实的 C 盘文件。
这篇要解决两件事：第一，把 WSL2 的自动挂载关掉或收紧，让/mnt/c不再默认暴露整个系统盘；第二，在安全的前提下接入 TaoToken 的统一 Key/API 通道，让 Claude Code、Cursor、各类 CLI 工具用同一个 Key 跑起来，而不是每个工具配一遍、还把密钥散落在各处。适合日常在 WSL2 里跑 AI 工具、写脚本、又不想哪天醒来发现 C 盘被清空的开发者。
2. 先理解 WSL2 的挂载逻辑，再决定怎么改
WSL2 的自动挂载由/etc/wsl.conf控制，默认行为是enabled = true，挂载点前缀是/mnt/，所以 C 盘就是/mnt/c，D 盘就是/mnt/d。这个配置在发行版启动时读取，改完必须wsl --shutdown让整个 WSL 实例重启才生效，只关终端窗口没用。
这里有个常见误区：很多人以为在 WSL 里rm会经过 Linux 权限检查，实际上文件操作最终落到 NTFS 上，走的是 Windows 的权限模型。TrustedInstaller、SYSTEM拥有的系统文件你删不掉，但C:\Users\你的名字下面的文档、下载、图片，你的 Windows 账户是有完全控制权的，Agent 一旦在这些目录里执行破坏性命令，是真的会删掉。
所以策略分两档。温和档是保留/mnt/c但把项目全部放到 WSL 自己的 ext4 虚拟磁盘里，也就是/home/<用户名>/projects，日常操作不碰/mnt/c。激进档是直接关掉自动挂载，/mnt变成空目录，cd /mnt/c直接报错，Agent 想访问 Windows 系统盘都没有入口。我实测下来，如果你经常跑高权限自动化 Agent，激进档更省心；如果还要频繁在 Windows 和 Linux 之间拷文件，温和档够用。
3. 可复制的 /etc/wsl.conf 配置骨架
先看当前配置长什么样，很多发行版这个文件根本不存在，需要自己建：
cat /etc/wsl.conf如果提示 No such file or directory，直接新建。用 nano 或 vim 都行：
sudo nano /etc/wsl.conf方案一：彻底关闭自动挂载（激进档）
[automount] enabled = false保存退出后，在 Windows PowerShell 里执行：
wsl --shutdown等几秒重新打开 Ubuntu，验证：
ls /mnt正常结果是什么都不显示，或者提示目录为空。再试：
cd /mnt/c会直接报No such file or directory。这时候 Claude Code、任何 Agent、任何脚本都无法通过/mnt/c触达 Windows 系统盘，误删风险从根上切断。
方案二：保留挂载但收紧选项（温和档）
[automount] enabled = true root = /mnt/ options = "metadata,umask=22,fmask=11" mountFsTab = falsemetadata让 Linux 权限位能映射到 NTFS，umask和fmask控制默认权限，mountFsTab = false表示不自动挂载/etc/fstab里的额外条目。这个方案不阻止访问，只是让权限更规范，真正的安全靠习惯——项目一律放~/projects。
方案三：只挂载指定盘符
如果你只想让 WSL 看到 D 盘、不想暴露 C 盘，可以这样：
[automount] enabled = true root = /mnt/ options = "metadata"然后在/etc/fstab里手动写你要挂的盘，配合mountFsTab = true。不过这个配置对新手偏复杂，容易把挂载搞乱，我一般不建议一上来就动 fstab。
改完任何方案，生效动作都是同一个：
wsl --shutdown注意这条命令会关掉所有 WSL 发行版和正在跑的 Docker Desktop 后端，执行前先保存工作。
4. 把项目迁到 ext4，再接入 TaoToken 统一 Key
关掉或收紧挂载只是第一步，项目路径不改，Agent 还是可能被指向/mnt/c。推荐的工作目录结构：
mkdir -p ~/projects cd ~/projects git clone https://github.com/yourname/your-app.git cd your-app pwdpwd应该输出/home/<用户名>/projects/your-app，而不是/mnt/c/Users/...。WSL 的文件实际存在一个ext4.vhdx虚拟磁盘里，位置大概在C:\Users\<用户>\AppData\Local\Packages\CanonicalGroupLimited...\LocalState\ext4.vhdx，你在 Linux 里rm -rf ~/projects/test只影响这个虚拟磁盘，碰不到C:\Windows。
项目就位后接 TaoToken。它的作用是给你一个统一的 API 通道和 Key，Claude Code、Cursor、各类 CLI 工具都指向同一个入口，不用每个工具单独申请、单独配。官网入口在这里：
https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=API 基础地址是：
https://taotoken.net/api注意 API 地址不带 UTM 参数，配置里填干净的https://taotoken.net/api就行。先去控制台创建 Key：
https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewriteKey 管理页面：
https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite拿到 Key 之后，以环境变量方式注入，不要硬编码进脚本。在~/.bashrc或~/.zshrc里加：
export TAOTOKEN_API_KEY="sk-你的key" export ANTHROPIC_BASE_URL="https://taotoken.net/api" export ANTHROPIC_API_KEY="$TAOTOKEN_API_KEY"source ~/.bashrc之后，Claude Code 这类读ANTHROPIC_BASE_URL的工具就会走 TaoToken 通道。如果你用的是别的 CLI，把对应的 base_url 和 api_key 指向同一组值即可。接入文档在这里：
https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite长期跑编码任务或 Agent 的话，Coding Plan 更划算，入口：
https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite5. 验证请求与成功结果
配置完先做一次最小验证，确认 Key 和通道都通。用 curl 打一个模型对话请求：
curl https://taotoken.net/api/v1/messages \ -H "x-api-key: $TAOTOKEN_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{ "model": "claude-sonnet-4-20250514", "max_tokens": 128, "messages": [ {"role": "user", "content": "只回复两个字：通了"} ] }'返回里能看到content数组和文本内容，说明 Key 有效、通道正常。如果返回 401，检查 Key 有没有复制完整、有没有多余空格；返回 404 检查 base_url 是不是写成了带路径的完整地址。
再验证 WSL 挂载状态是否符合预期：
mount | grep /mnt ls /mnt激进档下ls /mnt为空，mount里没有/mnt/c条目。温和档下能看到/mnt/c，但你的项目在~/projects，Agent 的工作目录不在系统盘上。
最后跑一次 Claude Code 做端到端确认：
cd ~/projects/your-app claude在交互界面里问一句让它读当前目录的文件，能正常响应就说明工具、Key、通道、工作目录全部就位。想直接在网页里试模型效果，可以用模型对话入口：
https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content=model-chat&utm_campaign=rewrite6. 本篇常见错排查
改了 wsl.conf 没生效：九成是没执行wsl --shutdown，或者只关了终端窗口。必须在 Windows PowerShell 里跑wsl --shutdown，等几秒再重开。另外确认改的是发行版内部的/etc/wsl.conf，不是 Windows 侧的某个文件。
ls /mnt还有 c 目录：检查enabled = false有没有拼错，[automount]段名有没有写对，缩进用空格不用 Tab。改完再wsl --shutdown一次。
Docker Desktop 起不来：关掉自动挂载后 Docker Desktop 的 WSL 集成可能受影响，因为它依赖 WSL 后端。如果你重度用 Docker Desktop，建议用温和档，项目放~/projects，别关挂载。
VS Code 连不上 WSL：VS Code Remote WSL 走的是 WSL 内部路径，和/mnt/c挂载无关。确认左下角显示WSL: Ubuntu，项目路径是/home/...而不是/mnt/c/...。如果之前用/mnt/c打开过，重新用code .在~/projects里启动。
Key 配了但工具报鉴权失败：检查环境变量有没有在正确的 shell 配置文件里，echo $ANTHROPIC_BASE_URL看输出对不对。有些工具读的是自己的配置文件而不是环境变量，去接入文档里对照具体工具的配置方式。
Agent 还是往 /mnt/c 写文件：检查项目路径和工具的工作目录设置，有些工具会记住上次打开的目录。在项目根目录重新启动工具，或者显式指定工作目录参数。
7. 安全接入的下一步
把/mnt/c处理掉之后，你的 WSL2 环境对 Windows 系统盘要么完全隔离，要么至少项目不落在上面，Agent 和脚本的破坏半径被限制在 ext4 虚拟磁盘里。接下来就是让 AI 工具在这个安全边界内跑起来，统一 Key 的好处是所有工具共用一个通道，密钥只存一份，换工具不用重新配。
先去 API Keys 页面建一个 Key：
https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite然后照着接入文档把 Claude Code 或你常用的 CLI 配好：
https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite如果你主要跑编码和 Agent 任务，直接看 Coding Plan：
https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewriteClaude Code 的接入说明单独放在这里：
https://taotoken.net/ClaudeCodeAnthropic?utm_source=taotoken_aicg_blog_end&utm_content=ClaudeCodeAnthropic&utm_campaign=rewrite我自己的习惯是：/etc/wsl.conf用温和档保留挂载方便拷文件，但所有项目、所有 Agent 工作目录一律在~/projects下面，Key 走环境变量注入，脚本里永远不出现明文密钥。这样既不影响日常跨系统操作，又把误删风险压到最低。
