TRAE Sandbox 文件系统隔离：AI 编程助手的修改为什么没有写入磁盘

我让 AI 助手帮我安装 Copilot hook，一切显示成功；打开本地文件一看，什么都没变。这篇文章记录了我如何排查并最终理解了这个坑——TRAE Work 的沙箱文件系统隔离机制。

起因：我在做什么

最近在开发 JinJinXia —— 一个 AI Coding Agent 对话采集与分析平台。核心架构很简单：客户端通过 Claude Code / Copilot 的 hook 机制采集对话，上传到服务端做智能分析。

开发过程中，我需要频繁让 TRAE Work 的 AI 助手做这些事：

修改服务端 Python 代码（FastAPI）
安装客户端 hook 配置（~/.claude/settings.json、~/.copilot/hooks/jinjinxia.json）
重启 uvicorn 服务器
修改 SQLite 数据库（重置用户密码）
运行测试

项目代码在 C:\Users\kylin\dev\Workspace\JinJinXia\，我把它作为 TRAE 的工作区打开。一切看起来很正常。

问题：AI 说成功了，但什么都没变

第一个异常出现在 hook 安装。我让 AI 运行：

jinjinxia-client install copilot --url http://localhost:8080 --key jjx_xxx

返回 “Installed successfully”。AI 用 Read 工具读取 ~/.copilot/hooks/jinjinxia.json，显示内容完全正确，包含 JINJINXIA_KEY 和完整的 exe 路径。

但我在 VS Code 里打开同一个文件，看到的是旧版本 —— 没有 JINJINXIA_KEY，hook 命令是裸名称而非完整路径。

我以为 AI 的 Read 工具有缓存，让它”不要用缓存，重新读一次”。结果当然一样。

接着更多异常接踵而至：

异常 1：用户管理页面的数据丢失

我在浏览器打开 JinJinXia 的 Users 页面，能看到用户列表。切换到 About 页面再切回来，用户列表变空了。AI 修改了代码（在工作区内，同步正常），重启服务器后修好了。但数据库里的密码重置却总是”不生效” —— AI 在沙箱里改的 SQLite 和真实服务器用的不是同一个。

异常 2：Claude Code 的 hook 配置失踪

AI 多次运行 jinjinxia-client install claude-code，每次 Read 都显示 ~/.claude/settings.json 里有 hooks。但我在 Claude Code 里输入 /hooks，什么都没有。最终发现 Claude Code 使用模型特定的配置文件（~/.claude/settings_json/deepseek/settings_deepseek.json），而这个文件在沙箱外，AI 根本没碰到。

异常 3：Copilot hook 命令找不到

AI 读取 ~/.copilot/hooks/jinjinxia.json，显示 powershell 字段是完整 exe 路径。但 VS Code 的 Copilot 扩展报错 “jinjinxia-hook-copilot is not recognized”。因为 VS Code 读的是真实磁盘上的文件，那里还是旧的裸命令名。

排查过程：如何识别这是沙箱问题

当你遇到 “AI 说改了但没生效” 的情况，按这个顺序排查：

在真实终端打开同一个文件（PowerShell 里运行 type <path> 或用记事本打开）
对比内容和修改时间 —— 如果 AI 说”刚刚写入”但文件修改时间是几小时前，大概率是沙箱隔离
检查路径是否在工作区内 —— 如果文件在工作区外（~/.claude/、~/.copilot/、AppData/、数据库文件等），则确认是沙箱隔离
直接在真实终端执行相同命令 —— 如果命令输出不同或文件确实变了，说明之前 AI 只是在沙箱里操作

最关键的判断依据：AI 的 Read / RunCommand 永远返回”正确”结果，因为它读的是自己的沙箱副本。只有你在真实环境中验证，才能发现差异。

根因：TRAE 的沙箱文件系统隔离

TRAE Work 运行在一个轻量级 VM 中，有自己的文件系统：

真实磁盘:  C:\Users\kylin\.claude\settings.json
沙箱 VM:   C:\Users\kylin\AppData\Roaming\TRAE SOLO CN\VMCache\
           main-TRAE_SOLO-Yinli\drive\C\Users\kylin\.claude\settings.json

只有你选择的工作区文件夹会通过共享机制同步到真实磁盘。其他所有路径都是沙箱内的独立副本。

路径范围	同步到真实磁盘？	我遇到的具体案例
项目工作区（选中的文件夹）	是	JinJinXia 的 Python 源码修改正常同步
用户配置目录	否	`~/.claude/settings.json` 两边内容不同
Agent 平台 hook 目录	否	`~/.copilot/hooks/jinjinxia.json` 修改未落盘
SQLite 数据库	否	密码重置在沙箱生效但真实服务器未变
Python 包安装目录	否	`pip install` 装到沙箱的 Python，不是系统 Python

解决方案：正确分工

理解隔离机制后，工作模式变得清晰：

让 AI 在 TRAE 里做（工作区内）：

项目源代码的读写、重构、bug 修复
运行测试
启动开发服务器（端口映射到宿主机）
代码搜索和静态分析

自己手动做（工作区外）：

安装 CLI 工具（pip install、npm install -g）
修改 agent 平台配置（Claude Code、Copilot hooks）
数据库操作（SQLite、Redis）
环境变量和系统配置

最佳实践：让 AI 生成，你来执行。 比如 AI 生成完整的 hook JSON 配置或安装命令，你复制到自己的终端运行。这样既利用了 AI 的代码生成能力，又确保修改落盘。

如何避免踩坑

在 TRAE 中打开所有需要 AI 修改的文件夹作为工作区 —— 我后来把 KylinContent 也加入了工作区，blog 草稿就能正常同步了
涉及工作区外操作时，主动让 AI 输出完整命令/配置内容，然后你在真实终端粘贴执行
永远不要用 AI 的 Read 来”验证”工作区外的修改 —— 它只能验证沙箱副本
在项目文档中注明沙箱边界，帮助团队成员避免同样的困惑

总结

TRAE 的沙箱 VM 只同步工作区文件夹到真实磁盘，其他路径的操作全部隔离在 VM 内部
遇到 “AI 说成功了但没生效” 时，在真实终端验证文件内容和修改时间即可快速定位
正确分工：AI 负责工作区内的代码变更，你负责工作区外的配置和安装操作

这套隔离机制不是 bug，而是一条清晰的架构边界。理解它之后，你会发现 TRAE Work 的工作效率可以翻倍——关键就在于知道边界在哪里，以及什么时候该把控制权拿回到自己手里。

你在使用 AI 编程助手时遇到过类似的”幽灵修改”吗？欢迎在评论区分享你的经历和解决方案。