它解决的是一个很具体但越来越常见的问题：你的日常电脑已经登录了各种网站和 CLI，但真正跑 agent 的可能是另一台 Mac mini。agentcookie 试图把 Chrome cookie、CLI bearer token、API key 和相关 auth blob 连续、单向、加密地同步过去，让 OpenClaw、Hermes 或其他 agent runtime 一醒来就已经“像你一样登录”。
一句话：它是给“第二台 agent 机器”同步登录态的本地工具。源机器是你日常登录网站的 Mac，目标机器是跑 agent 的 Mac。它把认证状态持续推过去。
你可以把它理解成“登录态搬运工”。你在主力 Mac 上登录 GitHub、Instacart、eBay、各种 CLI。agentcookie 观察这些登录态变化，把能搬的 cookie/token/API key 安全地搬到另一台 Mac，让那台机器上的 agent 不用重新登录。
它读取源 Mac 上 Chrome Cookies SQLite 和 per-CLI secrets bus，经 blocklist 过滤后，用配对派生密钥做 AES-256-GCM 封装，通过 Tailscale tailnet POST 到 sink。sink 再把状态写入 Chrome profile、plaintext sidecar、CLI adapter session file 或 cmux WebKit cookie jar。
传统 cookie 同步工具多半假设两台电脑都有人在用：点一下导入、合并一下 cookie、手动解锁一下 vault。agentcookie 的场景是：另一台 Mac mini 上没有人在，agent 需要 30 秒内带着你的登录态执行任务。
比如 agent 打开网站查订单、预约、购物车、后台页面。如果没有登录态，它会卡在 2FA、验证码、Keychain prompt 或 OAuth 页面。
很多 PP CLI 或内部 CLI 需要 bearer token、API key、session.json。agentcookie 的 secrets bus 把这类 auth blob 也一起同步。
sink 可以通过 LaunchAgent 持续运行，开机后自动接收。目标是“装完以后人不用再碰”。
| 问题 | Chrome Sync / 手动复制 | agentcookie |
|---|---|---|
| 是否适合无人值守 | 弱，常需要 GUI、登录或人工确认 | 强，设计目标就是 headless sink |
| 传输方式 | 依赖平台账户或人工导出 | 一对一 tailnet，应用层 AEAD 加密 |
| CLI token | 不覆盖 | secrets bus 覆盖 bearer/API key/env blob |
| 控制粒度 | 浏览器级 | source/sink 双侧 blocklist，per-CLI manifest |
| 风险 | 平台托管或人工误操作 | sink 获得高权限登录态，需要严格隔离 |
项目文档把一次 sync 拆得很清楚：source 读 cookie、解密、过滤、封装、加密、POST；sink 解密、校验、过滤、写入多个 delivery surface。
source 生成配对码和 X25519 keypair，sink 输入 code 和 pair URL。双方用 X25519 ECDH，再以 pairing code 作为 HKDF salt，得到 32-byte pair key。
协议 v1 的 envelope 包含 protocol_version、source_hostname、sequence 和 cookie 数组。sink 先验 AEAD tag，再验版本、sequence、blocklist。
{
"protocol_version": 1,
"source_hostname": "my-laptop.tailnet.ts.net",
"sequence": 1747432817,
"cookies": [ { "host_key": ".example.com", "name": "session", "value": "..." } ]
}因为不同 agent 和 CLI 读登录态的方式不一样。agentcookie 的实用性来自“同时喂多种入口”，而不是只写一个 cookie 文件。
| Surface | 写到哪里 | 解决什么 | 限制 |
|---|---|---|---|
| Universal Chrome profile | sink 的真实 Default Chrome Cookies SQLite，并用 sink Keychain 重加密 | 不改造任何 cookie 工具也能读 Chrome 登录态 | 需要处理 macOS Safe Storage 权限；headless 安装需要一次 login password |
| Plaintext sidecar | ~/.agentcookie/cookies-plain.db | agentcookie-aware 工具可以不碰 Keychain 直接读 | 默认明文落盘，必须依赖用户目录权限和机器隔离 |
| Per-CLI adapters | 各 CLI 的 session.json / config.toml / cookies.json | 让特定 CLI 无需懂 Chrome cookie 格式 | 每个 CLI 格式变动都可能需要 adapter 维护 |
| cmux WebKit | cmux rpc browser.cookies.set | 给 cmux 内置 WebKit 浏览器注入登录态 | 只同步 cookie；localStorage/IndexedDB/device-bound session 可能仍要手动登录 |
| Secrets bus | ~/.agentcookie/secrets/<cli>/secrets.env | 同步 bearer token、API key、OAuth refresh token 等非 cookie 认证 | 不是密钥生成/轮换系统，只搬运已有凭据 |
README 里最容易被忽略的点是 secrets bus。它不是只同步浏览器 cookie，而是提供一个 per-CLI 的文件标准，让 bearer token/API key/env blob 也随同同步。
所有 secrets 放在 ~/.agentcookie/secrets/<cli-name>/，核心文件是 secrets.env 和 manifest.toml。env 格式是严格 dotenv 子集，便于 Go/Python/Node/Ruby 读一致。
项目可以放一个 agentcookie.toml，声明自己参与同步、secret 文件在哪、哪些 key 默认同步、哪些 key 排除、是否有 alias 和 carried files。agentcookie discover 自动发现。
# ~/.agentcookie/secrets/example-cli/secrets.env
API_TOKEN=abc123
OAUTH_REFRESH_TOKEN="..."
# agentcookie.toml
schema_version = 2
name = "example-cli"
display_name = "Example CLI"
[secrets.file]
path = "~/.config/example-cli/.env"
[sync]
default = true
[sync.keys]
LOCAL_MACHINE_ONLY = false文档说得很清楚：secrets bus 不是 secret store，不负责生成密钥、不发 OAuth、不做轮换、不判断过期。它只是把某个 CLI 已经拥有的认证结果搬到 sink，让 agent 可以调用。
agentcookie 自己的 threat model 写得比较坦诚。这里要分清“传输安全”“落盘安全”“机器被攻破”是三件事。
v0.13 runbook 的重点是“one-password keychain onboarding”：为了让 universal cookie delivery 工作，sink 需要让 Chrome Safe Storage 可被指定路径读取。现代 macOS 不允许完全无密码修改 Keychain item access，所以底线是 SSH 里输入一次 login password，而不是 GUI 里点一堆 Allow。
Chrome 的 Device Bound Session Credentials 会把某些 session refresh 绑定到源机器安全硬件。agentcookie 没有也不应该尝试绕过它。
如果站点采用 DBSC，复制到 sink 的 cookie 可能短时间内还能用，但刷新挑战需要源 Mac Secure Enclave 中不可导出的私钥签名。sink 做不到，所以几分钟后失效。
它会标记 DBSC-suspect cookie，在 doctor 里警告；也支持 --skip-dbsc-suspect 直接不发。对 Google/Workspace 这类场景，正确方式是在 sink 的 Chrome 上登录一次，建立自己的 device-bound session。
# README 当前推荐的安装入口
go install github.com/mvanhorn/agentcookie/cmd/agentcookie@latest
# source
agentcookie wizard install --as source --peer <second-mac-hostname>
# sink
agentcookie wizard install --as sink --peer <first-mac-hostname> \
--code <pairing-code> --pair-url http://<first-mac-hostname>:9998/pair
# 验证
agentcookie doctor
agentcookie wizard verify-adapters
agentcookie accounts off x.comagentcookie 的价值很明确：当 AI agent 从“本机工具”变成“另一台长期运行的执行节点”，认证状态会成为第一大摩擦。它把这个摩擦系统化处理：cookie、CLI token、API key、adapter、cmux、LaunchAgent、Tailscale、pairing、blocklist、doctor，都围绕“第二台 Mac 无人值守但要已登录”这个单点展开。
我最欣赏的是它没有把问题讲成“万能登录同步”。文档明确承认 DBSC、设备指纹、root compromise、Chrome compromise、plaintext sidecar 默认风险。也就是说，它是一个面向懂边界的 power user / agent operator 的工具，不是给普通用户无脑安装的浏览器同步插件。
如果要类比：agentcookie 是 AI agent 时代的“会话状态复制层”。它不让 agent 更聪明，但让 agent 更少卡在登录、Keychain prompt、API key 缺失这些非智能问题上。前提是你愿意承担并管理它带来的权限集中风险。