Codex VS Code 插件加载新代理窗口时为何出现 workspace_dependencies 错误？

Codex VS Code 插件加载新的代理编辑器窗口时出现 workspace_dependencies 错误，公开日志显示根本冲突发生在实验特性协商阶段：扩展请求启用 workspace_dependencies，但实际连接的 Codex app-server 支持列表中没有这个名称，于是 experimentalFeature/enablement/set 返回无效请求，新窗口启动流程随之中断。

这是新编辑器窗口的启动路径故障

对应案例中，Codex 侧边栏仍能创建新聊天，历史中的部分聊天也能打开；失败的是新建全屏代理或编辑器窗口。这个差异说明登录、基础 app-server 连接和所有 Codex 功能并未整体失效。

失败发生在新窗口初始化阶段。该路径会同步一组实验功能开关，其中一个客户端请求的功能未被服务端识别。因为错误出现在 conversationId=none 时，它发生在新会话建立之前。

日志如何证明特性集合不匹配

扩展首先记录启用功能列表，其中包含：

workspace_dependencies
apps
plugins
tool_search
tool_call_mcp_elicitation

随后 app-server 返回：

unsupported feature enablement `workspace_dependencies`
currently supported features are apps, memories, plugins,
tool_search, tool_suggest, tool_call_mcp_elicitation

客户端发送值与服务端声明支持值可以直接对照。这里不是功能执行失败，而是服务端在接收开关时就拒绝了未知名称。

为什么它像版本错配

IDE 扩展和 Codex app-server 必须对实验功能名称达成一致。扩展可能携带内置二进制，也可能在 WSL 或其他环境中启动不同的 Codex 可执行文件。如果客户端代码比实际 app-server 新，或两侧来自不兼容构建，就可能出现一侧发送、另一侧不认识的特性。

公开问题尚未包含维护者确认的最终根因或修复提交，因此应称为“功能协商不匹配”，而不是断言某个具体打包步骤一定出错。

先确认实际运行的组件版本

code --version
code --list-extensions --show-versions | Select-String openai
codex --version
wsl codex --version

独立安装的 codex 版本不一定等于扩展实际启动的版本。应在 Codex 输出日志中查找 Spawning codex 或 spawn-codex-process，记录完整可执行文件路径和启动环境。

如果日志路径位于 VS Code 扩展目录，说明使用的是扩展随附二进制；如果指向 WSL 中的其他位置，则需要核对 WSL 侧安装与 PATH。

用最小工作区排除项目内容

该问题已经在真实仓库、全新空目录和执行 git init 后的目录中复现，因此项目文件、AGENTS.md 和 Git 状态不是必要触发条件。仍可使用以下最小测试确认本机行为：

New-Item -ItemType Directory -Force E:codex-window-test
Set-Location E:codex-window-test
git init
'test' | Out-File README.md -Encoding utf8
git add README.md
git commit -m 'Initial test'
code .

在同一窗口分别从侧边栏新建聊天和创建全屏代理窗口。如果前者成功而后者报相同特性错误，就能把故障边界缩小到新窗口 bootstrap。

比较 WSL 开关不能只看结果

公开案例在 WSL 模式开启和关闭时都失败。开启时，日志明确显示扩展在 WSL 内启动 app-server；关闭时仍出现相同的特性协商错误。因此它不是单纯的 WSL 路径转换问题。

测试 WSL 时应记录：

• 扩展最终选择了 Windows 还是 Linux 二进制。
• app-server 报告的版本。
• 发送的 enabledFeatures 完整列表。
• 服务端返回的 supported features 列表。

只切换设置而不确认实际启动路径，不能证明测试覆盖了两个运行时。

当前可用的临时工作流

既然侧边栏仍可创建聊天，可以先在侧边栏启动会话，再从历史中尝试打开它。这是公开报告中偶尔可用的绕行路径，但并不保证每次都能把会话加载到编辑器窗口。

重要工作开始前先确认聊天确实创建成功并保留会话。不要连续点击新窗口按钮，因为每次都会重复同一个失败的功能同步请求。

不要把无关日志当成根因

报告中还出现 Git watcher 的 ENOENT，但创建 Git 仓库后该日志不再具有解释力，原始 workspace_dependencies 错误仍然存在。这说明 Git 元数据异常是测试环境中的旁支信息。

还出现插件同步认证和 403 警告，但侧边栏基本聊天仍可用，且最早阻断新窗口的是实验特性设置请求。排查时应按时间顺序锁定启动链路中第一个确定失败，而不是追逐日志中所有红色条目。

为什么大范围重置不值得优先尝试

案例已经尝试重启、重新登录、更新 WSL、切换 WSL 模式、卸载扩展、清理 Windows 与 WSL Codex 状态、清理 VS Code workspaceStorage 后重装，问题仍然存在。清理还导致部分本地会话历史无法访问。

功能名不匹配通常不能通过删除用户数据修复。没有完整备份时，不要删除 ~/.codex、Windows 用户目录下的 Codex 状态或整个 VS Code workspaceStorage。

检查是否混入自定义可执行文件

如果曾配置扩展使用自定义 Codex CLI，应暂时记录并移除覆盖，让扩展使用其预期内置版本做对照。具体设置名可能随版本变化，应从设置界面搜索 Codex executable 或 CLI path，而不是凭旧文档直接修改 JSON。

完成对照后恢复原配置。若只有自定义 CLI 失败，版本不匹配范围就进一步缩小；若内置二进制也失败，则需要连同扩展包版本报告。

扩展侧应如何降级

更稳健的特性协商不应让一个未知实验开关阻断整个窗口。实现可以采用以下策略：

1. 先从 app-server 获取支持功能集合。
2. 只提交客户端与服务端交集中的功能。
3. 未知的可选功能只记录警告并继续启动。
4. 只有必需功能缺失时才阻断窗口。
5. 向用户显示组件版本与不兼容功能，而不是停在 splash screen。

如果功能确实必需，则扩展包必须确保随附 app-server 与客户端代码来自兼容版本，并在启动时给出明确升级提示。

回归测试应覆盖哪些组合

测试路径	期望结果
侧边栏新建聊天	基础聊天正常
全屏编辑器新建聊天	未知可选功能不会阻断
旧服务端不支持新功能	自动过滤或明确提示升级
WSL 模式开启	使用兼容 Linux app-server
WSL 模式关闭	使用兼容 Windows app-server
空目录和普通 Git 项目	结果不依赖项目内容

提交问题时保留哪些证据

1. VS Code、Codex 扩展和实际 app-server 的版本与路径。
2. 完整的 enabledFeatures 和 supported features 列表。
3. 失败请求的方法名、错误码和时间。
4. 侧边栏与全屏编辑器窗口的对照结果。
5. WSL 开关两种状态下实际启动的二进制。
6. 最小空目录能否复现。

日志公开前删除账号、令牌、用户名和项目路径。不要为了生成“干净日志”再次删除会话目录。

当前结论

这个错误不是 workspace_dependencies 功能执行失败，而是扩展在新代理窗口启动时要求启用一个 app-server 不认识的实验功能。侧边栏可用、空目录复现、WSL 开关无效和服务端返回的明确支持列表，共同把问题限定在客户端与 app-server 的特性协商。

当前风险最低的临时方案是从侧边栏创建聊天，并等待扩展与内置 app-server 的兼容更新。不要通过删除本地状态反复重置，因为现有证据表明它不能解决协议不匹配，却可能让旧会话历史丢失。