周末打开 VSCode原本只是想继续改那个拖了很久的小项目。结果代码还没看几行余光先扫到了侧边栏的 Copilot Chat——一排旧对话里周一查过的“表格固定列闪烁”还悬着周三让它帮忙写的类型定义也还在周五排查 Docker 内网访问超时的记录更是占了半屏。想找到当前真正要用的那条信息得往下翻好几屏。那一刻我下定决心顺手把这些历史对话全部清掉。但真动起手来才发现“清除 VSCode 里的 Copilot Chat 对话”这件事远不止点一下删除按钮那么简单。整个清理过程里我踩了几个不大不小的坑也把界面操作、命令面板、乃至于直接动本地缓存文件的方案都试了一遍。这篇东西就是这次清理的完整记录。如果你也只是想让面板干净一点看前两章就够了如果你是界面失灵、或者出于隐私考虑想彻底抹掉记录那重点看第三章。1. 清理之前先看清楚Copilot Chat 的对话记录放在哪1.1 界面上的历史记录不等于磁盘上的全部数据在 VSCode 里用 Copilot Chat最直观的交互界面就是侧边栏的 Chat 面板。当前对话、历史记录列表都在这里展示。很多人以为“我把列表里的这一条删掉了这个对话就彻底消失了”其实这个理解只对了一半。你在界面上点击删除VSCode 只是把这几条记录的展示入口给移除了真实的数据往往是另一套逻辑。这就好比浏览器里清除了地址栏的下拉记录本地数据库里可能还躺着完整的访问痕迹。对“列表太乱”来说界面删除确实够用但要是心里想的是“让下一个打开 VSCode 的人完全看不到我之前问了什么”那靠点界面按钮是远远不够的。我见过不止一个同事在准备把电脑交还给公司、或者换新机器之前只是在 Copilot Chat 面板里点了删除觉得隐私已经清干净了。后来换台机器登录同一账号或者别人打开他的面板重新加载一下旧对话的影子还是会回来。归根结底是没有搞清楚 Copilot Chat 到底把东西写在了哪里。1.2 本地存储的三个常见位置以目前主流的 VSCode 搭配 GitHub Copilot Chat 扩展为例对话相关的数据通常分布在下面这几处存储位置典型路径/文件大致内容扩展全局存储目录globalStorage/github.copilot-chat/会话历史、聊天元数据、会话索引VSCode 用户级本地状态库Code/User/state.vscdbSQLite 格式扩展的部分设置、少量状态数据工作区级状态库workspaceStorage/哈希/state.vscdb与当前打开项目相关的缓存或临时上下文具体到目录Windows 上一般在%APPDATA%\Code\User\globalStorage\github.copilot-chat\macOS 对应~/Library/Application Support/Code/User/globalStorage/github.copilot-chat/Linux 则是~/.config/Code/User/globalStorage/github.copilot-chat/。如果你用的是 VSCode 的 Insider 版本、或者一些基于 VSCode 改版的编辑器路径前缀会相应变化但globalStorage这个目录结构基本不会变。大概有人会问这些对话不是应该存在云端换个设备就能同步吗以我自己的实际体验Copilot Chat 的会话历史在绝大多数情况下是本地优先的并不像你想象中那样自动漫游到每一台设备。不同机器登录同一个账号历史列表未必一致反而更容易造成“这边删了那边又冒出来”的错觉。真正靠得住的判断标准还是看本地磁盘上有哪些文件。1.3 为什么经常出现“删不干净”的怪现象很多人在面板里把所有可见对话删除之后重启 VSCode 却发现有一条旧记录还在。这通常有三个原因第一扩展自己维护了一份数据VSCode 主进程的本地状态库又维护了一份索引。界面删除只把扩展层的数据标记掉了状态库里可能还残存着键值下次加载时又被重新读了出来。第二一个对话可能在多个工作区之间被复制。你在这台机器上清理了全局存储但某个项目的workspaceStorage缓存目录里还留着对应的记录。过几天重新打开那个项目旧对话又出现了。第三某些版本的 Copilot Chat 扩展删除动作并没有真正触发磁盘删除只是视觉上隐藏了。等到 VSCode 崩溃、重启、或者扩展自动更新后重构缓存时列表又变回原样。我自己的例子是曾经只删某一次“代理模式下排查数据库死锁”的长对话当时界面已经显示删得干干净净。结果隔天打开另一个工作区它又出现了。当时还不知道工作区缓存这回事后来顺着路径翻出来才明白——清理这件事真是得搞清楚它存放的层级才能谈得上“快速”。2. 图形界面清法从删除单条到一键清空历史2.1 先找到历史记录的入口新版 Copilot Chat 把历史记录收进了一个类似时钟或气泡的图标里位置在 Chat 面板的顶部区域。点开之后你能看到按时间倒序排列的会话列表每条会话通常带有一个自动生成的标题。如果你的 VSCode 界面版本比较旧历史记录也可能直接列在 Chat 面板下方或者需要通过命令面板里的Copilot Chat: Show History之类的命令唤出。图标的样式并不重要关键是你要能找到那个“能看到过往每一段对话”的入口。找不到入口的话后续所有界面操作都无从谈起。2.2 删除单条对话的细节与隐藏坑找到某条目标对话后把鼠标悬停到会话标题那一行通常会出现一个删除或者垃圾桶类的图标点击即可删除。有的版本会弹确认框有的版本点了直接删不需要反复确认。但我在清理过程中发现删除入口有时候藏得比较深。部分版本的 Copilot Chat 悬停时显示的并不是垃圾桶而是一个“...”更多按钮点开之后才有Delete Conversation。更隐蔽的情况是如果你去右键点击会话条目弹出的菜单里不一定有删除项——尤其在某些旧版本里右键菜单只提供重命名、在新窗口中打开之类的选项。一个很多人不知道的小技巧直接把鼠标放到会话条目上选中它然后按键盘上的Delete键。部分版本是支持这个快捷键的特别是在历史列表获得焦点的情况下。这个操作比找图标快得多。2.3 /clear 和 New Chat别把“清上下文”和“删历史”混为一谈有些人说的“清除对话”其实不是删历史而是想把当前聊天窗口里已经聊乱了的上下文清掉重新出发。这里有两个你一定会遇到的操作但它们的差别非常大在输入框里输入/clear并回车当前会话内的上下文会被清空但会话本身还会保留在历史列表里。它清掉的是“记忆”不是“记录”。点击 New Chat 新建对话相当于开了一个新会话原来的会话原封不动地留在历史列表里想回看随时可以回去。这两个操作经常被混为一谈。如果你遇到的具体场景是“刚才聊了很多但代码都写出来了现在想换个话题继续”直接用 New Chat 就好完全不用动删除操作反而给自己留了一条回看的退路。如果你想要的是“从头再来但又不想留任何记录”那才需要先/clear然后再去历史列表把当前会话删掉。两件事是两步别指望一个操作全搞定。2.4 一键清空全部历史命令面板其实是最快路径如果历史列表里已经有几十条对话逐条去点删除图标显然不现实。这种时候最快的路径是命令面板按Ctrl/Cmd Shift P打开命令面板输入Clear Chat History找到对应命令并回车执行。执行完之后历史列表会回到一张白纸状态。不过我必须提前打一个预防针并不是每个版本的 Copilot Chat 都提供这个命令。我在比较老的版本上搜遍命令面板都找不到它最后不得不走向下一章的本地文件方案。如果你的版本里搜不到这条命令别在界面里继续耗时间。另外还有一种听起来不太像清理、但很实用的“以刷新代替删除”的方式那就是执行Developer: Reload Window重载当前窗口。它本身不做真正的数据删除但对某种假死状态非常有效比如你明明删了对话但它还顽固地停留在列表里怎么点都刷新不掉。重载一下窗口界面缓存的脏数据被强制丢弃列表往往立刻就干净了。遇到这种半卡死的情况别急着去翻磁盘先重载一次再说。3. 界面失灵也不慌本地缓存目录的精确清理方案3.1 什么情况下需要动到本地文件界面按钮解决绝大多数轻量清理需求但它不是万能的。我把需要动到本地文件的场景总结成四类扩展界面卡死删除按钮怎么点都没反应历史列表中出现了“幽灵会话”界面上根本不显示这条记录但它就是占着历史位置不消失需要批量清理几百条历史逐条点在时间成本上实在不划算隐私级别的要求换人、换机、归还电脑之前你要确保本地磁盘上没有任何旧的对话痕迹。这几类场景里命令行反而是最干净、最可控的路径。它绕开了界面层的缓存问题直接对真实数据动手效果立竿见影。3.2 前置准备退出 VSCode并备份动文件之前有一个绝对前提先把 VSCode 完全退出不是关掉窗口而是确保进程里没有任何 Code 相关进程在运行。原因很简单VSCode 在运行时会锁定这些文件或者持续写入。如果边运行边删可能遇到文件被占用导致删除失败还可能因为读写时序问题让扩展在下次启动时重建出一堆异常状态。退出之后强烈建议先做备份。这一步看起来多余但它属于“改完很难后悔”的操作做了备份后面再怎么折腾都不慌。以 macOS 和 Linux 为例cp -r ~/.config/Code/User/globalStorage/github.copilot-chat ~/copilot-chat-backup-$(date %Y%m%d)Windows 下用 PowerShellCopy-Item -Path $env:APPDATA\Code\User\globalStorage\github.copilot-chat -Destination $env:USERPROFILE\copilot-chat-backup -Recurse备份完成后再进入下一步。这点时间换来的是安心很值。3.3 定位缓存文件判断该删什么进入扩展的全局存储目录之后你会看到若干文件。不同版本的 Copilot Chat 文件组织方式差异较大常见的有chatSessionHistory.json、一些数据库文件、以及存放会话内容的子目录。千万不要一上来就把整个目录删掉先看内容再决定ls -la ~/.config/Code/User/globalStorage/github.copilot-chat/如果目录里出现了明显的 json 文件可以用less或grep先瞥一眼确认里面确实存的是会话内容再动手处理。我见过有同事直接把整个目录一股脑删掉的结果发现里面还存着一些自定义的界面设置虽然损失不大但平白多了一次恢复步骤。看一眼再删永远比盲删稳妥。3.4 两种删法粗粒度清空与 SQLite 精确删除如果目标是把所有对话全部抹掉最简单稳妥的办法是把整个github.copilot-chat目录改名而不是直接删除。改名相当于给自己留了个后悔药mv ~/.config/Code/User/globalStorage/github.copilot-chat ~/.config/Code/User/globalStorage/github.copilot-chat.bak下次启动 VSCode 后Copilot Chat 会发现没有历史记录目录自动初始化一个空的历史库。你看到的界面就是一个全新的、干干净净的聊天面板。但如果你只想删某一条特定对话而且这条记录恰好藏在state.vscdb里那就需要借助 SQLite 工具。VSCode 的state.vscdb本来就是 SQLite 格式可以直接用系统自带的sqlite3命令或者任意 SQLite 客户端打开sqlite3 ~/.config/Code/User/state.vscdb打开以后先看看有哪些相关键值SELECT key FROM ItemTable WHERE key LIKE %copilot%;找到跟 Copilot Chat 相关的键之后再执行删除DELETE FROM ItemTable WHERE key LIKE %github.copilot.chat%;这里必须把话说重一点这条删除语句会删掉所有键名里带该关键字的键值不只是对话历史。所以执行之前一定先SELECT查出来看看确认那些键值确实是聊天相关的数据再动手删。不确定的键宁可不删也不要错删。删除之前顺手备份一下state.vscdb看起来谨慎实际上是在给自己省麻烦。3.5 别漏了工作区级的残留清理全局存储之后旧对话仍然可能出现十有八九就是工作区级缓存没处理干净。处理思路和前面完全一致找到workspaceStorage目录下对应的哈希子目录里面同样有一个state.vscdb打开看一眼再决定怎么处置。有一点比较麻烦这些哈希目录名和项目路径不是一一对应的可读关系。打开子目录里的workspace.json文件里面记录了该工作区对应的真实项目路径。通过它来确认哪个缓存属于哪个项目然后再决定要不要处理。千万不要凭感觉乱删否则可能误伤其他项目的缓存数据得不偿失。4. 清除之后会怎样受影响和完全不受影响的部分4.1 可以放心的代码文件和补全能力都不受影响很多人担心清理对话会连累 Copilot 的代码能力觉得聊天记录就是它的“记忆”记忆没了它也就变笨了。这个担心属于误解。Copilot 的代码补全、代码建议能力依赖的是扩展建立的本地索引和远程推理服务跟聊天历史是否清空没有直接关系。聊天历史只是你和它之间沟通的过程记录真正生成代码、分析代码时用到的上下文是从当前打开的编辑器内容、文件内容、项目结构中实时提取的。对话历史清掉之后补全功能该怎么用还怎么用Agent 模式也照样能分析项目结构。你在清理时完全不用担心这一点。4.2 会真正失去的连续性的上下文清理对话最直接的代价是失去一段“延续的上下文”。举个例子你花了一下午让 Copilot 陪你排查一个分页查询慢的问题从最初怀疑索引失效到一步步定位到 ORM 生成的 N1 查询再到最后改写方案。整套排查思路都沉淀在同一个对话里。这时候如果点击删除下回再想让它基于那套排查思路继续给建议就得把整个需求、已经做过的尝试、得到过的结论全部重新描述一遍。这种代价在“对话比较长、中间思路比较曲折”的场景下尤为明显。所以我现在的习惯是在清理历史之前先快速扫一遍列表问自己几个问题这条对话里的信息我是不是已经写进代码注释了是不是已经变成文档或者 commit message 了如果答案是否定的那就先把值得留的内容复制出来再动手删。顺序反了损失是实实在在的。4.3 误删之后有后悔药吗直接说结论Copilot Chat 的界面删除没有可靠的撤销入口。我亲眼见过有人以为点完删除之后按CtrlZ能救回来实测是救不回来的。聊天记录的删除属于独立存储的移除不像编辑器里的文本删除没有文本缓冲区这个概念快捷键撤销对它完全无效。所以恢复这件事只能依赖备份macOS 如果有 Time Machine可以回退整个目录Windows 如果开启了文件历史记录或系统还原点也有机会找回被删除的缓存文件手动备份的目录像上一章里提到的mv或cp是最可靠的后悔药。为了不走到“找后悔药”这一步更实际的做法是凡是花费了较多时间才拿到的对话内容不要在对话里裸放。你可以点会话右上角的Open in Chat Editor把对话内容引入到一个独立的 Chat Editor 标签页然后另存为 Markdown 文件放到项目的docs/目录下。这样清历史的时候完全没有任何心理负担。4.4 有些场景不建议手快在下面这几种情况下我的建议是先忍一忍别急着清理第一正在跨文件推进大型重构的时候。这个阶段对话里往往积累了对模块边界、依赖关系的复杂判断一旦删除重新建立这套认知需要额外很多轮沟通。第二在对比不同的模型或者不同的配置方案时。同一段需求你可能让 Copilot 换着方式回答过好几轮旧对话里保留着这些对照价值很高。全删了后面再做回归对比就没了依据。第三刚改完自定义指令或者刚接入新工具链、还没验证稳定的时候。保留历史能让你快速回顾哪些改动有效、哪些改动反而变差了。等整套配置稳定下来再清理更从容。5. 把清理做成日常习惯减少下次清理的摩擦5.1 给对话命名清理才有目标Copilot Chat 历史列表里的会话默认是自动生成标题的勉强能用但不够明确。我的做法是每次开始一个明确任务时先新建一个会话把它重命名为“日期任务”的格式。比如2025-06-14 修复仪表盘图表定时刷新。这个习惯看起来不起眼实际上省了很多事。一周之后扫一眼列表哪些能删、哪些还能复用一眼就能判断不用再逐条点进去看内容。尤其当你的列表里有十几条历史时这个命名习惯的价值会非常明显。5.2 按周归档而不是等它堆成山清理最怕的就是“积攒太多不想动继续积攒”的恶性循环。我现在养成的节奏是每周五下班前花五分钟处理一下 Chat 历史流程基本固定把本周还值得保留的对话用 Chat Editor 导出成 Markdown 文件按项目维度归档到仓库的docs/目录归档之后返回历史列表把对应的会话一一删除没有归档价值的琐碎问答直接删除不犹豫。这个节奏坚持一段时间后我的 Chat 列表常年保持在十条以内。每次打开都是一个干净的起点不用再担心几千条历史占用的磁盘空间和界面加载负担。而且因为工作量被拆分到每周每次清理都只花五分钟心理阈值很低不容易拖延。5.3 共用设备场景下的额外一步如果你的电脑不完全私人比如公司共用开发机或者你正准备把旧机器交出去那清理完本地缓存之后还有一步很重要退出 Copilot 账号并在 VSCode 设置里重新确认扩展状态。清掉的缓存数据只是本地痕迹账号层面的登录状态不会因为删文件而自动退出。共用设备场景下注销账号和清理本地数据要同时做才算真正完成了交接前的卫生工作。清理完之后我还会习惯性地重新搜一次磁盘确认没有遗漏的残留文件。Windows 和 macOS 的文件搜索工具都能快速做到这件事花不了多少时间但对隐私保护来说非常值得。说到底“快速清除 VSCode 中的 Copilot Chat 对话”这件事本身并不复杂。复杂的是搞清楚自己到底要清到什么程度只是受不了列表杂乱图形界面几个点击就能解决是界面失灵、遇到幽灵会话或者有隐私级别的需求那就必须落到本地缓存目录上。希望这篇记录能帮你把“眼睛看到的历史记录”和“磁盘上真实存在的数据”这两件事对上号下次清理时少走一点弯路。我在写这篇的过程中顺手做了一次彻底清理现在面板清爽多了——下周再攒出新的一屏历史时我应该已经养成了定时归档的习惯不会再让清理变成临时救火式的大工程。