VS Code 远程 WSL 中 Claude Code 导致 Java 文件修改被自动撤回的一次排查

最近在 VS Code Remote SSH 连接 Windows Server 中的 WSL 环境时，遇到了一个非常反直觉的问题：两个被 Claude Code 引用过的 Java 文件，在 VS Code 中无法正常编辑。任何手动修改都会在一两秒后被自动撤回，但文件权限没有问题，外部编辑器也能正常修改。更奇怪的是，执行了一次 Developer: Reload With Extensions Disabled，再执行 Help: Start Extension Bisect 后，问题消失了。退出二分查找、重新启用所有插件、重新加载窗口后，问题仍然没有复现。

环境如下：

VS Code 版本：1.113.0

Claude Code VS Code 插件版本：v2.1.172

Claude Code 版本：2.1.170

远程环境：VS Code SSH 到 Windows Server 中的 WSL

这个现象表面看起来像文件权限、WSL 文件系统、VS Code Remote、Java 扩展、Claude Code 插件共同造成的复杂问题。但从最终恢复方式看，它更像是一次"扩展宿主状态污染"，而不是一个稳定可复现的文件系统错误。

现象回顾

问题最初出现在 Claude Code auto mode 下。Claude 尝试操作项目时，出现了类似下面的报错：

claude-opus-4-8[1m] is temporarily unavailable, so auto mode cannot determine the safety of Bash right now.
Wait briefly and then try this action again.
If it keeps failing, continue with other tasks that don't require this action and come back to it later.
Note: reading files, searching code, and other read-only operations do not require the classifier and can still be used.

之后将模式从 auto mode 改成 Ask before edits，再改成 Edit automatically。随后发现 Claude 尝试修改 Java 文件时出现 Edit failed，并且这两个 Java 文件在 VS Code 中也无法手动修改。每次修改过一两秒后都会被撤回。

尝试过的操作包括：

强制终止远程运行的 VS Code；

重启本地 VS Code；

关闭远程 Claude Code 插件；

重新打开项目。

这些操作都没有立即解决问题。

但有几个现象非常关键：

把文件改名后再编辑，可以保存；

用 VS Code 外部的编辑工具修改，改动可以保存；

外部工具改完后，VS Code 中也可以继续编辑；

一旦文件内容被恢复成 Claude Code 输入前一模一样的内容，问题又会出现。

这说明问题不是简单的"文件不可写"。如果是 Linux 权限、ACL、只读属性、磁盘挂载问题，那么改名、外部编辑、内容变化不应该产生这种差异。真正的触发条件更像是"路径 + 内容快照 + 编辑器状态"共同命中了某个异常缓存。

为什么不像文件权限问题

如果文件权限异常，通常会表现为所有编辑器都无法写入，或者保存时报 permission denied。但这次外部编辑器可以写入，改名后可以写入，说明 WSL 文件系统层面并没有阻止写操作。

如果是 Git 自动回滚，通常可以通过 git status、git diff、hook 或后台脚本发现线索，而且不会只在 VS Code 内部编辑时触发。

如果是 Java formatter 或 save action，问题一般发生在保存时，而不是编辑后一两秒直接回退；并且重新启用所有插件后仍然正常，也不符合一个稳定 formatter 配置错误的特征。

因此，这次更像 VS Code 内部某个编辑模型、文件 watcher、扩展宿主进程或 Claude Code 相关状态卡在了异常位置。

最可能的根因

我的判断是：Claude Code auto mode 的安全分类器不可用，导致 Edit/Write 流程失败；失败过程中，Claude Code 插件或 VS Code Remote 扩展宿主留下了某个未完成的编辑状态、文件快照、working copy 状态或 watcher 状态。之后 VS Code 在检测到这两个 Java 文件的内容与某个旧快照完全一致时，会错误地把文件恢复到旧状态，表现为"手动修改被撤回"。

这个解释能同时覆盖几个怪现象。

文件改名后可以编辑，是因为路径或文件标识变了，原来的异常状态没有命中。

外部编辑器可以修改，是因为它绕过了 VS Code 的 TextModel、扩展宿主和保存管线。

外部编辑后 VS Code 可以继续编辑，是因为内容 hash 或文件时间戳发生了变化，旧快照失效。

文件恢复到 Claude Code 介入前的完全相同内容后问题复现，是因为旧状态再次命中。

执行 Reload With Extensions Disabled 后恢复，是因为 VS Code 重新加载窗口时，扩展宿主、文件 watcher、编辑器模型和一部分工作区状态被重建。

执行 Extension Bisect 后彻底恢复，是因为二分查找会多次禁用扩展并重载窗口，这比普通重启更容易清掉挂住的扩展状态。

重新启用全部插件后仍然正常，说明问题不是某个插件每次启动都会稳定触发的 bug，而是一次运行时状态污染。

为什么 Extension Bisect 能"顺手修好"问题

Extension Bisect 本来是用于定位问题扩展的。它的做法不是简单列出插件，而是禁用一部分扩展，重新加载窗口，让用户判断问题是否还存在，再继续缩小范围。

这个过程有几个副作用：

重新创建 VS Code 扩展宿主；

重新注册文件监听器；

重新加载远程工作区；

重新初始化语言服务和 AI 插件；

刷新部分 working copy 状态；

打断某些挂起的异步编辑流程。

所以它不仅能定位坏插件，也可能把一次性的脏状态直接清掉。

这也解释了为什么你点击二分查找后没有真的找到某个问题扩展，但问题消失了。因为二分流程本身已经完成了"软重置"。

Claude Code auto mode 是诱因，不一定是唯一根因

这次问题的起点是 Claude Code auto mode 报错，但不能简单说"Claude Code 插件一定有 bug"。更精确的说法是：Claude Code auto mode 的安全分类器不可用，是这次异常链路的诱因。

auto mode 的特点是尽量减少用户批准，让 Claude 自动执行更多操作。但它不是无条件放行，而是在执行工具调用前交给安全分类器判断。如果分类器模型临时不可用，Bash、Edit、Write 等工具调用就可能被阻塞。

你的原始报错正是这一类问题。后续的 Edit failed 和 VS Code 中文件被回滚，则更像是失败编辑与 VS Code 远程扩展状态叠加后的副作用。

换句话说，可以把它理解成两层问题：

第一层是 Claude Code auto mode 的 classifier transient outage；

第二层是 VS Code Remote / Claude Code 插件 / Java 文件 watcher 在失败后留下了脏状态。

第一层有公开案例，第二层更依赖你的具体环境，不一定能稳定复现。

为什么不是重启 VS Code 就能解决

普通重启 VS Code 有时并不会完全清理远程端状态。尤其是在 Remote SSH + WSL 场景中，本地 VS Code 窗口、远程 VS Code Server、扩展宿主、语言服务器、文件 watcher 可能不是同一个生命周期。

你重启的是本地窗口，但远程端某些进程或缓存可能仍然存在。Reload With Extensions Disabled 和 Extension Bisect 则会更明确地改变扩展加载状态，从而强制重建更多运行时组件。

这就是为什么"重启 VS Code 无效"，但"禁用扩展重载 + 二分查找"有效。

建议的处理流程

如果以后再遇到类似问题，建议按下面顺序排查。

先保护现场。执行：

git status --short
git diff

如果当前改动重要，先提交或复制备份，避免在排查过程中丢失。

然后在 VS Code 中执行：

Developer: Reload With Extensions Disabled

如果问题消失，说明大概率不是文件系统问题，而是扩展宿主或扩展状态问题。

接着执行：

Help: Start Extension Bisect

如果二分过程中问题复现，就按提示继续定位具体扩展。如果二分过程中问题直接消失，即使没有找到问题扩展，也说明它可能是一次性运行时状态污染。

恢复后，重新启用所有插件，再执行：

Developer: Reload Window

如果仍然正常，可以认为当前状态已经被清掉。

如果问题仍然存在，可以进一步清理 VS Code Remote 的工作区缓存，或者清理 Claude Code 的项目状态。但这类操作会影响历史会话、工作区状态或未保存恢复记录，最好先备份。

后续规避建议

短期内，不建议在敏感代码仓库里继续使用 Claude Code 的 auto mode，尤其是在 Opus 4.8 classifier 出现临时不可用报错之后。

更稳妥的模式是：

普通小改动使用 Ask before edits；

可信的重复性编辑使用 Edit automatically；

大范围重构只在干净 Git 工作区和临时分支中进行；

auto mode 只用于低风险任务，不用于未提交的重要代码。

在让 AI 修改代码前，最好先执行：

git status --short
git checkout -b ai-edit-$(date +%F-%H%M%S)

这样即使再次遇到异常回滚、错误覆盖、编辑失败，也可以通过 Git 精确比较和恢复。

结论

这次问题最有价值的线索不是"Claude Code 报错"，而是"重新启用所有插件后仍然正常"。这说明问题并不是某个插件稳定地破坏文件，而是某次失败编辑后，VS Code 远程扩展宿主或工作区状态进入了异常状态。

Reload With Extensions Disabled 和 Extension Bisect 之所以能解决问题，是因为它们强制重建了扩展运行环境，清掉了残留的文件监听、编辑模型或工作区缓存。

因此，这类问题的处理思路不应该一开始就怀疑 Linux 权限，而应该优先考虑：

VS Code 扩展宿主状态；

Remote SSH / WSL 的远程 server 状态；

Claude Code auto mode 的失败编辑状态；

Java language server、formatter、save action 的文件 watcher；

VS Code working copy 和 workspaceStorage 缓存。

这类问题看起来很玄学，但从排查方法上看，有一个简单判断标准：如果外部编辑器能写入，而 VS Code 内部编辑会被撤回，优先查 VS Code 扩展与工作区状态，