DeepSeek 误操作导致整个浏览器数据丢失

Chrome 上装了Chrome DevTools MCP(Chromium 153.0.8010.53)，出了点问题导致没办法调用，想着这种问题应该可以让deepseek简单处理一下，就放权给4.1flash去做一段时间没管。

做到一半chrome直接崩了，再次重启发现所有用户凭证、会话、布局与登录态全部丢失。基本跟新的一样了，直接整懵。然后去翻了它的工具调用，发现它为了连接chrome做了这几件事

1. 创建目录联接：

C:\ChromeCDP → 原来的 Chrome\User Data

两个路径指向同一份真实数据。

2. 执行带 -Force 的启动脚本，关闭原来的 Chrome，再用以下参数启动：

–user-data-dir=“C:\ChromeCDP” --remote-debugging-port=9222

看到调试端口通了，deepseek认定成功，其实这个方法是错误的，官方readme写的很明白方法，但这时候登录态、加密数据和配置已经全毁了。

这个类似高版本谷歌的安全熔断机制，具体看这篇文章：

Chrome 136 起不允许通过这些参数调试默认用户目录，这是安全限制，也就是deepseek根本不搜也不知道正确的做法，自主操作撞上了谷歌的红线，触发重置机制。在此情况下：

• 
  

  非默认用户目录会让 App-Bound 加密密钥不可用。 即使 Local State 中保存的密钥完全没变，这次启动也不会提供它来解密。对应源码

  
  


• 
  

  Cookie 解密失败后，加载器存在删除相关域名组 Cookie 的处理路径，并不是仅仅“暂时显示未登录”。对应源码

  
  


• 
  

  受保护配置也使用加密校验，解密失败会被判为校验无效，并可能触发配置重置。对应源码

  
  

我让gpt查了一下Google这操作把chrome里的东西全清干净了，就保留了快照告诉你之前还有啥。

现状是部分数据可以通过Google的账号同步恢复（书签、密码箱、布局等等），但是也有些东西完全丢失了，比如所有网站的登录态以及cookie，没办法恢复了。

其实之前deepseek有几次简单的轻任务做的确实不错，但部分会话就会有以下表现：

• 
  

  一个小目标，但是把整个C盘、D盘或者整个工作目录全搜刮一遍，最后一行解决了。不知道在搜啥。

  
  


• 
  

  所有有搜索工具的TUI或者Agent上来不搜索，如果你不在prompt中告诉它能搜索，它永远不知道调用，遇到拿不准的直接开始在思维链中边猜边试，试对了还好，试不对经常卡思维链或者原地打转。

  
  

整体一种感觉真的是神鬼二相性，而且其实deepseek的api算是比较烧的，真的算是比较烧的，没有coding plan，其实月费已经有点接近一些能力比他好的模型的订阅费了。也确实没想到谷歌还有熔断机制，现在也在找数据的路上了.