不敢用了，害怕

[qiaojiedongfeng]

上周五用了一下，然后周一的时候，和朋友还在聊微信，聊着聊着，直接提示退出，手机上的也退了，让学习，我去，微信号要是没了，那人要疯掉。

[endearqb]

我也遇到了，也是周五用的，也是刚刚直接提示退出，先清理安装使用记录再说

[cc-demonlx]

吓得我立马把程序停了

[qiaojiedongfeng]

看来遇到问题的不止我一个

[jackwener]

按描述时间线（周五用 wx-cli，周一聊天时被退出），事件和 wx-cli 没有直接相关性。wx-cli 是 read-only 工具，只读本地 SQLCipher 文件，不向微信服务器发任何请求；登录态本身不会被 wx-cli 主动失效。微信退出 / 风控原因很多（多设备登录、异地、行为模式等），无法和一次本地数据库读取建立因果关系。

如果有可复现的"执行 wx-cli 某命令 → 立即触发微信退出"路径，欢迎单独开新 issue 给出具体步骤。

[jackwener]

更正：上一条 close 评语口径不对。

微信风控算法在 4.x 系列上确实趋严，wx-cli init 阶段需要 attach 到 WeChat 进程读内存（macOS task_for_pid / Linux ptrace / Windows OpenProcess+ReadProcessMemory），这种 process-attach 行为微信侧是有能力检测到的，被风控 / 触发安全验证 / 短期封号的风险真实存在，并且不是只在执行 wx-cli 的同一时刻才会触发——可能存在延迟触发或基于"近期是否有可疑进程行为"的累计判定。

建议：

• 用辅助小号或不重要的微信账号试用
• 完成 wx init 后立即 wx daemon stop，不要常驻
• 看到任何安全验证 / 异常退出弹窗，立刻停掉 wx-cli 后续操作

Re-open 以便其他用户能看到这条警示。

[astrodooog]

周六用了一次，昨天碰到了一样的问题，吓得卸载了😂

[Dangooy]

我昨天也遇到了这个问题，提醒我违反微信使用规范。

[byan]

更正：上一条 close 评语口径不对。

微信风控算法在 4.x 系列上确实趋严，wx-cli init 阶段需要 attach 到 WeChat 进程读内存（macOS task_for_pid / Linux ptrace / Windows OpenProcess+ReadProcessMemory），这种 process-attach 行为微信侧是有能力检测到的，被风控 / 触发安全验证 / 短期封号的风险真实存在，并且不是只在执行 wx-cli 的同一时刻才会触发——可能存在延迟触发或基于"近期是否有可疑进程行为"的累计判定。

建议：

• 用辅助小号或不重要的微信账号试用
• 完成 wx init 后立即 wx daemon stop，不要常驻
• 看到任何安全验证 / 异常退出弹窗，立刻停掉 wx-cli 后续操作

Re-open 以便其他用户能看到这条警示。

建议 wx init 获取到 key 立即退出，除非另有参数明确指定以 daemon 方式继续运行。

[cy1k]

看起来，只读的风险是比较低的。目前只读取信息。也不会用到daemon 方式

[jackwener]

补一条更精确的风险说明，避免把风险点说偏：

当前实现里，不存在一个“持续常驻、反复扫描微信内存”的进程。

现在的代码路径是：

• 真正会 attach 到 WeChat 进程、读取内存里 key 的主路径，发生在 wx init
• wx init 扫完以后就把 key 落到 all_keys.json，进程随后退出
• 后续常驻的是 wx-daemon，它主要负责复用 / 缓存已解密数据库并响应查询，不会像 scanner 那样持续循环扫微信内存

所以如果说“风险在哪里”，更准确的说法是：

1. 风险主要集中在 wx init 这一步的 process-attach 行为本身

   • macOS: task_for_pid + mach_vm_read
   • Linux: ptrace / /proc/<pid>/mem
   • Windows: OpenProcess + ReadProcessMemory
     这种 attach 到微信进程、读取内存的行为，微信侧理论上有能力感知；如果会触发风控，核心风险在这里。

2. macOS 默认 invasive 路径还有额外风险：需要 ad-hoc 重签名 /Applications/WeChat.app
   这会改变 WeChat 的 code identity。我们前面已经确认过，它会带来系统权限弹窗和 TCC 相关副作用；如果从“异常行为特征”角度看，这也比 daemon 常驻更值得警惕。

3. wx-daemon 常驻 != 持续扫内存，但 Windows 图片附件解密是一个例外 surface

   • daemon 常驻带来的主要是本地侧风险：机器上保留了解密缓存、socket、日志等
   • 但在 Windows + 图片附件解密 场景下，daemon 首次解密 V2 图片附件时，会通过 WindowsImageKeyProvider attach 一次 WeChat 进程去取 image key（有 per-wxid cache，所以不是持续循环 attach）
   • 也就是说，“daemon 永远不会 attach 微信进程”这句话并不严格成立；更准确的说法是：它不是持续扫描，但某些功能路径下仍可能按需 attach 一次

也就是说，之前那句“wx init 后立刻 wx daemon stop，不要常驻”并不准确。stop daemon 最多只能减少本地残留面，不能改变你已经执行过 wx init attach 微信进程这件事；但如果你在 Windows 上继续用图片附件解密，daemon 后续也仍可能触发一次 attach。

如果你的重点是规避微信风控风险，当前更保守的建议应该是：

• 不要在主号上直接跑 wx init
• 如果必须试，优先用不重要账号 / 测试号
• macOS 上尤其要把“重签 WeChat.app”视为高风险动作
• Windows 上如果你还要用图片附件解密，也要把那条按需 attach 算进风险面
• 不要再把“daemon 停不停”误当成唯一或核心风险开关

后续如果做 hardening，正确方向也不是“把 scanner 继续常驻”，而是反过来：

• 让 memory scan 显式收敛成一次性 helper
• 把 Windows 图片 image-key 这条 attach 也外提成一次性 helper
• 尽量让 daemon 在结构上不直接具备 attach WeChat 进程的能力

这条不是在否认 issue 里的风险；相反，是把风险点说准：主风险在 init attach / 重签路径，另有 Windows 图片附件解密的按需 attach 例外，不在所谓“daemon 持续扫内存”。

[endearqb]

我的感觉是因为宝玉用这个作为依赖，做了一个skill让微信重视这个事情了，然后说不定是扫描了一下用户目录，用了没那么正常的手段。

[lzkkai]

可以通过降低微信版本来解决吗

[LittleNightmare]

我卸载wx cli后又被微信封了
怀疑微信现在检测生成的那个文件夹，我现在移走没改名看看后续会不会封，或许是我卸载的有问题

是卸载的问题，我没卸载掉