昨晚TRAE Work CN更新后，让TRAE帮改个表字段名称，结果TRAE把几十个不相干的文件缩进空格改了：2个改成1个，4个改成2个，6个改成3个等，这是什么BUG？太浪费时间了。
/Plan模式会出现生成的计划内容在执行时被旧的不相关计划覆盖的情况，文件名是正确的新计划，但是里面的内容完全是其他计划的内容
发帖材料.zip (257.3 KB)
发帖材料.zip (257.3 KB)
使用trae work 过程发现一个问题，版本信息：TraeWork CN
版本: 0.1.59
提交: d01780104770defb6500f257b54d684ab054b38d
日期: 2026-08-27T09:29:15.568Z
Electron: 39.2.7-release.1.51.2 (aha)
Node.js: 22.21.1
V8: 14.2.231.27-electron.0
OS: Windows_NT x64 10.0.26200
构建版本: 2.3.78539
设备ID: 569a5fd7cb31ca73d57132e1ecaf3f388bbb1edbdf73297bd2660b7dd04b78df
Web SDK Version: 1.6.51
Device Id: 2785476841598281 问题：在添加外部模型过程中，通过自定义添加了A厂商的glm-5.2，然后A厂商用完了，会提示token plan quota exhausted (Model Provider Error Code: 20098, HTTP Status: 500) (4028) 。接着，我新添加B厂商的glm-5.2模型，发现还是出现同样的错误，但是我拿B厂商的对接信息去别的电脑上的trae work或其他工具使用，又是正常的，同样是glm-5.2模型。最后我在我本机电脑删掉A厂商的对接模型信息，然后再去测试使用B厂商的glm-5.2模型，现在又正常了，这个是什么原因呢？如解决，麻烦给一个信息响应一下。实际中我们A厂商的下个月可能又充值进来了，然后我又得去添加一次，密钥等信息很难找的啊。处理好麻烦给一个回复，谢谢。
为什么每次关闭traeCode，都会弹窗自动重新安装一次？？？？ 是更新吗？
使用TraeIDE打开markdown文件，打开预览模式，预览文档的左上角的“目录图标”体验不好。目前最新版升级后，“目录图标”默认不展示了，需要鼠标滚动后再滚动到顶部后，这个“目录图标”才显示出来，然后是随预览文档滚动。建议左上角的“目录图标”固定悬浮在左上角，而不是随预览文档滚动。
trae在工作期间，多次出现自动手动终止，uid4258822709074516
需要核查积分消耗情况
- 2026 年 9 月 2 日 17:57 左右，我在 TraeWork 发起了一项批量处理任务，并选择了 auto 模式自动执行。发起时账号积分余额为 13559.77。
- 当晚 20:00 左右我查看时，Obsidian中笔记以处理完成，但任务进程并未真正停止，仍在持续运行。我以为很快会结束，就没有干预。
- 2026 年 9 月 3 日早上发现，账号积分已从 13559.77 全部消耗至 0，约 1.36 万积分在一夜之间被全部扣光。
我的需求： - 该任务在Obsidian仓库中以完成了工作任务，但工作agent进程仍在持续运行并继续消耗积分？是否属于任务未正确终止的异常？
- 一个任务在已完成的状态下，是否可能消耗如此大量的积分？请协助核查该任务实际的积分消耗明细。
- 如果核查确认存在异常消耗，恳请将异常扣除的积分予以退回。
基本信息：
TRAE Work版本： 0.1.62
操作系统：windows 11
sessionid：1505656606040172:d3cbb40e28b0530959e0f1c5909c279e_6a9798597d23ae95809b21f8.6a97f2e07d23ae95809b2a57.6a97f2e07d23ae95809b2a55:TraeWork CN.0.1.62.no_sid.no_ppe.T(2026/9/2 17:56:48)
我想取消继续执行了，我另外开任务算了，但是取消不了
使用/plan 制定计划完成后会给出三个选择，选择修改方案，输入修改提示后，生成的方案，没有方案变动记录了，相当于是新的方案；不知道第二次方案改动了哪里，要重新人工审核生成的方案
[严重 / 数据丢失] Trae Solo 自动更新(2.3.795 → 2.3.79943)在 4 分钟内删除了 D 盘 26 万+ 文件,含个人隐私数据
工单类型:数据丢失 / 安装器逻辑错误
严重等级:Critical(不可逆数据丢失 + 涉及个人敏感信息)
涉及版本:TRAE SOLOSetup-stable-2.3.795-B63DB8B1
报告日期:2026-09-04
报告人:Trae Solo 用户(国内个人开发者)
一句话摘要
Trae Solo 在后台执行版本升级时(2.3.795 → 2.3.79943),安装包误把升级前的"清理旧版本"操作扩大到了整个 D 盘,4 分钟内触发 266,595 次文件删除操作,绕过回收站,造成不可恢复的数据丢失。丢失的数据中包含 1,007 份含身份证号的劳动合同 PDF、32 个桌面快捷方式、以及用户的全部项目代码 / 工作资料。
环境信息
| 项 | 值 |
|---|---|
| 操作系统 | Windows 10/11(管理员账号) |
| Trae Solo 升级前版本 | 2.3.795(commit B63DB8B1) |
| Trae Solo 升级后版本 | 2.3.79943 |
| 受影响磁盘 | D 盘(NTFS),共 ~500 GB,其中约 80 GB 用户数据 |
| 同一时刻运行的项目 | F:\tvbox\sj\ai编程\xmgl_v1.0(React + TS + Express,正在跑两个 npm dev server) |
| D 盘是否开启 VSS / 系统还原 | 否(0 个还原点,0 个卷影副本) |
| 文件系统 | NTFS,USN Journal 已启用并完整导出 |
事件时间线(均为本地时间 +08:00,精确到秒)
9/2 上午 11:14 之前 — Trae Solo 正常运行
| 时间 | 事件 | 证据来源 |
|---|---|---|
| 08:03 | MSEDGE 启动 | Windows Prefetch |
| 08:38 | CODEX CLI 启动 | Windows Prefetch |
| 11:06:03 | Trae Solo 删除一个 index.lock(正常) |
D 盘 USN Journal |
| 11:14:18 | 用户观察:Trae 主窗口自动关闭,弹出自动安装进度界面 | 用户陈述 |
| 11:14:19 | 删除风暴开始 | D 盘 USN Journal |
9/2 上午 11:14–11:18 — 安装包删除风暴(共 4 分钟)
逐秒逐分钟删除计数(从 USN Journal 提取):
| 时间(秒级聚合) | 删除次数 | 备注 |
|---|---|---|
| 11:14:19–11:14:59 | ~50,000 | 首先清空 D 盘回收站(606 个 $I + 607 个 $R)+ 删除 Trae 自身旧文件 |
| 11:15:00–11:15:59 | 56,472 | 项目代码、依赖包、缓存 |
| 11:16:00–11:16:59 | 147,208 | 删除峰值,几乎全盘 |
| 11:17:00–11:17:59 | 56,976 | 删除仍在持续 |
| 11:18:00–11:18:59 | 5,665 | 收尾,少量残留 |
| 11:18:59 之后 | <50/小时 | 风暴结束 |
| 总计 | 266,595 | — |
Prefetch 中 11:14–11:18 窗口内唯一命中的可执行文件:
C:\Windows\Prefetch\TRAE SOLOSETUP-STABLE-2.3.795-B63DB8B1.pf
文件 mtime = 2026-09-02 11:17
(Prefetch 是 Windows 内核级的程序启动记录器,无法被应用伪造或关闭。)
9/2 上午 11:18 之后 — Trae Solo 重启并完成升级
| 时间 | 事件 | 证据来源 |
|---|---|---|
| 11:20 | 火绒(HIPSLOG)开始记录异常 | Windows Prefetch |
| 11:21 | 升级后的 TRAE SOLO CN.EXE 启动 |
Windows Prefetch |
| 11:22 | 用户在 Trae 中运行的 npm run dev 和 npm run backend:dev 任务被强杀(exit code -1) |
AppData\Local\Temp\trae-agent-toolhost\jobs\*.json |
| 16:02 | StartMenuExperienceHost 启动(系统空闲) | Windows Prefetch |
| 18:22 | 安装器把新版安装包 TRAE SOLOSetup-stable-2.3.79943.exe(430 MB)落到 C:\Users\Administrator\AppData\Local\Temp\solo-cn-user-x64\ |
文件 mtime |
9/4 今天(写这份报告的同一天)
C:\Users\Administrator\AppData\Local\Temp\solo-cn-user-x64\
└─ TRAE SOLOSetup-stable-2.3.81345.exe.a4co49kn5sf.tmp (94 MB,正在下载)
→ 同一台机器上,Trae Solo 还在尝试自动下载更新。
安装器最先删除的"自己的文件"(关键证据)
USN Journal 显示,删除风暴的前 1 秒(11:14:33–11:14:34) 安装器处理了这些 Trae 自身的文件:
2026/9/2/周三 11:14:33 TRAE Work CN.lnk ← Trae 桌面快捷方式
2026/9/2/周三 11:14:33 codex-windows-sandbox-setup.exe
2026/9/2/周三 11:14:33 windows-updater.node
2026/9/2/周三 11:14:34 CodexPlusPlus-1.2.36-windows-x64-setup.exe
2026/9/2/周三 11:14:34 MinerU-0.14.1-setup.exe
2026/9/2/周三 11:14:34 TRAE-memory-import
2026/9/2/周三 11:14:34 TRAE_Work_CN-Setup-x64.exe ← 旧版 Trae 安装包本身
2026/9/2/周三 11:14:34 TRAE会话迁移包_2026-08-26.zip
2026/9/2/周三 11:14:34 TRAE会话迁移包_2026-08-26 (1).zip
2026/9/2/周三 11:14:34 TRAE会话迁移包_2026-08-26 (2).zip
2026/9/2/周三 11:14:34 author-memory.md ← Trae 记忆模块
2026/9/2/周三 11:14:34 author_memory_commit.py
2026/9/2/周三 11:14:34 memory-cache-store.js
2026/9/2/周三 11:14:34 memory1786011029299.ts
2026/9/2/周三 11:14:34 memory1786011127174.ts
2026/9/2/周三 11:14:34 project_memory.md
2026/9/2/周三 11:14:34 session_memory_019fb2a1-596e-74c3-9d2a-b3c168e3b1c2.jsonl
随后 11:14:40 开始清理 @deepseek-ai 包目录,然后删除风暴扩散到 D 盘全部文件。
→ 这是典型的"清理脚本路径边界检查失败"bug:原本只想清 Trae 自己的安装/缓存/会话目录,但清理逻辑遍历到了整个 D 盘。
删除风暴开始前的"准备动作"(更关键)
风暴开始前 0 秒前(T=11:14:19),USN Journal 记录的第一批删除全是 D 盘回收站的 $I 文件(Recycle Bin 元数据):
2026/9/2/周三 11:14:19 $I005Z9P
2026/9/2/周三 11:14:19 $I06GY6Q
2026/9/2/周三 11:14:19 $I07ZF6R.png
... (606 个 $I 文件 + 607 个 $R 实际内容文件)
→ 安装包在执行清理之前主动调用了 SHEmptyRecycleBin 之类的 API 清空回收站。这一步是数据永久丢失(无法恢复)的直接原因:正常情况下回收站里的内容至少有一次撤销机会。
涉及的个人敏感数据(需要厂商特别关注的法律风险)
USN Journal 记录了 1,007 个含敏感个人信息的文件名,样例:
付于恒-511302199107060048-劳动合同.pdf
代强-511302198512071918-劳动合同.pdf
任拯民-511321199003100155-劳动合同.pdf
何俊杰-511321199210095379-劳动合同.pdf
何勇平-511325197912211318-劳动合同.pdf
... (上千份,均为员工姓名+身份证号+合同)
格式上呈 [姓名]-[身份证号]-[文件类型].ext,属于**《个人信息保护法》第 4 条**规定的敏感个人信息。安装器未经用户授权清空包含此类文件的回收站,且无法恢复,法律风险已经实际发生。
预期 vs 实际
| 期望行为 | 实际行为 |
|---|---|
| 自动更新只清理 Trae 自己的目录 | 清理脚本遍历到整个 D 盘根目录 |
| 删除前应该备份或至少提示 | 无任何提示,主进程静默退出,安装 UI 自动弹出 |
| 应该尊重回收站里的数据 | 调用 SHEmptyRecycleBin 主动清空回收站 |
| 升级失败时回滚 | 升级"成功",但用户的数据已经回不来 |
| 删除路径应该是白名单(精确路径) | 看起来是黑名单/正则匹配,导致"凡是带 trae/deepseek/memory 字样的都删"被错误扩大 |
建议复现路径(供你们内部 QA)
1. 在 D 盘根目录下放若干"诱饵文件"(文件名包含 trae / deepseek / memory / setup / update 等关键字)
2. 启动 Trae Solo 1.x,让其在 D 盘写入带上述关键字的会话文件
3. 触发自动更新或手动执行 TRAE SOLOSetup-stable-2.3.795
4. 观察 D 盘诱饵文件是否被一并删除
5. 检查安装器是否调用了 SHEmptyRecycleBin / RemoveDirectoryW 之类 API
建议修复(供工程团队参考)
- 强制白名单:升级脚本的清理目标必须用绝对路径枚举(例如
C:\Users\<user>\AppData\Local\aha_doctor\TraeWork CN\old\),严禁用通配符或正则扫 D 盘根目录。 - 禁止静默清空回收站:升级流程中任何
SHEmptyRecycleBin调用必须改为"标记文件 → 等用户确认"。 - 删除前落审计日志:每个被删除的文件路径 + 大小 + 哈希写入
AppData\Local\aha_doctor\TraeWork CN\log\install-cleanup-<时间戳>.log,便于事后追溯和恢复。 - 提供"安全模式"开关:在 Trae 设置里加"升级前先备份用户工作目录"开关,默认开。
- 降级路径:当用户主动降级或升级失败时,必须能通过备份回滚到旧版本。
用户已经做的临时缓解措施
- 已关闭 Trae Solo 的自动更新(等待你们确认更安全的更新策略)
- 已将 D 盘的关键文件移至 C 盘 / OneDrive 并开启版本历史
- 已准备向字节安全团队备案此事件
证据文件清单(随附件提供)
| 文件 | 路径 | 说明 |
|---|---|---|
| D 盘 USN Journal 9/2 全集 | C:\Users\Administrator\WorkBuddy\2026-09-04-16-13-00\usn_d2_full.txt(266,595 行,12 MB) |
每一条删除事件的精确时间戳 + 文件名 |
| Trae Solo 主进程日志 | C:\Users\Administrator\AppData\Local\aha_doctor\TraeWork CN\log\1.35.0.3-2026-08-25_08_07_07.log |
Trae 自身日志(注:9/2 当天的日志疑似被升级过程覆盖,只剩 8/25 的旧日志,这也是你们内部要查的另一个问题) |
| npm 任务被杀证据 | C:\Users\Administrator\WorkBuddy\2026-09-04-16-13-00\trae_job_2e9fe2ef.jsonC:\Users\Administrator\WorkBuddy\2026-09-04-16-13-00\trae_job_58a3d5c1.json |
Trae-agent-toolhost 杀进程的 JSON 证据 |
| 新版安装包 | C:\Users\Administrator\AppData\Local\Temp\solo-cn-user-x64\TRAE SOLOSetup-stable-2.3.79943.exe |
升级后的目标版本安装包(430 MB) |
| 旧版安装器 Prefetch | C:\Windows\Prefetch\TRAE SOLOSETUP-STABLE-2.3.795-B63DB8B1.pf |
直接证据:安装器在删除窗口内启动 |
期望回复
- 确认收到此工单
- 提供内部排查进度
- 给出数据恢复的官方建议(如果你们有内部工具可以读取 USN Journal 之前的扇区残留)
- 给出后续版本对此 bug 的修复时间表
报告人联系方式已通过 Trae IDE 账号 Administrator 关联,工单可定向回复。
Trae_Bug_提交.zip (10.1 KB)
bug反馈在这个专栏