从 Claude Code 通知到 Codex 飞书交互：本地 Agent 接入飞书的两条链路

最近我把两条看起来很像、实际上完全不同的飞书接入方式都跑了一遍：

• Claude Code Hook -> 飞书通知
• Codex + cc-connect -> 飞书内交互

它们都和“飞书接入 Agent”有关，但定位完全不同。

• 前者解决的是“任务结束了没有、是否需要我介入”
• 后者解决的是“我能不能直接在飞书里继续让本地 Agent 干活”

这篇文章目标只有三个：

1. 帮你快速判断自己到底该用哪一条路
2. 给出 Codex + cc-connect 这条线的最小可用接法
3. 把环境边界写清楚，避免 Linux 跑通的命令被误当成 Windows 可直接照抄

环境说明

• 下面这套完整截图和实际接入过程，最初是在 Linux 本地环境跑通的
• 我现在是在 Windows 环境里整理文章，没有重新做整套链路复测
• 所以本文里的路径、~/.claude、~/.cc-connect、chmod、tail -f、env -u 等写法都以 Bash/Linux 为准
• 如果你现在主要在 Windows 上使用 PowerShell、Git Bash 或 WSL，需要自己替换路径和 shell 命令

---

一、先把两条链路分开

1. Claude Code Hook：单向通知

如果你的诉求是下面这些事：

• 任务完成时提醒我
• 失败时提醒我
• 需要授权时提醒我
• 需要我补一句话时提醒我

那你要的是 通知链路，不是会话链路。

flowchart LR
    A[Claude Code] --> B[Hook 事件]
    B --> C[本地通知脚本]
    C --> D[飞书 Webhook]
    D --> E[飞书群 / 私聊]

这条路的特点是：

• 配置简单
• 适合关键节点提醒
• 飞书是结果终点
• 不能在飞书里继续接着聊

2. Codex + cc-connect：飞书内交互

如果你的诉求是下面这些事：

• 人不在电脑前，也想从飞书里继续安排任务
• 想在飞书里切会话、切目录、切模式
• 想把飞书当成本地 Agent 的远程入口

那你要的是 交互链路。

flowchart LR
    A[飞书机器人] <--> B[cc-connect 常驻进程]
    B <--> C[本地 Codex]
    C <--> D[项目目录]

这条路的特点是：

• 飞书不再只是通知终点
• 本地机器必须在线
• 需要一个常驻桥接进程
• 更适合远程协作和移动端入口

3. 怎么选

诉求	建议方案	原因
我只想知道任务做完没有	Claude Hook	单向通知就够了，结构最简单
我想在飞书里继续指挥本地 Agent	Codex + cc-connect	需要会话、目录、模式这些交互能力
我两者都要	两条链路分开上	通知和交互本来就不是一回事
我希望飞书替代本地终端	不建议这样理解	飞书只是入口，本地执行环境仍然是核心

---

二、如果你只要通知，直接用 Claude Hook

Claude Hook 这条线，我已经单独写过完整实战：

• Claude Code 任务完成通知实战：SSH 远程服务器与本地环境接入飞书机器人

那篇文章里已经把下面这些内容拆开讲清楚了：

• Stop、StopFailure、PermissionRequest、Elicitation 这些事件怎么用
• notify_feishu.py 的脚本思路
• settings.json 怎么挂 Hook
• SSH、代理、Windows 路径这些坑怎么排

这篇就不再把 Hook 教程整篇重写一遍，只保留一个判断：

如果你要的是“Claude 有结果了提醒我”，Hook 足够。
如果你要的是“我在飞书里还能继续发命令”，Hook 不够。

下面这张图就是通知链路的效果。它很好用，但它不是会话入口：

---

三、Codex + cc-connect 这条线真正解决什么

Codex + cc-connect 解决的是“远程交互入口”，不是“更高级的通知”。

你得到的是：

• 飞书里发一句话，可以驱动本地 Codex 工作
• 可以查看当前会话
• 可以切换会话
• 可以切换工作目录
• 可以调整执行模式

你得不到的是：

• 一台离线机器还能继续工作
• 终端里的旧对话自动无损搬到飞书
• 一套完全不依赖本地环境的云端 Agent

所以这条线最准确的理解是：

飞书只是入口，cc-connect 是桥，Codex 才是真正执行的人，本地机器仍然要保持在线。

---

四、开始前先确认前提

在动手之前，先确认这几件事：

1. 你的本地 codex 已经能正常运行
2. 你有一台会长期在线的 Linux 主机或本地开发机
3. 你有飞书企业自建应用的创建和发布权限
4. 你接受先按 Linux 命令跑通，再自己映射到 Windows

这里特别强调第四点。

当前这篇文章里的启动命令、目录结构、日志查看方式，都是按 Linux/Bash 写的。如果你现在在 Windows 上做这件事，原理不变，但下面这些东西都要自己替换：

• ~/.cc-connect/config.toml 的路径
• chmod、tail -f 这类命令
• 后台常驻进程的管理方式
• shell 环境变量写法

如果你现在的目标是“先把链路跑通”，仍然建议先在 Linux 侧完成一次端到端验证。

---

五、飞书侧的最小配置

1. 创建企业自建应用

先在飞书开放平台里创建一个企业自建应用。

名字你可以自己取，我这里当时用的是：

cc-connect-codex

接着启用机器人能力，并准备后面的权限和事件订阅。

2. 记录 App ID 和 App Secret

创建完应用后，先记下两项凭据：

• App ID
• App Secret

后面要写进 config.toml。

3. 打开机器人、权限和事件订阅

这一段最容易漏，建议一次性确认三件事：

1. 机器人能力已经启用
2. 消息接收、消息发送相关权限已经配置
3. 事件订阅使用的是 长连接

这里最关键的判断是：

cc-connect 接飞书，重点是长连接，不是公网 Webhook 回调。

也就是说，你不需要专门暴露一个公网回调地址给飞书，而是让本地桥接进程主动连出去。

4. 别忘了发布版本

很多人把前面都配好了，但机器人就是没反应，最后问题其实不是权限，而是应用版本根本没发布。

这一步一定要确认：

• 当前修改已经发布
• 机器人所在的目标范围可用

---

六、安装 Codex 和 cc-connect

先让本地 Codex 可用，再谈飞书接入。因为 cc-connect 只是桥接层，真正执行任务的是 Codex。

npm install -g @openai/codex
codex --version

然后再装 cc-connect：

npm install -g cc-connect
cc-connect --version

这里有两个边界要说明：

• codex 相关命令我在当前环境里核过帮助信息，codex resume、codex exec resume 这些写法和本机 CLI 是对得上的
• cc-connect 的字段和命令可能随版本调整，下面给的是我当时跑通这条链路时采用的最小结构，具体以你安装版本的帮助和示例为准

---

七、写一份最小 config.toml

下面这份配置重点不是“功能最全”，而是“先把链路跑通，便于排障”。

language = "zh"

[log]
level = "info"

[[projects]]
name = "codex-project"

[projects.agent]
type = "codex"

[projects.agent.options]
work_dir = "/home/your-user/projects/your-repo"
mode = "suggest"

[[projects.platforms]]
type = "feishu"

[projects.platforms.options]
app_id = "cli_xxxxxxxxxxxx"
app_secret = "xxxxxxxxxxxxxxxx"

这几个字段最重要：

• name：cc-connect 里的项目别名
• type = "codex"：表示后端执行者是 Codex
• work_dir：真正让 Agent 干活的目录
• mode = "suggest"：建议先从保守模式开始，先把权限边界和消息链路跑通
• app_id / app_secret：飞书应用凭据

为什么我建议先用 suggest：

• 权限更保守
• 排障时更容易判断问题在桥接层还是执行层
• 不容易在刚接好机器人时就触发高风险操作

如果你后面确认场景确实需要，再逐步放开权限，不要一上来就把整套流程建立在高权限模式上。

---

八、启动顺序不要反

建议按下面这个顺序启动：

1. 先确认本地 Codex 自己能工作
2. 再启动 cc-connect
3. 最后去飞书里发第一条命令

启动命令示例：

cc-connect -config ~/.cc-connect/config.toml

如果链路正常，日志里一般会看到类似这些关键信息：

• 配置文件已加载
• feishu 机器人已识别
• engine started
• cc-connect is running
• 成功连上飞书长连接

这里不要反过来做。

如果你先去飞书里戳机器人、再回头排查本地进程，大概率只会把问题范围越搞越大。先把本地桥接层跑起来，飞书侧验证会轻松很多。

---

九、飞书里最常用的几条命令

不同版本的 cc-connect 命令可能会有差异，但从日常使用看，下面这些是最值得先掌握的：

命令	作用
/current	查看当前会话
/list	查看当前项目的会话列表
/new [名称]	新建一个会话
/switch <id>	切换到指定会话
/dir	查看当前工作目录
/dir <路径>	切换工作目录
/mode	查看当前模式
/mode suggest	切回保守模式
/stop	停止当前执行

第一次进来，建议先做三步：

/current
/list
/new demo-session

这样你先确认三件事：

• 机器人能回消息
• 会话层已经工作
• 新会话创建逻辑正常

下面这张图里可以看到 /current 和 /list 的基本效果：

关于 /switch，本文只建议一种做法：

1. 先 /list
2. 看到会话 ID
3. 再 /switch <id>

不要默认“名称匹配”“前缀匹配”“摘要关键字匹配”一定可用，因为这些行为更容易受版本差异影响。

---

十、会话和上下文到底怎么理解

这部分是最容易被误解的地方。

1. Claude Hook 方案里没有飞书会话

在 Hook 链路里：

• Claude 的会话在本地
• 飞书只是接收通知
• 飞书不是上下文入口

也就是说，你在飞书里看到一条通知，不等于你能在那条消息下面继续把原来的任务接着做完。

2. cc-connect 方案里有桥接会话

在 Codex + cc-connect 里，至少有两层东西需要区分：

1. cc-connect 自己管理的桥接会话
2. Codex 本地执行时对应的实际上下文

对日常使用来说，你首先应该盯住第一层，也就是：

• 当前会话是谁
• 当前目录在哪
• 当前模式是什么

先把这三件事稳定住，你才谈得上“在飞书里继续工作”。

3. 不要默认终端旧对话会自动无缝接上

如果你之前一直在终端里和 Codex CLI 对话，现在想切到飞书继续，建议先按下面这个边界理解：

• Codex CLI 自己有会话恢复能力
• cc-connect 也有自己的桥接会话
• 但你不应该默认“我刚才在终端里开的那条对话”一定会自动原样出现在飞书里

如果你只是想在终端里继续旧任务，先用 Codex 自己的恢复能力确认它没问题：

codex resume --last
codex exec resume --last "继续刚才的任务"

如果你想把工作切到飞书里继续，我更建议这样做：

1. 先在终端确认旧会话本身还能恢复
2. 再启动 cc-connect
3. 在飞书里新建一个明确命名的会话
4. 把关键上下文重新补进去

例如：

/new mini-infer-followup

然后把这些信息补一段进去：

• 当前仓库或目录
• 当前分支
• 已完成到哪一步
• 下一步要继续做什么

这样做的好处是可控，而不是把整条链路建立在“希望它自动接上”这种不稳定预期上。

---

十一、常见问题怎么排

1. feishu: app_id and app_secret are required

优先检查三件事：

• config.toml 是否真的被加载到了
• projects.platforms.options 下面是否真的写了 app_id 和 app_secret
• 配置路径是否写错

2. 飞书里完全没有反应

优先排查顺序建议固定成这样：

1. cc-connect 是否正在运行
2. 飞书应用是否已经发布版本
3. 事件订阅是否用的是长连接
4. 机器人权限是否配齐
5. 本地 codex 是否本身可用

3. 私聊能用，群里没反应

这通常不是 Codex 的问题，优先看：

• 机器人是否已经被拉进群
• 群聊消息接收权限是否生效
• 群里触发范围和私聊触发范围是否一致

4. 机器人会回复，但总感觉上下文接不上

先不要急着怀疑模型。

先在飞书里做这三件事：

/current
/list
/dir

很多“上下文没接上”的问题，本质上不是模型忘了，而是：

• 你切到了另一个会话
• 当前目录不是你以为的那个仓库
• 你本来想续的是终端旧任务，但飞书里开的其实是新桥接会话

---

十二、我更推荐的落地顺序

如果你是第一次把飞书接到本地 Agent 上，我建议按这个顺序来：

1. 先把通知跑通

目标只有一个：

任务结束后，我在飞书里能收到消息。

这样你先解决“人不在终端前，不知道任务跑到哪了”的问题。

2. 再把交互跑通

目标也只有一个：

我在飞书里发一句话，机器人能把结果回给我。

先不要一上来就追多项目、多机器人、多群聊协作，先把单项目、单目录、单会话跑顺。

3. 最后再做会话和目录管理

等最小链路稳定后，再去做这些事：

• 给不同仓库拆不同项目配置
• 用 /new 给任务分会话
• 用 /dir 在多个仓库间切换
• 用 /mode 管理权限边界

这三步分开做，出问题时会清楚很多。

---

结语

把飞书接到本地 Agent 上，最容易混淆的不是命令本身，而是目标本身。

你到底要的是：

• 通知
• 还是 交互

如果只是通知，Claude Hook 已经足够直接。

如果要把飞书变成一个真正的远程入口，那就走 Codex + cc-connect，但要接受它依然依赖本地机器、依赖本地目录、依赖本地执行环境这个事实。

把这个边界先想清楚，后面的配置反而不难。