一下午都在 Cursor 的 Agent/Composer 里来回迭代，退出，第二天早上一开——对话列表空了。或者只剩今天那条，昨天那场深聊没了；又或者每条都卡在 Loading Chat 上一直转。有时候不用完全退出，Reload Window 一下就触发了。
最快的办法：先退出 Cursor，再用 File -> Open Recent 从项目原来那个完整绝对路径重新打开。绝大多数「丢」掉的历史其实没删，只是被绑在一个 workspace hash 上，而文件夹一旦移动、重新 clone、或者创建时间戳变了，这个 hash 就跟着变。如果这样还回不来，数据基本上也还在磁盘的 state.vscdb 里，按下面的步骤能找回来。
Cursor 的聊天历史是存在本地 SQLite 里的，不在云上。截至 2026 年 6 月（Cursor 3.7），没有内置的跨设备聊天同步——这一直是个呼声很高的 feature request，但并不是一个已经上线的设置。所以某条线程在这台机器上没了，恢复只能在这台机器的磁盘上做，靠「重新同步」是没用的。
Cursor 到底把聊天历史存在哪（截至 2026 年 6 月）
磁盘上一共三个位置，而且在整个 3.x 版本里挪过，所以三个都要查：
| 存储 | 路径（macOS） | 存什么 |
|---|---|---|
| 全局库 | ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb | 大部分聊天 / Agent 数据：composerData:*（线程头：标题、时间戳）和 bubbleId:*（单条消息） |
| Workspace 库 | ~/Library/Application Support/Cursor/User/workspaceStorage/<hash>/state.vscdb | 每个 workspace 指向全局库的链接；以及驱动侧边栏列表的 composer.composerHeaders key |
| Agent 记录 | ~/.cursor/projects/<project-slug>/agent-transcripts/ | 较新版本 Agent 按 run 写出的纯文本记录文件；即使侧边栏空了也能直接读 |
Linux 上前两个在 ~/.config/Cursor/User/... 下，Windows 在 %APPDATA%\Cursor\User\... 下。~/.cursor/projects/ 这个目录三个平台一样，都在你的 home 目录下。
agent-transcripts 这个目录是近期最重要的变化：哪怕应用里列表啥都没显示，你的 prompt 和 agent 的回复往往还以可读文件的形式留在那里。在你认定「真没了」之前，先去看这个目录。
常见原因
按命中率从高到低。
1. workspace hash 变了（文件夹移动、改名、重新 clone 或还原）
Cursor 用一个 workspace hash 给存储分桶，这个 hash 由文件夹的绝对路径算出来，某些情况下还掺了创建时间戳。把文件夹挪个位置、改个名、重新 git clone、从备份还原、或者网络盘重挂——Cursor 都会算出一个新 hash，建一个空的新 workspace，旧聊天就被孤立在旧 hash 下面了。东西没删。
怎么判断：File -> Open Recent 选回原始路径。线程回来了——就是它。如果文件夹确实搬走了，看 Step 3（把旧 workspace 重新关联回来）。
2. 版本升级时存储迁移出了岔子
升级时 Cursor 会迁移 SQLite schema。某些 3.x 升级会让旧线程显示成 Chat Too Old - this chat was created in an older version of Cursor and is no longer supported、Conversation has corrupted data，或者无限 Loading Chat 转圈。新建的对话能用，旧的浮不出来。
怎么判断：Cursor -> About（macOS）或 Help -> About 看版本。如果是自动升级之后历史立刻没了，并且看到上面任意一条原文——那是迁移问题，不是你操作错了。
3. 硬关导致 state.vscdb 损坏
线程正写到一半时 force-quit，可能让 SQLite WAL 留在 Cursor 恢复不了的状态。下次启动它就退而求其次建个新库，而不是直接打不开报错。
怎么判断：退出 Cursor 后，到 workspace 或全局存储目录里看有没有残留的 state.vscdb-shm / state.vscdb-wal，或者一个 state.vscdb.backup / state.vscdb-corrupted 同名兄弟文件。
4. 线程被孤立成 null workspace
有个已知故障会让 composerData 行原封不动（标题、正文都对），但它们的 workspace 关联被置成了 null，结果数据明明在那儿，侧边栏却一条都不显示。
怎么判断：跑 Step 4 里的 SQLite 查询。如果能查到 composerData:* 这些 key，但侧边栏是空的，那数据还在，只是没被关联上。
5. 有人为了腾磁盘把全局 state.vscdb 删了
globalStorage/state.vscdb 能涨到好几个 GB。网上那种「直接删了它」的建议是破坏性的：删完之后每一个项目都会永远卡在 Loading Chat，因为各个 workspace 库还指向已经不存在的线程 ID。
怎么判断：最近是不是有人（或某个「清理」脚本）删了或清空了那个文件？如果是，从备份还原；一旦没了，应用里没有任何恢复手段。
6. 撞上单 workspace 的体量行为
重度使用的 workspace 会攒下成千上万条 bubble。Cursor 不会激进删除，但超大或超旧的线程可能渲染成被截断、或加载失败，而新的都没事。
怎么判断：如果只有最旧、最大的线程出问题，最近的都完整——那是体量问题，不是整体丢失。
开始前
- 别先在空窗口里开新对话。新写入可能盖掉能恢复的备份，或者顶掉当前 workspace 的状态。
- 动任何存储文件前先完全退出 Cursor（
Cmd+Q/File -> Exit）。Cursor 开着改 SQLite 会把恢复机会也毁掉。 - 改任何东西之前先备份：
cp -r ~/Library/Application\ Support/Cursor/User/globalStorage ~/Desktop/cursor-globalStorage-backup
cp -r ~/.cursor/projects ~/Desktop/cursor-projects-backup需要收集的信息
- Cursor 版本（
Cursor -> About）。 - OS，以及上表里那几个确切路径。
- 今天的 workspace 路径 vs 创建历史那会儿的路径。
- 屏幕上的确切字串（如果有）：
Chat Too Old、Loading Chat、Conversation has corrupted data。 globalStorage/state.vscdb和对应workspaceStorage/<hash>/state.vscdb的文件大小。~/.cursor/projects/<slug>/agent-transcripts/里有没有文件。
一步一步修复
Step 1：开回原来那个 workspace
File -> Open Recent，选项目的原始绝对路径，要精确（大小写都算）。历史回来——你只是开到别的 workspace 去了。以后把规范路径加书签。这一步能解决最常见的那种情况。
Step 2：直接读 agent 记录
如果侧边栏空了、但你只是要内容，先看这里：
ls -la ~/.cursor/projects/
ls -la ~/.cursor/projects/<your-project-slug>/agent-transcripts/每个文件就是某一次 agent run 的可读记录。哪怕应用里的列表坏了，这里往往是一份完整的「你和 agent 都干了啥」的记录。先把要的内容拷出来，再去做风险更高的库操作。
Step 3：文件夹搬过之后把旧 workspace 关联回来
如果文件夹挪了或重新 clone 了，旧聊天就在旧 workspace hash 下面。把候选都列出来，找数据最多（state.vscdb 最大）的那个：
du -sh ~/Library/Application\ Support/Cursor/User/workspaceStorage/*/state.vscdb | sort -h社区工具 cursor-chat-recovery 能自动把旧的（有数据的）workspace 和新的（空的）配上。Cursor 完全退出后：
curl -fsSL https://raw.githubusercontent.com/cpeoples/cursor-chat-recovery/main/cursor-chat-recovery.sh -o cursor-chat-recovery.sh
bash cursor-chat-recovery.sh --list my-project-name
# 真写之前先预览
bash cursor-chat-recovery.sh --dry-run --restore <source-index> <target-index> my-project-name
# 确认无误再实跑
bash cursor-chat-recovery.sh --restore <source-index> <target-index> my-project-name跑完之后，从恢复所针对的那个确切路径重新打开项目。Windows 用户需要 Git Bash 或 WSL，PowerShell/CMD 跑不了这个脚本。
Step 4：自己查 SQLite 库
不想跑脚本的话，手动确认数据在不在。Cursor 退出状态下：
cd ~/Library/Application\ Support/Cursor/User/globalStorage/
sqlite3 state.vscdb "SELECT COUNT(*) FROM cursorDiskKV WHERE key LIKE 'composerData:%';"
sqlite3 state.vscdb "SELECT key FROM cursorDiskKV WHERE key LIKE 'composerData:%' LIMIT 20;"如果是更老的版本把聊天存在 ItemTable 里，试：
sqlite3 state.vscdb "SELECT key FROM ItemTable WHERE key LIKE '%composer%' OR key LIKE '%chat%';"有任何匹配行就说明数据在磁盘上。可以把某个 value 导出来看看：
sqlite3 state.vscdb "SELECT value FROM cursorDiskKV WHERE key = '<composerData:...>';" > thread.json如果你查到一堆有内容的 composerData:* 行、但侧边栏是空的，那就是 null-workspace 孤立这种情况（原因 4）：内容是安全的，只是 Cursor 不肯把它列出来。
Step 5：从 backup 文件恢复
如果你找到 state.vscdb.backup 或 state.vscdb-corrupted 同名兄弟文件，把当前文件挪开、把 backup 顶上去。在对应目录里（workspace 或全局）：
cp state.vscdb state.vscdb.broken
mv state.vscdb.backup state.vscdb重启 Cursor 看侧边栏。对原因 3（损坏）以及原因 5（全局库被删但有备份）来说，这是最干净的修法。
Step 6：处理「Chat Too Old」/「Loading Chat」迁移问题
迁移失败（原因 2）这种，数据通常完好，只是某一个 key 把列表卡住了。因为 state.vscdb 是 SQLite，你可以只精准清掉那个侧边栏列表 key，而不动设置、扩展、或线程本身。Cursor 退出后，在出问题的 workspaceStorage/<hash>/ 目录里：
cp state.vscdb state.vscdb.bak
sqlite3 state.vscdb "DELETE FROM ItemTable WHERE key = 'composer.composerHeaders';"重启 Cursor。它会从底层的 composerData/bubbleId 行重建列表头。如果没用，把刚才那个 .bak 还回去，往下走。
Step 7：兜底——重建 + 开 ticket
要是怎么都浮不出线程，退出 Cursor，把全局库挪开强制一次干净重建（旧的留着当备份）：
mv ~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb \
~/Library/Application\ Support/Cursor/User/globalStorage/state.vscdb.bak重启；大项目索引要几分钟。然后去 Cursor 论坛 或应用内反馈提报，带上版本、确切错误字串、前面查到的文件大小、以及 agent-transcripts/ 里有没有数据。确认恢复之前所有 .bak 文件都先留着。
怎么验证修好了
- 打开恢复后的 workspace，对比线程标题和你记得的一致。
- 点进一条旧线程，确认对话完整、没被截断、也没卡在
Loading Chat。 - 退出再重开 Cursor 一次，确认历史扛得住重启。
- 把现在全局库的大小和备份比一下，确认没有悄悄少行。
长期预防
- 用
Cmd+Q（macOS）或File -> Exit退出；尽量别 force-kill——它就是 WAL 损坏的常见元凶。 - 用稳定的绝对路径。有了 Composer/Agent 历史之后，别移动、改名、或重新 clone 那个文件夹，workspace hash 会变。
- 千万别为了腾磁盘删
globalStorage/state.vscdb——它会把每个项目的聊天列表都搞废。 - 不可替代的重要线程，导出一份：打开线程 → 三点菜单 →
Export存成 Markdown。 - 留着
~/.cursor/projects/.../agent-transcripts/那些文件，它们是你最可读的保命备份。 - 想要真正的跨机器衔接（截至 2026 年 6 月 Cursor 原生还没有），用社区同步 CLI（比如
cursaves，把记录推到一个私有 git 仓库），或者用 Time Machine /rsync备份globalStorage/和~/.cursor/projects/。
容易踩的坑
- 还没查 workspace 路径或 transcripts，就先在空窗口开了新对话。新写入可能盖掉能恢复的备份。
- Cursor 开着改
state.vscdb，一定要先退出。 - 听信磁盘清理建议删掉全局
state.vscdb——这是最具破坏性的一步，会让每个项目都卡在Loading Chat。 - 以为聊天在云上。它只在本地，没有原生同步可以重拉。
- 项目用到一半改文件夹名或挪位置，hash 一变，活跃线程立刻从侧边栏消失。
- 把
Reload Window当无副作用操作。它会重新 init 状态，有时会暴露一个陈旧或空的存储路径。
常见问答
- Cursor 聊天历史到底存哪？ 3.7 里一共三处：
globalStorage/state.vscdb（大头）、workspaceStorage/<hash>/state.vscdb（每个 workspace 的链接，以及那个composer.composerHeaders列表 key）、还有~/.cursor/projects/<slug>/agent-transcripts/下的纯文本记录文件。macOS 上前两个在~/Library/Application Support/Cursor/User/下，Linux 在~/.config/Cursor/User/，Windows 在%APPDATA%\Cursor\User\。 - 聊天历史会同步到我的 Cursor 账号吗？ 不会。截至 2026 年 6 月 Cursor 没有内置的跨设备聊天同步，这是个高票 feature request、不是设置。历史只在每台机器本地，所以要在丢失的那台机器上恢复。
- 升级后聊天显示「Chat Too Old」或一直「Loading Chat」，是丢了吗？ 通常没丢。那是迁移 / 列表头问题。试 Step 6（清
composer.composerHeaders）；composerData/bubbleId这些行一般是完好的。 - 我为了省磁盘删了 globalStorage/state.vscdb，现在全都「Loading Chat」，能撤销吗？ 只能从备份还原那个文件（Time Machine、
rsync、或你自己的拷贝）。没备份就没法恢复——这正是删它如此危险的原因。 - 同一个项目通过 symlink 或重新 clone 的副本打开，会共享历史吗？ 不会。workspace hash 不一样，两份独立存储。要么从原始路径打开，要么用 Step 3 的恢复工具重新关联。
- 能单独导出一条对话吗？ 能——打开线程，点三点菜单，选
Export存成 Markdown。任何丢不起的对话都先这么导一份。