【开源自荐】让 Codex Desktop 也能用 Claude Desktop Buddy 审批硬件
- 内容介绍
- 文章标签
- 相关推荐
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
-
我的帖子已经打上 开源推广 标签： 是
-
我的开源项目完整开源，无未开源部分： 是
-
我的开源项目已链接认可 LINUX DO 社区： 是
-
我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
-
以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
本项目是基于Claude官方出的BLE api 衍生固件的 Codex 兼容版本，支持原项目的固件【M5StickC/M5StickS3】(理论上支持任何ESP32固件)。
是什么：macOS 上一个小 daemon。Codex 触发 PermissionRequest hook 时把审批信息推到 buddy 屏幕上，按 A 是 allow、B 是 deny，决策从 hook stdout 回到 Codex。固件零改动 ------ 同一台 Claude-… 设备，原来给 Claude 用的，现在两边轮流用。
image872×1126 139 KB
image872×1126 134 KB
桌上有台 M5StickS3 跑着 anthropics/claude-desktop-buddy 的固件，Claude Code 让我审批 rm -rf 时按个 A/B 就完事。Codex Desktop 4 月更新带了 stable hooks 之后我就一直想：能不能让 Codex 的审批也走这台硬件？
折腾完了，路子感觉可行。
image1164×1324 175 KB
image1920×857 232 KB
开源在这里：
GitHub - Yamiqu/codex-buddy-bridge
通过在 GitHub 上创建帐户来为 Yamiqu/codex-buddy-bridge 开发做出贡献。
踩过的两个坑
第一个：UI 抓取行不通。 最初的方案是用 macOS Accessibility（osascript）爬 Codex Desktop 的 UI 文本，靠正则 match “approve / allow / deny” 关键字然后模拟点击 Codex 的按钮。完全没反应 ------ Codex 的审批弹窗大概率是 SwiftUI 自定义 view，AppleScript 抓不到 button name。
转折点是发现 Codex 在 2026-04 GA 的 hooks 框架里有个 PermissionRequest 事件（文档：https://developers.openai.com/codex/hooks ）。“弹审批之前先 fork-exec 你的命令、把审批 JSON 喂进 stdin、你 stdout 写决策 JSON” ------ 这是官方接入点，同步阻塞、默认 600s 超时，远比 UI 抓取干净。
第二个：BLE 是 1:1。 ESP32 BLE peripheral 一次只能被一个 central 连接，连上之后停止广播。第一版 daemon 抄了 Claude Desktop 的设计，持续连着 BLE 推 heartbeat。结果就是 Claude Hardware Buddy 那边整个找不到设备了，扫描扫不到，偶尔扫到了 connect 立刻被踢。基本 = 我把主功能搞坏了。
最后改成按需 BLE：daemon 平时只挂 Unix socket 当 IPC server，完全不碰蓝牙。Codex 触发审批的瞬间才连 BLE → 推 prompt → 等按键 → 断开。整个流程 3-5 秒。Claude 那边大部分时间都在用 buddy，互不影响。
如果审批触发时 Claude 正占着设备，daemon 8 秒连不上 → hook 退出无 stdout → Codex 自动 fallback 到原生审批弹窗，不会卡死。这是设计好的兜底。
食用方式
需要：macOS、一台跑着 anthropics/claude-desktop-buddy 固件的 BLE 设备、Codex 4 月版本或更新。
git clone https://github.com/Yamiqu/codex-buddy-bridge.git
cd codex-buddy-bridge
./install.sh
会做这几件事：建 venv 装 bleak、写 launchd plist 启动 daemon、把 [features] codex_hooks = true 加进 ~/.codex/config.toml、把 PermissionRequest hook 配置写进 ~/.codex/hooks.json。装完之后重启 Codex Desktop / Codex CLI session 让它重新加载 hook 配置。
第一次 Codex 触发审批时 macOS 会弹蓝牙权限对话框，target 是 venv 里的 python3，同意一次以后 launchd 启动的进程会继承这个权限。
附带一个 codex-buddy CLI：
codex-buddy status 看 daemon 状态 + 末尾 10 行日志
codex-buddy on / off 一键启停 daemon（off 立即释放 BLE 给 Claude）
codex-buddy log tail -F 日志
codex-buddy probe 扫一圈 BLE 看周围有什么，调试用
codex-buddy foreground 前台 --debug 跑，Ctrl+C 真的能退
不能做什么
平时不显示 Codex idle / working 状态。因为 daemon 闲时不占 BLE，没法在 buddy 屏上画 heartbeat ------ 这是和 Claude 共存必须付的代价。
仅 macOS。daemon 依赖 launchd 和 Unix socket，Linux 加个 systemd-user unit 应该不难，欢迎 PR。Windows 没测，hook 那部分理论上能跑，daemon 部分得重写 launchd 那块。
其它
协议照 anthropics/claude-desktop-buddy 的 REFERENCE.md 严格实现，没有任何固件 fork，同一台 buddy 给两边用。19 个单测，重点覆盖 hook payload 转 BLE 帧、firmware 40 字节 promptId 截断的回归（前期被这个坑过 ------ buddy 把我发的 51 字符 id 截到 39 然后 daemon 匹配不上，UUID 当 id 不行）、各种 timeout 路径。
整个降级链路也都验证过：daemon down、BLE 抢不到、buddy 不按键 ------ hook 都退 0 不写 stdout，Codex 走原生 UI。所以即便这个桥挂了也不会让 Codex 难受。
欢迎佬们食用。
网友解答：--【壹】--：
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
-
我的帖子已经打上 开源推广 标签： 是
-
我的开源项目完整开源，无未开源部分： 是
-
我的开源项目已链接认可 LINUX DO 社区： 是
-
我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
-
以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
本项目是基于Claude官方出的BLE api 衍生固件的 Codex 兼容版本，支持原项目的固件【M5StickC/M5StickS3】(理论上支持任何ESP32固件)。
是什么：macOS 上一个小 daemon。Codex 触发 PermissionRequest hook 时把审批信息推到 buddy 屏幕上，按 A 是 allow、B 是 deny，决策从 hook stdout 回到 Codex。固件零改动 ------ 同一台 Claude-… 设备，原来给 Claude 用的，现在两边轮流用。
image872×1126 139 KB
image872×1126 134 KB
桌上有台 M5StickS3 跑着 anthropics/claude-desktop-buddy 的固件，Claude Code 让我审批 rm -rf 时按个 A/B 就完事。Codex Desktop 4 月更新带了 stable hooks 之后我就一直想：能不能让 Codex 的审批也走这台硬件？
折腾完了，路子感觉可行。
image1164×1324 175 KB
image1920×857 232 KB
开源在这里：
GitHub - Yamiqu/codex-buddy-bridge
通过在 GitHub 上创建帐户来为 Yamiqu/codex-buddy-bridge 开发做出贡献。
踩过的两个坑
第一个：UI 抓取行不通。 最初的方案是用 macOS Accessibility（osascript）爬 Codex Desktop 的 UI 文本，靠正则 match “approve / allow / deny” 关键字然后模拟点击 Codex 的按钮。完全没反应 ------ Codex 的审批弹窗大概率是 SwiftUI 自定义 view，AppleScript 抓不到 button name。
转折点是发现 Codex 在 2026-04 GA 的 hooks 框架里有个 PermissionRequest 事件（文档：https://developers.openai.com/codex/hooks ）。“弹审批之前先 fork-exec 你的命令、把审批 JSON 喂进 stdin、你 stdout 写决策 JSON” ------ 这是官方接入点，同步阻塞、默认 600s 超时，远比 UI 抓取干净。
第二个：BLE 是 1:1。 ESP32 BLE peripheral 一次只能被一个 central 连接，连上之后停止广播。第一版 daemon 抄了 Claude Desktop 的设计，持续连着 BLE 推 heartbeat。结果就是 Claude Hardware Buddy 那边整个找不到设备了，扫描扫不到，偶尔扫到了 connect 立刻被踢。基本 = 我把主功能搞坏了。
最后改成按需 BLE：daemon 平时只挂 Unix socket 当 IPC server，完全不碰蓝牙。Codex 触发审批的瞬间才连 BLE → 推 prompt → 等按键 → 断开。整个流程 3-5 秒。Claude 那边大部分时间都在用 buddy，互不影响。
如果审批触发时 Claude 正占着设备，daemon 8 秒连不上 → hook 退出无 stdout → Codex 自动 fallback 到原生审批弹窗，不会卡死。这是设计好的兜底。
食用方式
需要：macOS、一台跑着 anthropics/claude-desktop-buddy 固件的 BLE 设备、Codex 4 月版本或更新。
git clone https://github.com/Yamiqu/codex-buddy-bridge.git
cd codex-buddy-bridge
./install.sh
会做这几件事：建 venv 装 bleak、写 launchd plist 启动 daemon、把 [features] codex_hooks = true 加进 ~/.codex/config.toml、把 PermissionRequest hook 配置写进 ~/.codex/hooks.json。装完之后重启 Codex Desktop / Codex CLI session 让它重新加载 hook 配置。
第一次 Codex 触发审批时 macOS 会弹蓝牙权限对话框，target 是 venv 里的 python3，同意一次以后 launchd 启动的进程会继承这个权限。
附带一个 codex-buddy CLI：
codex-buddy status 看 daemon 状态 + 末尾 10 行日志
codex-buddy on / off 一键启停 daemon（off 立即释放 BLE 给 Claude）
codex-buddy log tail -F 日志
codex-buddy probe 扫一圈 BLE 看周围有什么，调试用
codex-buddy foreground 前台 --debug 跑，Ctrl+C 真的能退
不能做什么
平时不显示 Codex idle / working 状态。因为 daemon 闲时不占 BLE，没法在 buddy 屏上画 heartbeat ------ 这是和 Claude 共存必须付的代价。
仅 macOS。daemon 依赖 launchd 和 Unix socket，Linux 加个 systemd-user unit 应该不难，欢迎 PR。Windows 没测，hook 那部分理论上能跑，daemon 部分得重写 launchd 那块。
其它
协议照 anthropics/claude-desktop-buddy 的 REFERENCE.md 严格实现，没有任何固件 fork，同一台 buddy 给两边用。19 个单测，重点覆盖 hook payload 转 BLE 帧、firmware 40 字节 promptId 截断的回归（前期被这个坑过 ------ buddy 把我发的 51 字符 id 截到 39 然后 daemon 匹配不上，UUID 当 id 不行）、各种 timeout 路径。
整个降级链路也都验证过：daemon down、BLE 抢不到、buddy 不按键 ------ hook 都退 0 不写 stdout，Codex 走原生 UI。所以即便这个桥挂了也不会让 Codex 难受。
欢迎佬们食用。
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
-
我的帖子已经打上 开源推广 标签： 是
-
我的开源项目完整开源，无未开源部分： 是
-
我的开源项目已链接认可 LINUX DO 社区： 是
-
我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
-
以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
本项目是基于Claude官方出的BLE api 衍生固件的 Codex 兼容版本，支持原项目的固件【M5StickC/M5StickS3】(理论上支持任何ESP32固件)。
是什么：macOS 上一个小 daemon。Codex 触发 PermissionRequest hook 时把审批信息推到 buddy 屏幕上，按 A 是 allow、B 是 deny，决策从 hook stdout 回到 Codex。固件零改动 ------ 同一台 Claude-… 设备，原来给 Claude 用的，现在两边轮流用。
image872×1126 139 KB
image872×1126 134 KB
桌上有台 M5StickS3 跑着 anthropics/claude-desktop-buddy 的固件，Claude Code 让我审批 rm -rf 时按个 A/B 就完事。Codex Desktop 4 月更新带了 stable hooks 之后我就一直想：能不能让 Codex 的审批也走这台硬件？
折腾完了，路子感觉可行。
image1164×1324 175 KB
image1920×857 232 KB
开源在这里：
GitHub - Yamiqu/codex-buddy-bridge
通过在 GitHub 上创建帐户来为 Yamiqu/codex-buddy-bridge 开发做出贡献。
踩过的两个坑
第一个：UI 抓取行不通。 最初的方案是用 macOS Accessibility（osascript）爬 Codex Desktop 的 UI 文本，靠正则 match “approve / allow / deny” 关键字然后模拟点击 Codex 的按钮。完全没反应 ------ Codex 的审批弹窗大概率是 SwiftUI 自定义 view，AppleScript 抓不到 button name。
转折点是发现 Codex 在 2026-04 GA 的 hooks 框架里有个 PermissionRequest 事件（文档：https://developers.openai.com/codex/hooks ）。“弹审批之前先 fork-exec 你的命令、把审批 JSON 喂进 stdin、你 stdout 写决策 JSON” ------ 这是官方接入点，同步阻塞、默认 600s 超时，远比 UI 抓取干净。
第二个：BLE 是 1:1。 ESP32 BLE peripheral 一次只能被一个 central 连接，连上之后停止广播。第一版 daemon 抄了 Claude Desktop 的设计，持续连着 BLE 推 heartbeat。结果就是 Claude Hardware Buddy 那边整个找不到设备了，扫描扫不到，偶尔扫到了 connect 立刻被踢。基本 = 我把主功能搞坏了。
最后改成按需 BLE：daemon 平时只挂 Unix socket 当 IPC server，完全不碰蓝牙。Codex 触发审批的瞬间才连 BLE → 推 prompt → 等按键 → 断开。整个流程 3-5 秒。Claude 那边大部分时间都在用 buddy，互不影响。
如果审批触发时 Claude 正占着设备，daemon 8 秒连不上 → hook 退出无 stdout → Codex 自动 fallback 到原生审批弹窗，不会卡死。这是设计好的兜底。
食用方式
需要：macOS、一台跑着 anthropics/claude-desktop-buddy 固件的 BLE 设备、Codex 4 月版本或更新。
git clone https://github.com/Yamiqu/codex-buddy-bridge.git
cd codex-buddy-bridge
./install.sh
会做这几件事：建 venv 装 bleak、写 launchd plist 启动 daemon、把 [features] codex_hooks = true 加进 ~/.codex/config.toml、把 PermissionRequest hook 配置写进 ~/.codex/hooks.json。装完之后重启 Codex Desktop / Codex CLI session 让它重新加载 hook 配置。
第一次 Codex 触发审批时 macOS 会弹蓝牙权限对话框，target 是 venv 里的 python3，同意一次以后 launchd 启动的进程会继承这个权限。
附带一个 codex-buddy CLI：
codex-buddy status 看 daemon 状态 + 末尾 10 行日志
codex-buddy on / off 一键启停 daemon（off 立即释放 BLE 给 Claude）
codex-buddy log tail -F 日志
codex-buddy probe 扫一圈 BLE 看周围有什么，调试用
codex-buddy foreground 前台 --debug 跑，Ctrl+C 真的能退
不能做什么
平时不显示 Codex idle / working 状态。因为 daemon 闲时不占 BLE，没法在 buddy 屏上画 heartbeat ------ 这是和 Claude 共存必须付的代价。
仅 macOS。daemon 依赖 launchd 和 Unix socket，Linux 加个 systemd-user unit 应该不难，欢迎 PR。Windows 没测，hook 那部分理论上能跑，daemon 部分得重写 launchd 那块。
其它
协议照 anthropics/claude-desktop-buddy 的 REFERENCE.md 严格实现，没有任何固件 fork，同一台 buddy 给两边用。19 个单测，重点覆盖 hook payload 转 BLE 帧、firmware 40 字节 promptId 截断的回归（前期被这个坑过 ------ buddy 把我发的 51 字符 id 截到 39 然后 daemon 匹配不上，UUID 当 id 不行）、各种 timeout 路径。
整个降级链路也都验证过：daemon down、BLE 抢不到、buddy 不按键 ------ hook 都退 0 不写 stdout，Codex 走原生 UI。所以即便这个桥挂了也不会让 Codex 难受。
欢迎佬们食用。
网友解答：--【壹】--：
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
-
我的帖子已经打上 开源推广 标签： 是
-
我的开源项目完整开源，无未开源部分： 是
-
我的开源项目已链接认可 LINUX DO 社区： 是
-
我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
-
以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
本项目是基于Claude官方出的BLE api 衍生固件的 Codex 兼容版本，支持原项目的固件【M5StickC/M5StickS3】(理论上支持任何ESP32固件)。
是什么：macOS 上一个小 daemon。Codex 触发 PermissionRequest hook 时把审批信息推到 buddy 屏幕上，按 A 是 allow、B 是 deny，决策从 hook stdout 回到 Codex。固件零改动 ------ 同一台 Claude-… 设备，原来给 Claude 用的，现在两边轮流用。
image872×1126 139 KB
image872×1126 134 KB
桌上有台 M5StickS3 跑着 anthropics/claude-desktop-buddy 的固件，Claude Code 让我审批 rm -rf 时按个 A/B 就完事。Codex Desktop 4 月更新带了 stable hooks 之后我就一直想：能不能让 Codex 的审批也走这台硬件？
折腾完了，路子感觉可行。
image1164×1324 175 KB
image1920×857 232 KB
开源在这里：
GitHub - Yamiqu/codex-buddy-bridge
通过在 GitHub 上创建帐户来为 Yamiqu/codex-buddy-bridge 开发做出贡献。
踩过的两个坑
第一个：UI 抓取行不通。 最初的方案是用 macOS Accessibility（osascript）爬 Codex Desktop 的 UI 文本，靠正则 match “approve / allow / deny” 关键字然后模拟点击 Codex 的按钮。完全没反应 ------ Codex 的审批弹窗大概率是 SwiftUI 自定义 view，AppleScript 抓不到 button name。
转折点是发现 Codex 在 2026-04 GA 的 hooks 框架里有个 PermissionRequest 事件（文档：https://developers.openai.com/codex/hooks ）。“弹审批之前先 fork-exec 你的命令、把审批 JSON 喂进 stdin、你 stdout 写决策 JSON” ------ 这是官方接入点，同步阻塞、默认 600s 超时，远比 UI 抓取干净。
第二个：BLE 是 1:1。 ESP32 BLE peripheral 一次只能被一个 central 连接，连上之后停止广播。第一版 daemon 抄了 Claude Desktop 的设计，持续连着 BLE 推 heartbeat。结果就是 Claude Hardware Buddy 那边整个找不到设备了，扫描扫不到，偶尔扫到了 connect 立刻被踢。基本 = 我把主功能搞坏了。
最后改成按需 BLE：daemon 平时只挂 Unix socket 当 IPC server，完全不碰蓝牙。Codex 触发审批的瞬间才连 BLE → 推 prompt → 等按键 → 断开。整个流程 3-5 秒。Claude 那边大部分时间都在用 buddy，互不影响。
如果审批触发时 Claude 正占着设备，daemon 8 秒连不上 → hook 退出无 stdout → Codex 自动 fallback 到原生审批弹窗，不会卡死。这是设计好的兜底。
食用方式
需要：macOS、一台跑着 anthropics/claude-desktop-buddy 固件的 BLE 设备、Codex 4 月版本或更新。
git clone https://github.com/Yamiqu/codex-buddy-bridge.git
cd codex-buddy-bridge
./install.sh
会做这几件事：建 venv 装 bleak、写 launchd plist 启动 daemon、把 [features] codex_hooks = true 加进 ~/.codex/config.toml、把 PermissionRequest hook 配置写进 ~/.codex/hooks.json。装完之后重启 Codex Desktop / Codex CLI session 让它重新加载 hook 配置。
第一次 Codex 触发审批时 macOS 会弹蓝牙权限对话框，target 是 venv 里的 python3，同意一次以后 launchd 启动的进程会继承这个权限。
附带一个 codex-buddy CLI：
codex-buddy status 看 daemon 状态 + 末尾 10 行日志
codex-buddy on / off 一键启停 daemon（off 立即释放 BLE 给 Claude）
codex-buddy log tail -F 日志
codex-buddy probe 扫一圈 BLE 看周围有什么，调试用
codex-buddy foreground 前台 --debug 跑，Ctrl+C 真的能退
不能做什么
平时不显示 Codex idle / working 状态。因为 daemon 闲时不占 BLE，没法在 buddy 屏上画 heartbeat ------ 这是和 Claude 共存必须付的代价。
仅 macOS。daemon 依赖 launchd 和 Unix socket，Linux 加个 systemd-user unit 应该不难，欢迎 PR。Windows 没测，hook 那部分理论上能跑，daemon 部分得重写 launchd 那块。
其它
协议照 anthropics/claude-desktop-buddy 的 REFERENCE.md 严格实现，没有任何固件 fork，同一台 buddy 给两边用。19 个单测，重点覆盖 hook payload 转 BLE 帧、firmware 40 字节 promptId 截断的回归（前期被这个坑过 ------ buddy 把我发的 51 字符 id 截到 39 然后 daemon 匹配不上，UUID 当 id 不行）、各种 timeout 路径。
整个降级链路也都验证过：daemon down、BLE 抢不到、buddy 不按键 ------ hook 都退 0 不写 stdout，Codex 走原生 UI。所以即便这个桥挂了也不会让 Codex 难受。
欢迎佬们食用。