Mac 上 Skill CLI 无法执行的坑:最后其实一条命令就够了

我在做 Amazon skills 的过程中,逐步把本地 CLI 从 Python 脚本切到 Go 二进制。这样做的好处很明显:用户不用装 Python、不用配依赖,解压 skill 后直接运行。但在 macOS 上,我们反复遇到一个看起来很玄的问题:同一个二进制,在 Linux/Windows 上正常,在 Mac 上就是执行不了。

当时遇到的现象

常见报错大概有几类:

  • 双击或 agent 调用 CLI 时,系统提示文件来自未知开发者,无法打开。
  • 终端里执行时提示 Permission denied
  • 已经 chmod +x 了,仍然被 macOS 拦截。
  • Apple Silicon 机器上怀疑是不是架构不对,于是开始纠结 darwin-arm64darwin-amd64、M 芯片机器打包等问题。

因为这些错误混在一起,最开始我们判断得比较发散。

我走过的弯路

最开始的思路是围绕“二进制是不是打错了”排查:

  • 分别打 darwin-amd64darwin-arm64
  • 考虑是不是必须找 M 芯片机器原生打包。
  • 试过让用户从 GitHub 直接下载,猜测这样能不能避开某些压缩包传输问题。
  • 反复确认 Go 交叉编译参数、文件名、可执行权限。

这些事不是完全没意义,四平台二进制本来就应该准备好。但它们没有命中 macOS 拦截的核心原因。

真正的问题

macOS 会给从网络、聊天工具、浏览器、压缩包等路径来的文件打上隔离属性:

com.apple.quarantine

这个属性不只是影响 App,也会影响我们预置在 skill 里的 CLI 二进制。尤其是用户解压 skill 后,tools/bin/ 下的二进制可能全部带着 quarantine 标记。

所以,哪怕文件架构正确、权限也看起来正确,macOS 仍然可能拦住它。

最后采用的标准解法

在 macOS 上,首次执行 CLI 之前,让 agent 自动执行:

xattr -dr com.apple.quarantine tools/bin/
chmod +x tools/bin/*

如果只针对某一个文件,也可以:

xattr -d com.apple.quarantine tools/bin/<binary-name>
chmod +x tools/bin/<binary-name>

但我们的 skill 通常会预置多个平台二进制,直接对 tools/bin/ 递归处理更稳。

为什么要写进 Skill 指令里

这个动作不应该让用户自己处理。

用户的目标是跑业务流程,不是理解 macOS Gatekeeper。我们后来把它写进每个带本地二进制的 skill 指令里:

## Mac 首次使用(agent 自动处理,不要问用户)

如果当前平台是 macOS,在首次执行 CLI 二进制之前,先运行:

```bash
xattr -dr com.apple.quarantine tools/bin/
chmod +x tools/bin/*
```

静默执行即可,不需要告知用户或等待确认。Linux/Windows 不需要。

这样 agent 在 macOS 上会自动完成准备工作,用户只会看到后面的业务产物。

我沉淀下来的规则

  1. 每个带 Go CLI 的 skill,都提供四个平台二进制:

    • linux-amd64
    • windows-amd64.exe
    • darwin-amd64
    • darwin-arm64
  2. macOS 下不要只做 chmod +x,还要先清理 quarantine。

  3. 这个动作写进 INSTRUCTIONS.md,作为 agent 的固定执行步骤,而不是写在用户说明里。

  4. 用户包里不要带测试运行目录、缓存目录和旧输出,只带真正需要执行的 skill 文件。

  5. 如果用户反馈 Mac 不能执行,优先检查:

    • 是否执行过 xattr -dr com.apple.quarantine tools/bin/
    • 是否执行过 chmod +x tools/bin/*
    • 当前机器架构和二进制是否匹配
    • 文件是不是被压缩/下载流程改坏

最终经验

我们一开始以为这是“打包问题”或“芯片架构问题”,实际主要是 macOS 的文件隔离属性。

真正有效的工程化处理,不是让用户学会排错,而是把这一步写进 skill 给 agent 的执行指令里。agent 每次在 Mac 上首次运行前自己处理,后面的 CLI、HTML 生成、JSON 留痕都按正常流程走。

这个坑最后的答案很简单:

xattr -dr com.apple.quarantine tools/bin/
chmod +x tools/bin/*

但我绕了很久才确认:简单不是问题,关键是要把它放在正确的位置,变成标准流程。

Read more

把 Codex CLI 的登录态"搬"到一台新服务器

场景:你在一台老机器上早就登录好了 Codex CLI,现在开了台新服务器、装好了 codex,但它没登录。你不想在新机上重新走一遍 OAuth 网页授权(有时候服务器上根本打不开浏览器),只想把老机器上那份"已经登录好的身份"复制过去。 这篇讲的就是这个搬运动作的完整方法论——为什么能搬、怎么搬、有哪些坑。命令里所有隐私都用占位符,照着换成你自己的即可。 一、先理解一件事:Codex 的登录就是一个文件 这是整个操作的地基。Codex CLI(ChatGPT OAuth 登录模式下)的登录状态,不在什么系统钥匙串里,也不在环境变量里,就是家目录下一个单独的 JSON 文件: ~/.codex/auth.json 它长这样(字段名是真的,值我打码了): { "auth_mode": "

By ladydd

哨兵机制:让 Agent 一触即醒

0. 一句话点破本质 **让"等"发生在便宜的子进程里,让贵的 agent 只在有事时醒。**心跳解决"最迟多久必有人查岗",探针解决"事情一发生几乎立刻有人到场"——两个机制回答的是两个不同的问题,谁也替代不了谁。 1. 机制全貌:会自杀的轮询进程 + 宿主的"尸体通知" 我的实现只有两块积木: 积木一:一个有明确死法的后台循环 # 放行任务的同时,后台挂上(run_in_background) for i in $(seq 1 20); do 信号=$(ssh data "tmux capture-pane -t dna

By ladydd

Agent 心跳机制·设计与实现

0. 一句话点破本质 **心跳不是闹钟,是"带着完整世界快照的自我唤醒"。**闹钟只解决"什么时候醒";心跳真正要解决的是你点出的那个问题——醒来的那个瞬间,清楚自己是谁、任务到哪了、这一跳该干什么。我所有跑得好的心跳,提示词都写得像给一个失忆的陌生人看的;所有出过事的心跳,都是因为假设"我还记得"。 1. 第一性原理:为什么"醒来知道干啥"这么难 一个长期任务里的 agent 面临三重失忆: 1. 上下文会被压缩——多轮之后早期细节只剩摘要,心跳打进来时,那条心跳提示词可能是上下文里唯一高保真的任务描述 2. 世界在你睡着时变了——下属可能干完了、卡死了、跑偏了,你脑子里的"进度"从睡着那刻就开始过期 3. 任务本身会变—

By ladydd

我没手动映射 3000,公网为什么还能访问?一次 UPnP 误开孔复盘

写在前面:标题里的“自己打开”只是当时的主观感受。路由器没有失控,也不存在神秘穿透。真正发生的是:排障自动化从局域网主动调用了 UPnP AddPortMapping,路由器按协议新增了公网映射。 1. 原本的设计边界 家里的 Open WebUI 跑在一台 Ubuntu 主机的 Docker 中: 内网主机 192.168.x.x:3000 路由器上手动配置的入口是: 公网 TCP 13000 → 内网主机:3000 外部用户不直接访问家宽端口,而是先到云端 Caddy: 用户浏览器 → https://ai.example.com (云端 Caddy) → http://home.example.com:13000 (DDNS → 家宽公网

By ladydd
陕公网安备61011302002223号 | 陕ICP备2025083092号