LifeOS Interceptor 技能从源码重建全流程：Update 工作流实战指南（拉取、构建、原子安装、bridge 桥接与端到端验证）-平芜编程栈

LifeOS Interceptor 技能从源码重建全流程：Update 工作流实战指南（拉取、构建、原子安装、bridge 桥接与端到端验证）

【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS

本篇以 LifeOS 仓库中 Interceptor 技能的 Update 工作流为骨架，完整讲解在真实浏览器自动化 + macOS Computer Use 场景下，如何从上游源码重新构建并安装 Interceptor：包括$INTERCEPTOR_SRC源码检出、依赖安装与构建、二进制原子化安装（规避OS_REASON_CODESIGNING签名循环）、Chrome 扩展固定（Pin）、Native Messaging 重注册、macOS bridge 桥接的完整生命周期，以及interceptor diagnose端到端验证。读完你可以在自己的机器上安全地完成一次从源码到全链路可用的 Interceptor 升级，并掌握 bridge 排错、安全模型与卸载回滚的完整方法论。

一、Update 工作流在 Interceptor 技能中的定位

Interceptor 是 LifeOS 中负责"真实浏览器自动化 + macOS Computer Use"的核心技能：它是一个 Chrome/Brave 扩展 + 可选 macOS Swift bridge，通过真实浏览器 UI 操作页面（零 CDP 指纹），保持登录态、通过主流反爬检测，并可在安装 bridge 后驱动原生 macOS 应用、OS 级输入与虚拟机生命周期。在 SKILL.md 的 Workflow Routing 表中，Update工作流的触发词是 "update"、"check version"、"rebuild"、"install bridge"、"enable computer use"，职责正是"拉取、重建、重装、安装 Computer Use 桥接、端到端验证"。

该工作流在技能中被多处硬性引用：

隔离门 PreflightIsolation.sh 在版本低于最低要求时以 exit code4退出，并明确指示"通过Workflows/Update.md升级"；
SKILL.md 的 Prerequisites 一节将"macOS bridge 作为 LaunchAgent（full 模式）"的安装指引指向本工作流；
技能 Gotchas 中大量故障（二进制签名失效、Sparkle 缺失、云同步破坏签名、daemon split-brain）的恢复路径都指向本工作流。

何时运行 Update 工作流

原文档明确了五类触发场景：

从上游拉取新提交之后（After pulling new commits from upstream）
在新机器上首次安装（First-time install on a fresh machine）
interceptor 命令意外失败时（If interceptor commands fail unexpectedly）
周期性能力检查（Periodic capability check）
从--browser-only升级到--full（Promoting --browser-only → --full）

强制前置：Voice Notification

与技能内所有工作流一致，执行前必须先发送语音通知（SKILL.md 中标注为 MANDATORY，在任何动作之前执行）：

curl -s -X POST http://localhost:31337/notify \ -H "Content-Type: application/json" \ -d '{"message": "Running the Update workflow in the Interceptor skill to rebuild interceptor"}' \ > /dev/null 2>&1 &

随后输出文本提示：Running **Update** in **Interceptor**...。这是 LifeOS 各技能的约定，确保执行长流程时向用户播报进度。

二、安装模式（Install Modes）：browser-only 与 full

Interceptor 有两种安装模式，使用同一个 CLI 二进制，通过interceptor status输出的mode:行确认当前模式。原文档给出 v0.9.0+ 的通道对照表：

通道	结果模式
`Interceptor-Browser-<v>.pkg`（签名安装器）	`mode: browser-only`
`Interceptor-Full-<v>.pkg`（签名安装器）	`mode: full`
`bash scripts/install.sh --browser-only`（开发路径）	`mode: browser-only`
`bash scripts/install.sh --full`（开发路径）	`mode: full`
`interceptor upgrade --full`	将任意 browser-only 安装提升为 full

两种模式的能力差异，在 SKILL.md 的 Install Modes（0.16.x）一节有更完整的阐述：

mode: full（该技能的默认模式）：安装 CLI + daemon + 扩展 + Swift bridge.app+ LaunchAgent，解锁浏览器自动化之外的 Computer Use 全部能力：AX 可访问性树、OS 级可信输入（HID 源状态）、ScreenCaptureKit、Vision OCR、Speech、NLP、Apple Events、OSLogStore、文件监听、容器运行时与VM 生命周期；
mode: browser-only：仅安装 CLI + daemon + 扩展，只做浏览器自动化。interceptor macos *会在 1 秒内返回结构化的setup_required错误，且不会触发 TCC 权限弹窗。

模式记录在~/.config/interceptor/config.toml中，interceptor status会回显当前的mode:行。原文档特别注明：自 v0.13.4 起，browser-only 模式也支持 Microsoft Edge + Vivaldi 以及 Linux 主机。向 full 模式提升使用interceptor upgrade --full；降级则用bash scripts/uninstall.sh --bridge-only。

技能使用建议：如果用户要求原生能力而status报告mode: browser-only，正确回应是"I'm on a browser-only install. Runinterceptor upgrade --fullto enable that."，而不是试跑 macOS 命令验证报错——虽然 preflight 会短路拦截，但浪费交互轮次。

三、从源码重建的标准流程（Steps 0–3）

原文档在进入步骤前有一句重要提醒：大多数用户不应执行这些步骤。正常安装与升级路径是上游 releases 页的签名.pkg，或在已有安装上运行interceptor upgrade --full。仅当你需要未发布的提交，或正在针对仓库做开发时，才从源码构建。

Step 0：指向你的源码检出

后续所有步骤都读取$INTERCEPTOR_SRC环境变量——它是你克隆的 Interceptor 仓库路径，工具脚本Tools/Pin.sh读取同一个变量：

export INTERCEPTOR_SRC=/path/to/your/interceptor

关键警告：不要把这份检出放在云同步目录中（iCloud Drive、Dropbox、Google Drive）。同步过程会剥离构建出的.appbundle 的代码签名信封（codesign -v会报 "code has no resources but signature indicates they must be present"），导致 macOS bridge 启动即被 SIGKILL 循环。务必放在本地磁盘。Pin.sh 的源码注释也印证了这一点，并进一步说明 esbuild 会把绝对node_modules路径烘焙进打包 JS 的 CommonJS wrapper（如var __dirname = "/Users/<you>/.../ocrad.js"），Pin 脚本需要在每次固定时清理这类路径泄露。

Step 1：拉取最新代码

cd "$INTERCEPTOR_SRC" && git fetch origin && git status -uno

如果有本地改动，先 stash 再拉取：

cd "$INTERCEPTOR_SRC" && \ git stash push -m "local patches" -- '<paths>' && \ git pull --ff-only origin main && \ git stash pop

v0.13.0+ 的重要更新：历史上针对extension/src/content/data/extract.ts的 10M 切片补丁已过时。上游重写了 extract，改用withTruncationMarker+ 每个动作的maxChars+--full标志（设置后上限 200K）。新行为比旧的硬切片更正确——read在截断时会追加... (truncated: showed X of Y chars ...)，read --full则放宽到 200K。如果 stash 里还留着旧补丁，请丢弃它。SKILL.md 的 Gotchas 也确认：本地 extract.ts 定制已过时，无需再打。

若上游 force-push（v0.10 之后已很少见），先检查会丢失什么，然后：

cd "$INTERCEPTOR_SRC" && git reset --hard origin/main

Step 2：安装依赖

cd "$INTERCEPTOR_SRC" && bun install

每次构建前都必须运行——上游可能新增依赖，否则构建会以 "Could not resolve" 失败。

Step 3：构建

cd "$INTERCEPTOR_SRC" && bun run build # 或: bash scripts/build.sh

构建产物：

dist/interceptor— CLI
daemon/interceptor-daemon— 原生消息宿主（native messaging host）
extension/dist/— Chrome 扩展（manifest 反映上游版本）
dist/interceptor-bridge— 裸 Swift 二进制（仅 macOS、full 模式）
dist/interceptor-bridge.app— 内嵌 Sparkle.framework 的.appbundle

四、原子化安装二进制：绝不`cp`覆盖在线文件（Step 4）

这是本工作流最关键的工程实践。com.interceptor.daemon这个 LaunchAgent 以KeepAlive每 5 秒重生 daemon。如果用普通cp覆盖已安装的二进制，重生的 daemon 会读到半写入或签名失效的文件，taskgated会以OS_REASON_CODESIGNING对每次尝试 SIGKILL 循环——原文档记录 2026-08-10 一个窗口内出现 92 份崩溃报告，2026-08-07 也有类似爆发。

正确姿势是暂存（stage）→ 签名（sign）→mv原子重命名，让每次 spawn 都只看到完整签名后的二进制：

cp "$INTERCEPTOR_SRC"/dist/interceptor /opt/homebrew/bin/.interceptor.new cp "$INTERCEPTOR_SRC"/daemon/interceptor-daemon /opt/homebrew/bin/.interceptor-daemon.new codesign --force --sign - /opt/homebrew/bin/.interceptor.new codesign --force --sign - /opt/homebrew/bin/.interceptor-daemon.new mv -f /opt/homebrew/bin/.interceptor.new /opt/homebrew/bin/interceptor mv -f /opt/homebrew/bin/.interceptor-daemon.new /opt/homebrew/bin/interceptor-daemon launchctl kickstart -k "gui/$(id -u)/com.interceptor.daemon" # 让 daemon 拾取新 inode

验证：

codesign --verify -v /opt/homebrew/bin/interceptor-daemon # 退出码 0 launchctl print "gui/$(id -u)/com.interceptor.daemon" | grep -E 'pid|last exit' # 应显示存活 pid，且无 OS_REASON_CODESIGNING 退出

SKILL.md 的 Gotchas 补充了这条规则的背景：对/opt/homebrew/bin/interceptor{,-daemon}原地覆盖会触发OS_REASON_CODESIGNING——即使构建产物已做 ad-hoc 签名，cp覆盖后 daemon 的 spawn 仍会被内核 SIGKILL（launchctl print→last exit reason = OS_REASON_CODESIGNING）。本工作流的第 4 步（stage → sign → 原子mv）正是针对 2026-07-28 升级事故的持久修复。此外 daemon 升级后务必launchctl kickstart -k让 launchd 拾取新二进制，否则扩展侧会持续出现 "native keepalive ping failed / forcing reconnect" 控制台刷屏。

五、固定构建出的扩展（Step 4a）：Pin.sh 的机制与陷阱

签名.pkg安装器会自动放置 Chrome 扩展；本步骤仅适用于源码构建。Tools/Pin.sh会把构建出的extension/dist/复制到~/.claude/skills/Interceptor/Extension/，首次运行时创建该目录——它不随技能分发，只有固定了构建产物后才存在。Chrome 加载这份稳定副本而非构建树，因为重建会原地重写dist/，而 Chrome 会在 manifest 版本变化时禁用未打包扩展。

每次构建后都要重新固定：

bash ~/.claude/skills/Interceptor/Tools/Pin.sh

从 Pin.sh 源码可以看到它实际做了四件事：

rsync 复制：rsync -a --delete将extension/dist/同步到Extension/，排除profile-data/（运行时数据）与PINNED_FROM.txt（由重生成步骤负责）；
清洗绝对路径：用 perl 正则把所有 JS 字符串字面量中形如/Users/<name>/...或/home/<name>/...的 esbuild 烘焙路径替换为"."，防止用户名泄露进公开技能目录；
生成溯源文件PINNED_FROM.txt：写入相对源路径、Manifest version:（从manifest.json提取）、内容 SHA256（对目录内全部文件排序后xargs shasum -a 256再聚合）与Pinned at:时间戳，并注明原因 "Chrome disables unpacked extensions on every manifest version bump"；
泄露守卫：再次扫描，若有任何绝对 home 路径存活则 FATAL（exit 2）并列出匹配行。

源码还揭示了两个内部细节：rel_home()特意用printf '~%s' "${1#"$HOME"}"而不是${x/#$HOME/~}——因为 bash 5.2+ 会对替换结果做波浪号展开，静默把~变回绝对路径，导致清洗失效（2026-07-04 修复）。

Gotcha（2026-08-07，0.22.37 → 0.23.3）：extension/dist/被 gitignore，macOS Finder 的重复文件垃圾（如icon128 3.png、tesseract-core-simd-lstm 2.wasm——扩展名前有空格+数字）会跨构建累积，而bun run build不会清理它们。这些空格会破坏Pin.sh第 56 行未加引号的xargs shasum内容哈希循环，导致set -e下 Pin.sh 在 rsync 新 manifest 之后、重写PINNED_FROM.txt之前退出——留下不一致状态（新 manifest、陈旧的版本+SHA）。修复是先清理源树再重固定：

find "$INTERCEPTOR_SRC"/extension/dist \( -name "* 2.*" -o -name "* 3.*" \) -delete bash ~/.claude/skills/Interceptor/Tools/Pin.sh # exit 0，输出 "✓ pinned + scrubbed (v<X>, sha …)"

确认Extension/PINNED_FROM.txt显示新的Manifest version:与新的Pinned at:。

Self-updater 注意（0.23.x）：上游新增了顶层interceptor update（用户触发检查 + Sparkle 后台自动检查；interceptor update status查看 feed）。本技能不使用它——它会替换已安装二进制，从而丢掉未上游化的screenshot --save补丁。在补丁合入上游之前，始终按本工作流从源码构建。

六、重新注册 Native Messaging（Step 5）

cd "$INTERCEPTOR_SRC" && bash scripts/install.sh --chrome --skip-extension

--skip-extension对 Chrome 是正确的路径——品牌版 Chrome 忽略--load-extension，扩展重载是手动步骤（见第八节）。该脚本会重新生成~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.interceptor.host.json，写入当前允许的扩展 ID 列表。

运维提示（来自 SKILL.md Gotchas）：Chrome 的 NMH manifest 可能是指向$INTERCEPTOR_SRC/daemon/.generated/的符号链接（install.sh 会重建它指向仓库树）——若出现 daemon split-brain，应替换为指向/opt/homebrew/bin的真实文件。

七、Bridge——macOS 原生助手（Computer Use）（Step 6）

full 模式必需，仅在明确运行--browser-only时跳过。bridge 解锁 Computer Use 全套能力：OS 级可信输入、通过可访问性树控制原生应用、ScreenCaptureKit、Vision OCR、Speech、NLP、Apple Events、OSLogStore、文件监听、VM 生命周期、容器运行时。

6a. 安装（Apple Silicon 正确顺序——`.app`bundle 拓扑）

本机实际运行的 LaunchAgent 指向的是.appbundle内的二进制，而不是/usr/local/bin中的裸副本：

ProgramArguments[0] = ~/.local/share/interceptor/interceptor-bridge.app/Contents/MacOS/interceptor-bridge

签名.pkg会把.appbundle 装到这个位置（Sparkle.framework 内嵌于Contents/Frameworks/，无需单独的/usr/local/Frameworks副本）。旧的/usr/local/bin/interceptor-bridge副本已过时——不要安装它、不要把 plist 指向它、不要重新签名它。开发构建则把新构建的.appbundle 暂存到位：

# 1. 暂存 .app bundle（无需 sudo——位于 $HOME 下） mkdir -p ~/.local/share/interceptor rm -rf ~/.local/share/interceptor/interceptor-bridge.app cp -R "$INTERCEPTOR_SRC"/dist/interceptor-bridge.app \ ~/.local/share/interceptor/interceptor-bridge.app # 2. 写入 $HOME 下的 LaunchAgent plist（无需 sudo）——指向 .app MacOS 二进制 cat > ~/Library/LaunchAgents/com.interceptor.bridge.plist <<PLIST <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key><string>com.interceptor.bridge</string> <key>ProgramArguments</key><array><string>$HOME/.local/share/interceptor/interceptor-bridge.app/Contents/MacOS/interceptor-bridge</string></array> <key>RunAtLoad</key><true/> <key>KeepAlive</key><dict><key>SuccessfulExit</key><false/></dict> <key>StandardOutPath</key><string>/tmp/interceptor-bridge.stdout.log</string> <key>StandardErrorPath</key><string>/tmp/interceptor-bridge.stderr.log</string> <key>ThrottleInterval</key><integer>5</integer> </dict> </plist> PLIST # 3. 以用户身份加载（无需 sudo——uid 在脚本调用时捕获） launchctl bootstrap "gui/$(id -u)" ~/Library/LaunchAgents/com.interceptor.bridge.plist

注意：launchctl bootstrap成功时退出码为 1——这正常，用下一步验证。若 SIGKILL 了 bridge 且它每 ~5 秒重启循环（ThrottleInterval），原因是 agent 实际运行的二进制上残留了过期的 ad-hoc 签名。重新签名.appMacOS 二进制（~/.local/share/interceptor/interceptor-bridge.app/Contents/MacOS/interceptor-bridge），而不是过时的/usr/local/bin副本。

6b. 验证——检测并重启死掉的 bridge

"已加载" ≠ "运行中"。launchctl list显示 label 只证明 agent 已加载；要用interceptor status探测实际进程：

interceptor status | grep -A2 '^bridge:' # running + pid/socket，或 not running launchctl print "gui/$(id -u)/com.interceptor.bridge" 2>&1 | grep -E 'state|program|pid' ls -la /tmp/interceptor-bridge.sock # → srwxr-xr-x <user> staff

重启已加载但死亡的 bridge：

launchctl kickstart -k "gui/$(id -u)/com.interceptor.bridge"

interceptor status --verbose只报告扩展可达性——它不暴露扩展构建版本字段，所以不要用它做新鲜度检查。当 2+ 个 context 连接时，即使传了--context它也会提示not reachable — multiple extensions connected，这是预期行为而非故障。

若interceptor status显示bridge: not running而launchctl print显示 agent 已加载，说明 helper 启动即崩溃——查看/tmp/interceptor-bridge.stderr.log，确认 plist 指向.appMacOS 二进制（而非过时的/usr/local/bin副本），然后kickstart -k。

仓库中 HealBridge.sh 正是这段"loaded-but-dead 检测 + 单次 kickstart"的自动化封装：它先校验uname -s为 Darwin、interceptor在 PATH，然后用 awk 解析interceptor status的bridge:块判断是否 running，死亡则执行launchctl kickstart -k "gui/$UID_NUM/com.interceptor.bridge"并最多轮询 10 次（每次 0.3s）确认恢复，失败时输出指向重新签名.app二进制的 remediation 提示。

6c. 首次运行配置

interceptor init # 写入初始 ~/.config/interceptor/config.toml interceptor contexts # 列出已连接的浏览器 context interceptor macos trust # 探测 bridge 的 TCC 授权 interceptor macos trust --walkthrough # 缺失授权时深链到系统设置

6d. 安全模型——安装前必读

传输层是 UNIX domain socket/tmp/interceptor-bridge.sock——仅本地，无网络监听；
socket 无认证。任何以你的用户身份运行的本地进程都能连接并执行全部 bridge 动作。macOS TCC 权限（Accessibility、Screen Recording、Microphone）一次性授予 bridge，并被所有 socket 客户端继承。（trust探测恰好暴露三个键——accessibility、screenRecording、microphone——没有inputMonitoring字段。）
边缘风险是供应链型：恶意本地包无需自己的权限授权，即可一步获得 OS 级输入/屏幕/剪贴板路径；
单用户 Mac 威胁模型下可接受。多用户 Mac 需要 socket 加固（在 plist 的 post-start hook 中chmod 700socket）；
二进制溯源：从$INTERCEPTOR_SRC/interceptor-bridge/Sources/本地构建、ad-hoc 签名用于开发。v0.9.0+ 提供 Developer-ID 签名的.pkg用于分发——这里从源码构建是为了快速迭代。

6e. 排错对照表

症状	原因	修复
`launchctl bootstrap`报 "service already loaded"	之前的安装残留	`launchctl bootout "gui/$(id -u)/com.interceptor.bridge"`后重新 bootstrap
`interceptor status`显示 bridge 未运行	首次动作的 TCC 弹窗被阻断	触发一次`act --trusted`，在系统设置 → 隐私与安全性（辅助功能）中接受 macOS 弹窗
socket 存在但写入失败	二进制带 macOS quarantine	`xattr -dr com.apple.quarantine ~/.local/share/interceptor/interceptor-bridge.app`
bridge 每 ~5 秒重启循环	启动即崩溃	`tail /tmp/interceptor-bridge.stderr.log`；通常是缺失 entitlement 或过期 ad-hoc 签名——重新签名`.app`MacOS 二进制（`~/.local/share/interceptor/interceptor-bridge.app/Contents/MacOS/interceptor-bridge`），不是`/usr/local/bin`副本，然后`launchctl kickstart -k "gui/$(id -u)/com.interceptor.bridge"`
stderr 中`dyld[*]: Library not loaded: @rpath/Sparkle.framework/...`	Sparkle.framework 缺失	执行上文第 1 步，然后`launchctl kickstart -k "gui/$(id -u)/com.interceptor.bridge"`
VM 命令报`setup_required: virtualization entitlement missing`	bridge 需要`com.apple.security.virtualization`	用`scripts/build-bridge.sh`重建；确认 entitlement 存在
VM 命令报`setup_required: bridge install location`	bridge 装在`~/Documents`或`~/Desktop`下	把 bridge`.app`移出云同步目录

6f. 卸载

launchctl bootout "gui/$(id -u)/com.interceptor.bridge" rm ~/Library/LaunchAgents/com.interceptor.bridge.plist rm -rf ~/.local/share/interceptor/interceptor-bridge.app # agent 实际运行的 bundle sudo rm -f /usr/local/bin/interceptor-bridge # 若旧安装留下过时副本 sudo rm -rf /usr/local/Frameworks/Sparkle.framework # 仅当旧安装把框架放在这里 rm -f /tmp/interceptor-bridge.sock /tmp/interceptor-bridge.pid rm -f /tmp/interceptor-bridge.stdout.log /tmp/interceptor-bridge.stderr.log

可选：在系统设置 → 隐私与安全性（辅助功能、屏幕录制、麦克风）中移除interceptor-bridge条目，撤销 macOS 权限。

八、扩展重载（手动——Chrome 不会自动刷新未打包扩展）（Step 7）

如果Extension/manifest.json变了（尤其是version或key）：

打开chrome://extensions，启用开发者模式；
删除现有 Interceptor 卡片（不要只点重载——如果 manifestkey变了，扩展 ID 已变，旧卡片已失效）；
加载已解压的扩展程序→~/.claude/skills/Interceptor/Extension（第 4a 步中Tools/Pin.sh创建的副本——不是符号链接；它不会自动跟随上游，所以每次构建后必须重新固定）。如果用的是签名.pkg安装，安装器已注册扩展——跳过此步；
完全退出 Chrome（⌘Q，不是只关窗口）再重启——service worker 需要干净重启，尤其是新增了userScripts权限时；
接受任何新权限提示（userScripts等）。

如果只改了扩展目录内的 JS/HTML（manifest 未变），在现有卡片上点重载箭头即可。

九、端到端验证（Step 8）

interceptor --version interceptor status interceptor status --verbose interceptor contexts interceptor diagnose --no-skills-hint # 0.22.2+：daemon 执行路径、逐 context 探测、split-brain 检查 interceptor open "https://example.com"

status报告daemon与bridge两行（跳过第 6 步时 bridge 显示 "not running"——browser-only 下这正常）。open应返回树 + 提取的文本。diagnose是新版必跑检查——它打印 daemon 的真实执行路径，并标记二进制 split-brain（Chrome spawn 了一个 daemon 二进制，而 CLI 与另一个通信）。如果报告不匹配，把 NMH manifest 的path指向/opt/homebrew/bin/interceptor-daemon并pkill -f interceptor-daemon。完整的 bridge 签名 / 云同步 / launchd 节流恢复序列参见 SKILL.md 的 Gotchas 一节。

CommandReference.md 提供了对应命令的完整动词清单：interceptor macos trust探测 TCC 授权（字段为 camelCase 的accessibility/screenRecording/microphone，无inputMonitoring）、interceptor macos vm *的完整生命周期（Linux 走 Apple Containerization、macOS 走原生Virtualization.framework），以及 daemon 控制 socket/tmp/interceptor.sock（bridge socket 为/tmp/interceptor-bridge.sock）。VM 状态默认位于~/Library/Application Support/Interceptor/vms/，可用--state-dir或INTERCEPTOR_VM_STATE_DIR覆盖——详见 VmLifecycle.md。

十、版本演进与注意事项（Notes）

上游 force-push 已罕见（v0.10 前常见）。大多数情况下普通git pull --ff-only即可；
AXEnhancedUserInterface已在 v0.11+ 移除——bridge 仅用AXManualAccessibility做 Electron 唤醒。旧代码中设置AXEnhancedUserInterface的过时建议应忽略；
Sparkle 自动更新（v0.10.0+）——.appbundle 内嵌 Sparkle 用于就地更新，bridge 启动时轮询上游 feed；
VM 生命周期（v0.13+）——要求 bridge 带com.apple.security.virtualizationentitlement。状态位于~/Library/Application Support/Interceptor/vms/（可用--state-dir或INTERCEPTOR_VM_STATE_DIR覆盖）。

十一、升级后的运维红线（来自 SKILL.md 的实战沉淀）

作为 Update 工作流的延伸，SKILL.md 记录了多条由真实事故沉淀的升级后运维规则，与本工作流直接相关：

云同步目录会破坏 bridge 代码签名：若源码检出位于（或符号链接进）iCloud Drive / Dropbox / Google Drive，同步会剥离.app的代码签名信封，复制到位后 bridge SIGKILL 循环（launchctl print→last exit reason = OS_REASON_CODESIGNING）。真正修复是把检出移到本地磁盘；修复已损坏 bundle 需按序xattr -cr→codesign --force --deep --sign -Sparkle.framework → 对 MacOS 二进制与.app分别用scripts/entitlements-bridge.plist签名（不要codesign --deep整个 app，会错签嵌套 Sparkle）；
bash scripts/install.sh --chrome会再次覆盖刚修复的 bridge：它链式调用 install-bridge.sh，把原始（仍损坏的）bundle 重新拷回。签名之后再运行它——或者 bridge 已签名就不要再跑；
launchdjob state = spawn failed：反复kickstart -k后 launchd 节流进入失败态。恢复是launchctl bootout后全新launchctl bootstrap，而不是再 kickstart；
ad-hoc 重签名会重置 bridge 的 TCC 授权：新 ad-hoc 签名 = 新代码身份，Accessibility / Screen Recording / Microphone 掉回denied，Computer Use 停止直到重新授权（interceptor macos trust --walkthrough）。久经考验的Interceptor-Full-<v>.pkg在 Sparkle 更新中保持稳定的 Developer-ID 身份，能规避这一切——TCC 频繁变化时优先用它；
从源码重建 bridge 同样重置 TCC：且重拨旧行无效（旧行键绑定旧签名）。用tccutil reset Accessibility com.interceptor.bridge && tccutil reset ScreenCapture com.interceptor.bridge，kickstart 后跑一次macos windows重新注册，再由用户确认系统设置里的新行；永久修复是构建前设置INTERCEPTOR_SIGNING_IDENTITY为真实 Developer ID；
manifest bump 后的扩展重载可以零操作：完整退出 Chrome + 重启通常就能以新 manifest 版本重新启用固定扩展（0.22.2 → 0.22.37 实测），先试重启，失败再走手动删除 + Load Unpacked；
daemon 常驻 LaunchAgent（com.interceptor.daemon）：RunAtLoad+KeepAlive保证单例常驻，是扩展侧 "native keepalive ping failed / forcing reconnect" 刷屏的持久修复。daemon 二进制升级后记得launchctl kickstart -k（与 bridge 同一模式），并用interceptor status确认 daemon pid 等于 launchd pid。

十二、与隔离门的联动

最后需要强调：Update 工作流不是孤立存在的。升级后如果二进制版本低于0.16.0，隔离门 PreflightIsolation.sh 会以 exit code4硬失败并指向本工作流；如果升级只把新二进制留在$INTERCEPTOR_SRC/dist/而没有复制进/opt/homebrew/bin/，CLI 会停留在旧版本——旧二进制不认识--context或contexts子命令，会静默把命令路由到 operator 的 Default 配置，这正是 2026-05-23 的 fallback 事故。因此每次重建后请严格按第 4 步原子安装，并用interceptor --version、interceptor open --help（应含--context相关标志）与interceptor contexts三重确认版本就位，必要时pkill -f interceptor-daemon让下次调用拉起新 daemon。隔离门（exit code 4 → Update.md）与 Update 工作流（第 4 步 → 原子安装）构成了"版本不达标 → 正确升级 → 验证达标"的闭环。

围绕此流程的配套环境变量定义见 preferences.env.example：INTERCEPTOR_TEST_CONTEXT_ID（固定测试 context 的友好名，建议设为interceptor-test以规避 UUID rot）、INTERCEPTOR_TEST_CHROME_PROFILE、可选的INTERCEPTOR_TEST_BROWSER/INTERCEPTOR_TEST_BROWSER_BIN与INTERCEPTOR_WORKING_PROFILE_IDS（preflight 硬拒绝驱动的 operator 工作 profile 列表）。将该文件复制为~/.claude/LIFEOS/USER/CUSTOMIZATIONS/SKILLS/Interceptor/preferences.env并填写两个必填值后，整个隔离 + 更新体系即可完整运转。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

LifeOS Interceptor 技能从源码重建全流程：Update 工作流实战指南（拉取、构建、原子安装、bridge 桥接与端到端验证）