codex-lark

codex-lark 是一个本地运行的飞书 / Lark 机器人桥接层，用来把 Codex 接到你的工作流里。

它把消息链路收敛成：

飞书消息 -> 本机 codex app-server -> 飞书回复

核心原则是：Codex 操作留在本地，飞书只负责消息交互。

GitHub 成果演示地址

https://github.com/prinmoce/codex-lark

快速开始

1. 克隆仓库并进入目录。
2. 安装依赖：npm install
3. 配置 .env，然后启动：npm run feishu-bot

如果你只想先看效果，可以先读 docs/public-summary.md 和下面的版本/历程说明。

原创性说明

这个仓库不是简单搬运现成项目，而是基于真实使用场景做出来的持续迭代成果。

我的工作重点不是“把代码拷贝过来”，而是把一个 Codex 桥接系统反复打磨成可长期使用、可验证、可展示的工程化项目。

具体做法包括：

• 用 Agent / AI 帮我拆解需求、定位问题、收敛方案
• 根据真实运行反馈重做消息展示规则
• 根据审批和线程卡死问题补恢复逻辑、取消逻辑和自动放行逻辑
• 把测试、版本说明和开发历程持续回写到仓库里
• 让每次改动都能解释“解决了什么问题、为什么这样改、怎么验证的”

项目定位

• 面向 Feishu / Lark 的本地桥接
• 支持线程绑定、线程切换、状态卡片、审批卡片、模型与推理强度管理
• 适合长期运行的个人开发者工作流
• 由 codex-im 演进而来，保留了其本地桥接思路，并在稳定性和交互体验上做了多轮修复

主要能力

• 飞书长连接机器人
• 普通对话回复
• 卡片回复与流式更新
• 线程绑定与切换
• /codex bind 绑定项目
• /codex where 查看当前项目 / 线程
• /codex workspace 查看当前会话已记录项目和线程
• /codex remove /绝对路径 移除会话绑定项目
• /codex send <相对文件路径> 发送当前绑定项目内的文件
• /codex switch <threadId> 切换线程
• /codex message 查看最近几轮消息
• /codex new 新建线程
• /codex stop 停止当前运行
• /codex model / /codex model update / /codex model <modelId> 管理模型
• /codex effort / /codex effort <low|medium|high|xhigh> 管理推理强度
• /codex approve / /codex reject 审批卡片

我的工作量与改进点

下面这些内容，来自我在真实对话和真实运行中一轮一轮推进出来的改进，不是空泛概念：

• 把普通回复和状态回复分层，避免每次输出都带一大串默认模型、推理、审批和 sandbox 信息
• 把 /codex where 做成专门的状态视图，只在需要时展示模型、effort、approval policy 和 sandbox
• 把最近对话、线程切换、历史消息的展示重新整理成更清楚的分段格式
• 去掉首行缩进，过滤系统噪音，只保留用户真正关心的内容
• 把线程切换后的展示缩成更短的上下文，避免消息过长、信息噪音太多
• 把审批链路从“占位回复”推进到能真正工作、能恢复、能停止、能自动放行的状态
• 增加工作区级 allowlist 和记忆自动审批，减少重复确认
• 修复 RPC 超时、进程重启、阻塞线程识别等稳定性问题
• 补回归测试，确保每轮改动都能验证

这些工作组合起来，体现的是我在真实项目里持续做工程化收敛的能力，而不是单次写一个 demo。

MiMo 接入计划

这是后续面向小米 MiMo 的明确计划，不是已经完成的功能。

• 2026-05-10 前完成 MiMo API 接入验证
• 2026-05-20 前发布 v0.4.0
• 在 v0.4.0 中补上 MiMo 相关配置入口、模型选择说明和接入验证记录
• 保持现有 Feishu / Lark 桥接能力不回退

如果申请阶段需要强调路线图，这一段可以直接放进说明里。

安装

npm install -g codex-lark
codex-lark feishu-bot

开发态运行：

npm install
npm run feishu-bot

配置

项目通过 .env、~/.codex-im/.env 和当前 shell 环境变量加载配置，支持本地运行。

必填环境变量：

• FEISHU_APP_ID
• FEISHU_APP_SECRET
• CODEX_IM_DEFAULT_CODEX_MODEL
• CODEX_IM_DEFAULT_CODEX_EFFORT
• CODEX_IM_DEFAULT_CODEX_ACCESS_MODE

可选环境变量：

• CODEX_IM_DEFAULT_WORKSPACE_ID
• CODEX_IM_FEISHU_STREAMING_OUTPUT
• CODEX_IM_WORKSPACE_ALLOWLIST
• CODEX_IM_CODEX_ENDPOINT
• CODEX_IM_SESSIONS_FILE

版本说明

0.3.0

• 将仓库正式改名为 codex-lark
• 保留 codex-im 的主代码基线，并以 codex-lark 作为发布名
• 重写 README、仓库元数据和发布说明
• 增加发布前的忽略规则，避免把运行日志、快照和本地配置直接提交到仓库
• 将历史对话里的真实改进工作整理为可对外展示的项目成果
• 增加 GitHub 成果演示地址、快速开始、MiMo 接入计划、AI 驱动构建成果和申请表描述

0.3.1

• README 增加 MiMo 接入计划、快速开始和申请导向说明
• 仓库元数据补充 MiMo / feishu-bot / ai-assistant / claude-code 相关标签
• 将展示版文案和实用版结构保持在同一份 README 内，便于后续切回实用项目

0.2.2

• 上游 codex-im 的稳定版本基础
• 已包含线程绑定、卡片交互、审批、RPC、工作区管理等核心能力

开发历程

第一阶段：消息展示先变清楚

我先处理的是“看起来乱”的问题，而不是盲目加功能：

• 普通回复不再尾随默认状态串
• /codex where 专门展示状态信息
• /codex message 只负责历史对话
• 切换线程、历史消息、普通聊天各自分工
• 对话格式改成分段排版，减少密度和噪音

这一步解决的是信息层次问题，让输出先能读。

第二阶段：审批链路补完整

随后把审批相关能力从占位状态推进到可用状态：

• 让 approval policy 真正生效
• 接通 approve / reject / stop
• 补工作区 allowlist 和记忆自动放行
• 做恢复执行、取消执行和阻塞识别
• 用测试覆盖审批闭环

这一步解决的是执行控制问题，让系统能在真实场景里继续跑。

第三阶段：线程与历史预览做稳

然后我继续压线程管理和历史显示：

• 缩减切换后的上下文
• 改良最近会话的展示格式
• 让历史记录更像“项目轨迹”而不是一堆原始消息
• 让卡片和命令回显更适合真实操作习惯

这一步解决的是操作连续性问题，让消息流不容易丢上下文。

第四阶段：稳定性与可恢复性

后面重点是运行时稳定性：

• 处理 RPC 超时
• 处理卡住时的恢复提示
• 处理进程重启与阻塞线程
• 保证出错后不是静默失败

这一步解决的是可靠性问题，让项目能长期使用。

第五阶段：AI 作为协作引擎

最后，我把 Agent / AI 变成持续协作工具：

• 用它做需求拆解
• 用它做文档整理
• 用它做回归测试和版本说明
• 用它做多轮重构的辅助

这一步的结果是：项目不只是“能跑”，而是能持续迭代、持续说明、持续展示。

AI 驱动构建成果

如果申请表要求填写“请描述你使用 Agent 或 AI 驱动构建的具体成果”，可以这样写：

我使用 Agent / AI 作为持续协作的构建伙伴，把一个本地 Codex 桥接系统从基础接入一步步推进到可长期维护的工程化项目。整个过程不是一次性生成代码，而是围绕真实运行问题做多轮迭代：先用 AI 梳理线程、审批、历史展示和状态回显的问题，再把消息格式、权限策略、自动放行、恢复执行、超时重启和回归测试逐项补齐，最后把这些改进沉淀成 README、版本说明和开发历程。最终成果不是演示样例，而是一套可验证、可复用、可持续维护的本地桥接系统。

可直接提交的申请表描述

我用 Agent / AI 持续驱动完成了一个本地 Codex 桥接系统的工程化迭代。项目最初关注的是消息接入和线程管理，随后逐步补齐了输出格式治理、系统噪音过滤、审批链路、工作区 allowlist、线程恢复、RPC 超时处理、阻塞线程识别和回归测试等能力。每一轮改动都来自真实运行中的问题，不是简单堆功能，而是先定位问题、再拆解方案、再用 AI 协助实现和验证，并把结果回写到 README、版本说明和开发历程中。这个成果体现的是持续构建、持续验证和持续优化的能力。

迁移说明

• 这个仓库由 codex-im 演进而来
• 公开仓库里不包含真实 .env、sessions.json、运行日志和脱敏前快照
• 如果你要排查问题，先看 docs/ 下的时间线和验证记录

参考

• 上游思路来源：codex-im
• 相关实现参考：Lark / Feishu 机器人、Codex 本地桥接、线程状态与审批流处理