English | 简体中文

这份文档单独说明三件事：法律意义上的免责声明、装这个工具实际会给你的系统带来哪些 风险（用 Q&A 形式，尽量讲得通俗，不说套话），以及你的数据到底去了哪里。内容基于对 当前代码的实际检查（依赖清单、有没有遥测代码、有没有硬编码的外部上报地址）， 不是照抄一份通用免责声明模板。

CC-Monitor 是一个个人维护的开源项目，按 MIT 协议"现状"提供，不附带 任何明示或暗示的担保——包括但不限于对特定用途的适用性、无错误运行、或者规则库 能拦住所有危险操作的担保。

具体来说：

• 策略引擎是近似识别，不是形式化证明。全部规则本质上是正则表达式匹配命令 文本/文件路径/写入内容，见 DESIGN.md "策略引擎"那一节里反复 强调的"非精确"——总能找到没被规则覆盖的写法 绕过去，也总能找到被规则误判的正常操作。不要把它当成唯一的防线，尤其是 在处理你确实不信任的代码/仓库时，该有的其它防护（容器隔离、只读挂载、专用 沙箱账号）不能省。
• 系统层探针目前只做审计，不做强制隔离。CC-Monitor-probe 能看到、能记录 应用层 hook 被绕过的迹象，但看到之后并不会自动阻止——Landlock/沙箱化这类 真正的强制隔离方案还在 DESIGN.md 第 5 节的路线图 里，属于"未实现"。
• 作者不对因使用/误用本工具造成的任何直接或间接损失负责（包括但不限于： 规则误拦截导致的工作中断、规则漏检导致的安全事件、系统层探针权限问题导致的 异常、或者你自己修改规则/代码引入的问题）。风险自负，用之前建议先在非生产 环境跑一遍、看懂 cc_monitor/default_rules.json 里默认规则都在拦什么。

主要有三类需要注意的地方，都不是"装了就崩"，但值得心里有数：

• 跟其它 Claude Code hooks 工具的叠加：Claude Code 的 PreToolUse/PostToolUse hook 机制本身允许同一个事件下注册多个 hook，按顺序执行。如果你的 ~/.claude/settings.json 或项目 .claude/settings.json 里已经装了别的 hook 类工具，CC-Monitor 的 hook 会跟它们排队执行，不会互相覆盖，但每多一个 hook 就多一次进程启动的延迟——正常情况下单次 hook 执行是毫秒级，但如果另一个 hook 本身很慢或者卡住，会拖慢整个工具调用链（这是 hooks 机制本身的固有特性， 不是 CC-Monitor 独有的问题）。
• 运行身份不一致：Web UI 读的是启动它那个系统用户的 ~/.cc-monitor/events.db。 如果你平时跑 claude 命令用的是普通用户，却用 sudo/root 启动 Web UI，两边 各写各的数据库目录，Web UI 会显示"看不到任何数据"——界面里已经有提示，不是 bug，是运行身份没对上。
• 端口占用：Web UI 默认监听一个本机端口（详见 README 的启动说明），如果 这个端口已经被别的程序占用，服务会启动失败，需要换端口。

会真正拦截/放行危险操作的那条核心链路（Python 写的 hooks 脚本 + 策略引擎 cc_monitor/policy.py）零第三方依赖，只用 Python 标准库 （json/os/re/pathlib/sqlite3/subprocess 等）。这是刻意的设计 选择——这一层直接决定"要不要放行 Claude Code 的这次操作"，依赖越少，供应链 攻击面越小。

可选的 Web UI（Node.js）不是零依赖，webui/package.json 里列了 9 个运行时 依赖：

再加上仅打包 Electron 桌面版才需要的 3 个开发依赖（electron、 electron-builder、@electron/rebuild）——纯 Web UI 模式完全用不到它们。

这些包各自还有自己的间接依赖树（node_modules 展开后远不止 9 个包），任何一环 被投毒理论上都可能影响到跑在你机器上的这个 Node 进程——这跟几乎所有用 npm 生态的项目面临的风险是同一个量级，不是 CC-Monitor 特有的，但你应该知情。 如果你对 Node 生态的供应链风险特别敏感，可以完全不装/不跑 Web UI，只用 Python 那层（hooks 自动生效 + CC-Monitor tail/CC-Monitor rules/ CC-Monitor stats 这几个零依赖的 CLI 命令），照样能拦截、照样能看审计日志， 只是没有网页可视化界面。

分两层说：

• 应用层 hooks：每次 Claude Code 调用工具前后都会同步跑一次 hook 脚本 （启动 Python 进程 + 正则匹配 + 写 SQLite），单次开销通常在几十毫秒量级。 如果 hook 脚本本身抛异常或者卡死，理论上会拖慢甚至卡住 Claude Code 当次 的工具调用——这是所有基于 hooks 机制的工具共有的权衡，装得越多风险越叠加。
• 系统层探针（CC-Monitor-probe，Linux 用 bpftrace/eBPF，macOS 用系统 自带的 nettop）：只读观测，不修改内核状态——挂 tracepoint 看 execve/connect 系统调用，不拦截、不注入。Linux 上需要 root 权限（ CAP_BPF/CAP_PERFMON）才能加载 eBPF 程序，理论上跟内核版本、跟其它同时 运行的 eBPF 程序存在兼容性问题的可能性，但探针从不会被安装脚本自动启动 ——install.sh/install.py 全程不执行 sudo，探针需要你自己手动 sudo ./bin/CC-Monitor-probe 才会跑起来，装了这个工具本身不会自动要 root 权限、不会自动改动内核参数。macOS 上的 nettop 网络探针完全不需要 root。

不会。Web UI 默认只绑定 127.0.0.1（仅本机可访问），管理员需要显式设置 CC_MONITOR_WEBUI_HOST=0.0.0.0 才会监听所有网卡——这个开关默认关闭，界面里 也有醒目提示。但要注意：Web UI 的终端会话功能（能直接开 shell）目前没有 身份验证机制，默认绑定本机这件事本身就是唯一的访问控制。如果你出于 远程访问的需要把它开放到 0.0.0.0，等于把一个无验证的 shell 入口暴露给能 连到这台机器的所有人，务必自己在前面加反向代理 + 认证，不要裸奔。

一句话总结：全部数据留在你自己的机器上，代码里没有任何上报/遥测逻辑。 这不是一句公关话术，是可以直接验证的——具体依据：

• 审计数据落地在哪：~/.cc-monitor/events.db，一个本地 SQLite 文件。 Web UI 读写的也是同一个文件，没有任何"先传到云端再展示"的中间环节。
• 代码里搜不到任何遥测/统计上报逻辑：搜过 analytics/telemetry/ sentry/mixpanel/amplitude/posthog/track( 这些常见埋点关键字， 在 webui/ 和 cc_monitor/ 全部代码里零命中。
• 代码里搜不到陌生的硬编码外部地址：搜过整个代码库里出现的 http(s):// 地址，命中的只有 GitHub（安装时下载 GeoIP 数据库这一次性 操作、README 里的链接）和 Anthropic（Claude Code 本身访问，不是 CC-Monitor 主动发起的）——没有任何指向陌生第三方服务器的地址，没有"打电话 回家"上报数据的代码路径。
• IP 归属地查询是本地查表，不联网：世界地图、网络流量页显示的"某个 IP 属于哪个城市"，查的是安装时下载到本地的 GeoIP 数据库文件（DB-IP Lite 数据，通过 sapics/ip-location-db 项目分发）， 每次查询都是本地文件读取，不会把你访问过的 IP 发给任何第三方服务去查。
• Anthropic 账号信息（姓名/邮箱/套餐/额度）直接读 Claude Code 自己维护 的本地配置文件 ~/.claude.json，同样零网络请求。

需要你自己权衡的例外情况：

• 如果你开启了"持久化归档"功能，审计数据依然只是换了个本地文件位置，不涉及 网络传输。
• 如果你自己配置了反向代理/异地转发把日志同步到别的机器，那是你自己接的线， 不是 CC-Monitor 内置的行为。
• Web UI 里查看到的实时数据（额度、模型使用统计等）本身来自 Claude Code 官方 客户端跟 Anthropic 服务器的正常通信，CC-Monitor 只是读取本地已经落盘的数据 展示出来，没有额外发起请求。

有其它想核实的具体问题（比如某条规则到底匹配什么、某个依赖包具体做什么）， 欢迎直接翻源码——这份说明本身就是从翻源码得到的结论，不是营销话术。