VSCode 插件全部消失Everything 搜不到——TaoToken 这次被我当成排查搭档Key 在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 建Base URL 填 https://taotoken.net/api 交给 Codex 比对 Blender 卸载残留留下的删除记录。先把触发链条说清楚因为插件没了这句结论本身没什么用。我的 VSCode 插件目录一直不在默认位置快捷方式里加了--extensions-dir参数指向一个自定义目录平时双击快捷方式启动一切正常PlatformIO 也照常用。转折点有两个一是前几天把 Blender 2.93 的文本编辑器外部程序设成了 VSCode并且在参数里附加了那个插件目录路径二是后脚换了 Blender 4.0卸载旧版时用 Geek 扫残留屏幕上列出来的一堆目录看着都在 C 盘、都像垃圾我就全勾删了。再打开 VSCode扩展面板空白。这次的排查思路和平时不太一样。以前遇到这种事我是一条条翻日志、一个个目录对照耗掉半个晚上还不一定得出结论。这次我把 Codex 接上统一 API 通道当作目录考古的助手把 Blender 卸载时间、快捷方式参数、插件目录路径、VSCode 日志位置四组线索一起丢给它让它列出取证命令和分析顺序我自己在本地执行再把输出贴回对话。它不碰我的机器只负责对照和推理这样既快也不会误伤别的目录。1.--extensions-dir之后的第一次翻车插件目录整体蒸发1.1 症状回放快捷方式还能用扩展列表却空了表面现象很具有迷惑性。VSCode 本体能正常启动、能打开项目、能连远程说明程序本体和用户配置都还在唯独扩展面板空了CtrlShiftX里只剩几个内置项。这种程序好、插件全没的组合基本可以排除 VSCode 自身损坏问题指向扩展的存放位置。我在快捷方式里写的是--extensions-dir也就是说扩展被装在一个自定义路径下而不是默认的%USERPROFILE%\.vscode\extensions。这时有两种可能一是启动参数丢了VSCode 回到默认目录去找扩展自然一个也找不到二是自定义目录本身被删了。这两种情况的处理方式完全不同前者改回参数就行后者要考虑数据恢复。判断方法很简单右键快捷方式看属性里的目标一栏参数还在不在然后把参数里的路径复制出来直接在资源管理器地址栏粘进去回车。目录打不开、路径提示不存在就属于第二种。1.2 Everything 搜不到说明大概不是改名而是删除Everything 只索引磁盘上真实存在的文件记录它快是快在直接读文件系统的索引结构而不是遍历所有目录。所以它能搜到的东西通常都还在盘上它搜不到的往往意味着文件记录已经不在那里了。这里有个容易被忽略的细节被丢进回收站的文件一般仍然能被 Everything 找到因为它们还实实在在躺在$Recycle.Bin里。彻底搜不到更像是被清空回收站、被清理工具直接删除、或者删除时根本没走回收站。Geek 这类卸载工具的残留清理取决于你当时点的按钮和设置直删的情况并不少见。这条推断很关键它把恢复可能性从肯定没了调整成先看回收站再看卷影副本最后才考虑重建。别急着一个个重装先把证据收集齐。1.3 把怀疑对象钉在Geek 清残留那一刻回到时间线卸载 Blender 2.93、残留扫描、全选删除、之后 VSCode 插件消失。三个线索指向同一次操作。第一Blender 的文本编辑器设置会把外部编辑器路径和参数写进它自己的用户配置里卸载时这些配置目录也属于残留范畴。第二我在参数里附加的插件目录路径很可能就在被扫描出来的列表里。第三扫描结果里我看着都是 C 盘的就删了并没有逐条核对每一条到底属于谁。这三件事叠加删除动作误伤 VSCode 插件目录的概率非常高。2. 让 Codex 帮你对照卸载记录先去 TaoToken 拿一把 Key2.1 打开官网注册把 API Key 建出来不管是想复现我的排查流程还是以后遇到类似的目录凭空消失你都需要一个能长期用的模型入口。打开 TaoToken 注册账号进控制台创建 API Key把它复制到一个安全的地方——Key 一般只在创建时完整展示一次页面关掉就找不回来了。顺便在模型广场看一眼当前可用的模型 ID 列表等会儿填配置要用。模型 ID 一律以模型广场当时的列表为准不要凭记忆写也不要自己加日期后缀填错的表现就是请求返回模型不存在的报错。2.2~/.codex/config.toml里把 Codex 指到统一通道Codex 读的是 TOML 配置文件位置在%USERPROFILE%\.codex\config.tomlWindows或~/.codex/config.tomlmacOS / Linux。核心是三件事声明一个自定义 provider、把base_url指向https://taotoken.net/api、把 Key 从环境变量里读进来。# ~/.codex/config.toml model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chatKey 不要写死在配置文件里用环境变量更省事# Windows PowerShell设置后重开终端 setx TAOTOKEN_API_KEY YOUR_API_KEY# macOS / Linux export TAOTOKEN_API_KEYYOUR_API_KEY注意两个坑base_url末尾不要加/v1也不要补/chat/completions之类的路径通道会自己处理env_key里写的名字必须和实际设置的环境变量名一模一样大小写都要对。提示wire_api按你本地 Codex 版本支持的取值填先用chat试跑不通再换另一个取值。这一步和 Key 无关换通道不会解决它。2.3 先发一条测试消息确认通道真的通别等到真开始查问题时才发现配置没生效。在 Codex 里发一句普通提问比如列出 Windows 下 VSCode 扩展目录的默认位置和自定义位置的写法能正常返回就说明通道通了。想更直观一点可以打开 TaoToken 模型对话 用同一把 Key 发一条消息页面能回、模型名对得上就说明 Key 和模型 ID 都是有效的。这两个入口用的是同一套凭证先在网页里试通再去命令行能省掉一半的排错时间。3. 让 Codex 生成取证命令你自己在本地执行3.1 一条提示词模板四组线索一起给它很多人用 Codex 查问题上来就问我的 VSCode 插件为什么没了这种问法它只能给通用建议。把具体线索给足它才能做对照分析。我用的提示词结构是这样的背景Windows 11VSCode 通过带--extensions-dir参数的快捷方式启动插件目录为D:\vscode-ext\extensions事件某日用 Geek Uninstaller 卸载 Blender 2.93 并执行了残留扫描全选删除怀疑删除过程中误删了上述插件目录需求给出本地取证命令清单覆盖快捷方式参数、目录存在性、回收站、VSCode 日志与用户数据目录并说明每条命令的输出能证明什么。关键是最后一句——要求它解释输出能证明什么否则你拿到的只是一堆命令不知道结果怎么解读。另外记得说明只生成命令和解读思路由我在本地执行后再把结果贴回对话。Codex 本身不需要、也不应该去连你的磁盘或业务系统。3.2 几条真正有用的本地取证命令下面这些命令是我实际用到的全部在本地 PowerShell 里执行执行完把输出贴回对话让 Codex 对照。# 1. 看快捷方式的目标与启动参数 $sh New-Object -ComObject WScript.Shell $lnk $sh.CreateShortcut($env:USERPROFILE\Desktop\Visual Studio Code.lnk) $lnk.TargetPath $lnk.Arguments # 2. 自定义插件目录现在还在不在 Test-Path D:\vscode-ext\extensions # 3. 默认插件目录与用户数据目录 Get-ChildItem $env:USERPROFILE\.vscode -Force Get-ChildItem $env:APPDATA\Code\User -Force # 4. 回收站里有没有相关目录 Get-ChildItem C:\$Recycle.Bin -Recurse -Force -ErrorAction SilentlyContinue | Where-Object { $_.Name -match extension|vscode } | Select-Object -First 30 FullName第 1 条确认参数有没有被改动第 2 条区分路径丢了还是目录没了第 4 条是恢复的分水岭。如果回收站里能翻到直接还原到原路径重启 VSCode 就能收工。3.3extensions.json和 exthost 日志能证明什么插件目录下有一个extensions.json记录着当前目录里装了哪些扩展。如果整个目录被删这个文件也一起没了——它反而是目录整体消失的旁证而不是恢复依据。真正能帮忙的是另外两处。一是 VSCode 的日志目录%APPDATA%\Code\logs\日期\window*\exthost\exthost.log扩展宿主启动时会记录扫描到的扩展目录二是用户数据目录%APPDATA%\Code\User\globalStorage\很多扩展会在这里建立以自己 ID 命名的状态子目录即使扩展本体被删这些目录名仍然留着能反推出你之前装过哪些扩展。把这两处目录名列表贴给 Codex让它帮你对照、去重、补全成一份扩展 ID 清单比重装时凭印象回想靠谱得多。Blender 侧的配置在%APPDATA%\Blender Foundation\Blender\2.93\config\里如果这个目录还在也能确认当时外部编辑器确实指向了 VSCode。4. 恢复策略分层先救数据再重建环境4.1 三种局面三种做法回收站还在最省事。找到被删的插件目录右键还原确认它回到快捷方式参数里写的原路径重启 VSCode 即可。还原后立刻做一次压缩备份别再赌第二次。回收站已清空先把那个盘的所有写入停下来别往上面下载东西、别装软件。然后依次尝试卷影副本、系统还原点、文件历史记录或你自己的云备份。这类恢复有时间窗口越早越好。彻底找不回接受重建但重建不等于从零。用上一步从globalStorage反推出的清单批量安装路径改回稳定位置。# 从备份清单批量装回清单来自 globalStorage 反推 Get-Content .\extensions-backup.txt | ForEach-Object { code --install-extension $_ --extensions-dir D:\vscode-ext\extensions }4.2 重建之后别再把插件目录塞进会被清理的地方这次的教训不在 VSCode而在目录选址。任何会被卸载工具残留扫描波及的位置都不适合放插件目录软件安装目录旁边、C 盘根目录、临时目录、以及你打算长期卸载重装的软件附近。放在独立的数据分区、路径里带明确的专属名字会安全很多。还有一条经验在 Blender 这类软件里把外部编辑器指向 VSCode 时尽量不要在参数里附加--extensions-dir或--user-data-dir。外部编辑器只需要能打开文件就够了把插件目录、用户数据目录这些关键路径暴露给第三方程序的配置项只会增加被误删的面。真需要多个配置用独立的启动脚本而不是让别的软件替你传参。最后别忘了保险现在就去跑一次code --list-extensions extensions-backup.txt把清单和插件目录一起纳入定期备份。这次的痛主要是没有任何清单留底。5. 通道侧的排错401、404 和模型 ID 写错5.1 401 / 403Key 没被正确读到如果 Codex 一上来就报鉴权失败先确认三件事config.toml里env_key写的名字和你setx设置的变量名是否一致设置环境变量后有没有重开终端老进程读不到新变量复制的 Key 前后有没有带空格或换行。把 Key 临时打印出来比对长度是排查这类问题最快的办法。注意Key 只在本地环境变量或配置文件里出现不要贴进聊天记录、截图或提交进 Git 仓库。5.2 404base_url多写了路径这是最典型的一类错。通道要填的是https://taotoken.net/api不要加/v1也不要加/chat/completions。多写一层路径请求就会打到不存在的地址上返回 404 而不是 401很容易被误判成Key 有问题。另外 TOML 语法本身也会造成看起来配好了其实没生效字符串必须带引号[model_providers.taotoken]这一节要写在model_provider taotoken之后并且名称完全对应。5.3 模型 ID以模型广场当时的列表为准模型 ID 写错的表现通常是请求被接受但模型不存在报错信息和大模型供应商的风格一致容易让人以为是通道的问题。解决办法很朴素打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_list 看一眼模型广场里的准确 ID复制粘贴进配置不要手打。6. 排查收尾把这次调用对上账也把清单留一份配置改完、通道跑通、取证结果也贴回来了最后一步是确认这次调用真的被记录下来了。打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentconsole_after_fix 进控制台看一眼调用记录里有没有刚才那几条请求顺便核对 Key 的使用情况。这一步能排除请求其实走了别的通道这类隐蔽问题。如果你打算把这种把线索丢给模型做对照分析的用法长期化可以去 Coding Plan 看看套餐是否匹配日常量Key 的管理入口在 控制台 API Keys忘了 Key 或者想换一把都在这里处理。同一把 Key 想同时用在 Claude Code 上环境变量的对照写法在 Claude Code 接入文档 里。回头看这次事故真正致命的不是那一次删除而是插件目录的路径从来没被记录过也没有备份。Blender 只是一个触发器换任何一个卸载工具、任何一次看着都是垃圾的全选删除结果都一样。现在我把插件目录挪到了独立分区启动脚本里参数固定不改扩展清单每周导出一次——这比事后指望恢复工具靠谱得多而 Codex 在这套流程里的位置也很清楚它负责把散落的目录名、日志片段和卸载记录对照成结论动手的永远是我自己。