本文记录一套 Windows 11 下的实际使用WSL来减轻C盘负担的方式
C 盘到底被谁吃掉了,WSL2 又有什么用?
Codex CLI 本体通常不是 C 盘迅速见底的主因。真正会持续变大的,是开发环境运行过程中不断累计的数据。
C 盘常见的空间大户
- WSL2 虚拟磁盘:默认安装在系统盘时,Linux 系统、软件包和配置都会写入
ext4.vhdx;(咱直接撞到D盘) - 项目依赖:
node_modules、Python 虚拟环境、npm 与 pip 缓存会随着项目增加; - 构建结果:编译产物、测试报告、临时文件和下载缓存会反复增长;
- 容器与工具数据:Docker、包管理器和开发工具产生的镜像或缓存也会占用空间。
把 Ubuntu 在安装时直接指定到 D 盘,可以让 WSL 的大部分 Linux 数据从一开始就离开 C 盘。C 盘仍会保留 Windows、WSL 程序和少量临时文件,但不会承担 Linux 环境持续增长的主体。
我为什么在 WSL2 中使用 Codex CLI
- Linux 终端可以直接使用 PowerShell 之外的 Bash、Git、SSH、包管理器与脚本工具;
- Windows 继续负责编辑器、浏览器和日常软件,WSL 负责 Linux 命令与 Codex CLI;
- 项目保留在 D 盘,不需要为了进入 WSL 再维护一份重复代码;
- WSL 环境需要重装时,项目目录仍按 Windows 的 D 盘路径管理。
文章目录
- C 盘到底被谁吃掉了,WSL2 又有什么用?
- C 盘常见的空间大户
- 我为什么在 WSL2 中使用 Codex CLI
- 一、安装 WSL
- 1. `wsl --install` 出现“已禁止(403)”
- 2. 创建并运行 `Hyper-V.cmd`
- 3. 检查 Windows 功能
- 4. 重置文件系统资源并重新安装
- 5. 设置默认 WSL 版本
- 6. 查看发行版并直接安装到 D 盘
- 7. 首次启动并创建 Linux 用户
- 8. 验证 WSL2 是否安装成功
- 9. 确认 D 盘中的 WSL 文件
- 10. 常用 WSL 管理命令
- 二、安装 Codex CLI
- 1. 更新系统软件包
- 2. 准备运行环境
- 3. 安装并启动 Codex CLI
- 三、我的项目使用方式:D 盘项目目录 + WSL + AI编辑工具
- 1. 一套固定的路径对应关系
- 2. 从项目目录直接进入 WSL
- 总结
一、安装 WSL
以下 Windows 命令均在管理员身份打开的命令提示符或 PowerShell 中执行。安装前先关闭正在进行的下载、虚拟机或容器任务,避免组件启用和重启时被占用。
1.wsl --install出现“已禁止(403)”
管理员身份进入命令提示符后,执行wsl --install或wsl --update。本机第一次执行时出现了如下错误:
这类情况先按两个方向检查:
- 网络、代理或下载链路是否能够正常访问;
- Windows 的虚拟化相关组件是否已经启用。
我是第二种情况,即补齐虚拟化平台相关组件。
2. 创建并运行Hyper-V.cmd
在桌面新建文本文件,将下面内容完整粘贴进去。保存时选择“所有文件”,文件名写成Hyper-V.cmd;随后右键该文件,选择“以管理员身份运行”。脚本完成后按提示输入Y并重启 Windows。
注意:这段脚本会修改 Windows 可选组件。执行前请保存正在进行的工作,重启过程中不要强制关机。
pushd "%\~dp0" dir /b %SystemRoot%\servicing\Packages\*Hyper-V*.mum >hyper-v.txt for /f %%i in ('findstr /i . hyper-v.txt 2^>nul') do dism /online /norestart /add-package:"%SystemRoot%\servicing\Packages\%%i" del hyper-v.txt dism /online /enable-feature /featurename:Microsoft-Hyper-V-All /LimitAccess /ALL3. 检查 Windows 功能
重启完成后,依次进入“控制面板 → 程序 → 启用或关闭 Windows 功能”,确认截图中标出的组件已勾选:Hyper-V、适用于 Linux 的 Windows 子系统和虚拟机平台。
4. 重置文件系统资源并重新安装
完成组件启用后,打开 PowerShell 执行下面两条命令,再次尝试安装。安装成功后,系统会提示重启计算机。
fsutil resource setautoreset true c:\ wsl--install5. 设置默认 WSL 版本
电脑重启后,重新打开管理员 PowerShell,执行下面的命令,将默认 WSL 版本设为 2:
# 设置默认使用 WSL2 版本wsl--set-default-version 26. 查看发行版并直接安装到 D 盘
先查看可安装的 Linux 发行版,再将 Ubuntu 直接安装到D:\wsl。命令会自动创建目标文件夹。
# 查看所有可安装的Linux发行版wsl--list--online# 将Ubuntu直接安装到 D:\wsl 目录(自动创建文件夹)wsl--install-d Ubuntu--location D:\wsl7. 首次启动并创建 Linux 用户
安装完成后第一次启动 Ubuntu,会要求创建 Linux 用户名和密码。用户名建议使用全小写字母;输入密码时终端不会显示字符,这是正常现象。
Enter new UNIX username: New password: Retype new password:8. 验证 WSL2 是否安装成功
下面的命令用于查看发行版状态和版本,并直接进入 Ubuntu:
# 查看已安装WSL列表及版本wsl-l-v# 进入Ubuntu系统wsl当VERSION显示为2时,说明 Ubuntu 已运行在 WSL2 中。
9. 确认 D 盘中的 WSL 文件
安装到 D 盘后,目标目录中会看到ext4.vhdx。它是 WSL 管理的 Linux 虚拟磁盘文件,不要在资源管理器中手动移动、压缩或双击修改。
10. 常用 WSL 管理命令
这些命令都在 Windows 终端中执行,适合日常查看、关闭或卸载发行版:
# 关闭WSLwsl--shutdown# 重启WSLwsl--shutdown && wsl# 卸载Ubuntuwsl--unregister Ubuntu# 查看在线可安装系统wsl--list--online二、安装 Codex CLI
进入Ubuntu 终端后,先更新基础环境。后续的 Node.js、Python、Git 和 Codex CLI 命令都在 Ubuntu 终端中执行。
sudoaptupdate&&sudoaptupgrade-ysudoaptinstall-ygitcurlca-certificates1. 更新系统软件包
在继续安装开发环境前,先执行一次更新:
sudoaptupdate&&sudoaptupgrade-y2. 准备运行环境
下面依次安装 Node.js、Python 与 Git。命令执行完后,可以通过node -v、npm -v和npx -v查看 Node 相关版本是否正常输出。
# Node.js(推荐 nvm)curl-fsSLhttps://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh|bashsource~/.bashrc nvminstall--ltsnvm use--lts# 验证node-vnpm-vnpx-v# Python(推荐 uv)curl-LsSfhttps://astral.sh/uv/install.sh|shsource~/.bashrc uv pythoninstall3.11# gitsudoaptinstallgit-y3. 安装并启动 Codex CLI
完成环境依赖后,安装 Codex CLI,验证版本后直接启动:
npminstall-g@openai/codex# 验证codex--version# 打开codex三、我的项目使用方式:D 盘项目目录 + WSL + AI编辑工具
这一节只记录我自己的日常用法:项目不放进 Ubuntu Home,而是统一放在 D 盘中。这样 WSL 环境需要重新安装时,项目依然按 Windows 的 D 盘目录管理。
1. 一套固定的路径对应关系
以my-app为例,Windows 和 WSL 看到的是同一个项目目录:
| 使用位置 | 项目路径 |
|---|---|
| Windows 资源管理器、CMD、编辑器 | D:\code\my-app |
| WSL 终端 | /mnt/d/code/my-app |
例如D:\code\admin-web进入 WSL 后就是/mnt/d/code/admin-web。项目继续在 D 盘按原有目录组织,Windows 与 WSL 不需要各维护一份副本。
2. 从项目目录直接进入 WSL
先在D:\code\my-app打开 CMD,再执行下面两行:
D:\code\my-app> wsl /mnt/d/code/my-app$ codexCMD 当前所在的 D 盘项目路径会映射到 WSL 中的/mnt/d/...。进入 WSL 后,Codex CLI 面对的就是当前项目,不需要再进入其他目录。
总结
Codex CLI、Claude CLI、Mimo 以及其他依赖 Linux 终端环境的 杂七杂八的环境啥的,都可以统一装在同一套 WSL 中。
这套安排还有一个很实际的优点:WSL 里的 Node、Python、Git 或 AI CLI 配置折腾坏了,不必硬修。直接干掉WSL重新安装即可。别把项目放里面就行。