[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-82806":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":13,"openIssues":14,"contributorsCount":15,"subscribersCount":15,"size":15,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":15,"forks30d":15,"starsTrendScore":19,"compositeScore":20,"rankGlobal":9,"rankLanguage":9,"license":21,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":22,"hasPages":22,"topics":24,"createdAt":9,"pushedAt":9,"updatedAt":33,"readmeContent":34,"aiSummary":35,"trendingCount":15,"starSnapshotCount":15,"syncStatus":13,"lastSyncTime":36,"discoverSource":37},82806,"agentcookie","mvanhorn\u002Fagentcookie","mvanhorn","Your agent runs on a Mac that isn't your daily driver. agentcookie keeps its sessions in sync with the Mac you actually browse on, continuously, encrypted over Tailscale, so OpenClaw, Hermes, or any other agent runtime wakes up authenticated. macOS, peer-to-peer, no cloud middleman.",null,"Go",391,19,2,1,0,41,211,311,184,3.9,"MIT License",false,"main",[25,26,27,28,29,30,31,32],"ai-agents","automation","chrome","cli","cookies","golang","macos","tailscale","2026-06-12 02:04:28","# agentcookie\n\nYour agent runs on a Mac that isn't your daily driver. It needs to act as you on every site you're already logged into and against every API you've already authenticated. agentcookie keeps your second Mac's session state (Chrome cookies, per-CLI bearer tokens, API keys, and the auth blobs your tools persist next to them) in sync with your first Mac's, continuously, encrypted over your Tailscale tailnet, with zero per-site auth ceremony.\n\nOpenClaw, Hermes, or any other agent runtime you point at the second Mac wakes up authenticated, on the web and in the terminal.\n\n## What it looks like\n\nYou browse normally on your first Mac. agentcookie watches Chrome's Cookies file (and a parallel per-CLI secrets bus) and ships the diff to your second Mac the moment anything changes. On the second Mac, an agent does its work:\n\n```\n$ ssh second-mac 'instacart-pp-cli carts'\n  Costco                 slug=costco   cart=757109404 items=5\n  Safeway                slug=safeway  cart=3190      items=1\n\n$ ssh second-mac 'ebay-pp-cli auctions \"watch\" --has-bids --ending-within 1h'\n12 active auctions:\n  $352   23 bids   1m   Apple Watch Ultra 2 49mm Titanium ...\n  $115   26 bids   1m   Gucci 5500M Steel Quartz ...\n  ...\n\n$ ssh second-mac 'table-reservation-goat-pp-cli goat \"omakase\" --location seattle'\n{ \"results\": [ { \"name\": \"Omakase Dinner Series\", \"network\": \"tock\", ... } ] }\n```\n\nNo `auth login`. No Keychain prompt. No paste-the-cookie ritual. No re-entering API keys you already configured on your laptop. The agent's sessions were already there when the request hit.\n\nThe same is true for browser-driving agents and for any unmodified cookie tool. On a universal sink (the default), agentcookie writes your real Default Chrome profile and opens its Safe Storage key with a single login-password entry at install, so a tool that has never heard of agentcookie, yt-dlp, gallery-dl, a Polymarket CLI, a browser-driving agent, reads your synced, logged-in session with no per-tool setup. Prefer not to touch Chrome at all? Read the plaintext cookies sidecar at `~\u002F.agentcookie\u002Fcookies-plain.db`, and the per-CLI secrets under `~\u002F.agentcookie\u002Fsecrets\u002F\u003Ccli>\u002Fsecrets.env`.\n\n## What this fixes\n\nLogging in twice. Once on your laptop, once again on the Mac your agent lives on. Per site, per CLI, per API key. Forever.\n\nTools that ship cookies between machines today assume a human is going to click \"merge\" or unlock a vault or open the destination browser. They were built for switching accounts between two laptops the same person uses. They weren't built for \"the agent on the headless Mac mini needs my session in 30 seconds and there's nobody home.\"\n\nagentcookie is the second pattern. One-way, continuous, unattended replication from the machine you live in to the machine your agents act from. Pairing-derived per-peer keys, blocklist filters on both sides, AES-256-GCM over the Tailscale tailnet's WireGuard channel. The hard parts (macOS Keychain protections, Chrome's App-Bound Encryption, per-CLI auth conventions) are handled.\n\n## How it works\n\n```\nlaptop                                              second Mac\n======                                              ==========\n\nChrome cookies change      secrets bus change\n(fsnotify on Cookies)      (fsnotify on ~\u002F.agentcookie\u002F\n  |                         secrets\u002F\u003Ccli>\u002Fsecrets.env,\n  |                         or autodiscovered via\n  |                         agentcookie.toml manifests)\n  |                                |\n  +--------------+-----------------+\n                 |\n                 v\nagentcookie source --watch  (decrypt Chrome with Keychain key,\n                             filter against blocklist, fold in\n                             secrets bus payload)\n                 |\n                 v\n+----- HTTPS over Tailscale (AES-256-GCM, replay-defended) -----+\n                                                                |\n                                                                v\n                                              agentcookie sink (LaunchAgent)\n                                                |\n                                                | one of three cookie delivery surfaces:\n                                                v\n                                              1. Chrome's Cookies SQLite (re-encrypted for sink Keychain)\n                                              2. Plaintext sidecar at ~\u002F.agentcookie\u002Fcookies-plain.db\n                                                 (env var: AGENTCOOKIE_PLAIN_COOKIES)\n                                              3. Per-CLI adapter fan-out:\n                                                   instacart  -> session.json\n                                                   airbnb     -> config.toml + cookies.json\n                                                   ebay       -> config.toml + cookies.json\n                                                   pagliacci  -> config.toml + cookies.json\n                                                   table-reservation-goat -> session.json\n\n                                              plus the secrets bus mirror:\n                                                ~\u002F.agentcookie\u002Fsecrets\u002F\u003Ccli>\u002Fsecrets.env  (mode 0600,\n                                                  optional sealed twin under the v0.12 master key)\n```\n\nThree cookie surfaces because different agents read cookies differently. Universal delivery (surface 1, the real Default profile plus the one-password Safe Storage open) is the default and is what makes any unmodified cookie tool work; the sidecar (surface 2) and per-CLI adapters (surface 3) are the agentcookie-aware paths that also work in degraded mode, when no login password is available to open the key. The sink runs all three after every sync, so the agent picks what fits.\n\nBearer tokens, API keys, and other per-CLI auth blobs ride the same encrypted push and land at `~\u002F.agentcookie\u002Fsecrets\u002F\u003Ccli>\u002Fsecrets.env` on the sink. CLIs read them via environment variables, the in-process `pkg\u002Fagentcookiesecret` Go library, or a project's own `agentcookie.toml` manifest (see the adoption standard below).\n\nNew cookie adapters are roughly 50 lines of Go and a `Register()` call; the runbook walks through it. New secrets bus consumers usually require no agentcookie-side change at all: drop an `agentcookie.toml` next to your CLI and `agentcookie discover` finds it.\n\n## Install\n\nPrereqs: Tailscale running on both Macs, Chrome installed, Go 1.22+ (or a pre-built release).\n\n```\n# On both machines:\ngo install github.com\u002Fmvanhorn\u002Fagentcookie\u002Fcmd\u002Fagentcookie@latest\n\n# On the first Mac (source):\nagentcookie wizard install --as source --peer \u003Csecond-mac-hostname>\n\n# It prints a pairing code. On the second Mac (sink), paste:\nagentcookie wizard install --as sink --peer \u003Cfirst-mac-hostname> \\\n  --code \u003Cpairing-code> --pair-url http:\u002F\u002F\u003Cfirst-mac-hostname>:9998\u002Fpair\n```\n\nThe sink wizard installs a LaunchAgent, opens Chrome Safe Storage for universal delivery with one login-password entry over SSH (no GUI click), and registers the five built-in adapters that fire after every sync. If no password is available (a fully non-interactive install with no `AGENTCOOKIE_LOGIN_PASSWORD`), it lands in degraded mode (sidecar + adapters) and prints the one-line `agentcookie wizard set-keychain-access` upgrade command. After install, all sync work runs unattended.\n\nSee [docs\u002Fquickstart.md](docs\u002Fquickstart.md) for the long-form walkthrough and [docs\u002Fquickstart-beta.md](docs\u002Fquickstart-beta.md) for the headless flow if you're installing the second Mac over SSH.\n\n## Verify it's working\n\n```\nagentcookie doctor                           # both sides' health\nagentcookie wizard verify-adapters           # per-adapter results from the last sync\nagentcookie wizard verify-adapters --json    # same, structured for SSH agents\n```\n\nTurn cookie sync off or back on for a site without editing YAML:\n\n~~~bash\nagentcookie accounts off x.com          # add x.com + subdomains to blocklist.yaml\nagentcookie accounts on x.com           # remove those blocklist entries\nagentcookie accounts list               # show disabled domains and custom patterns\n~~~\n\nHealthy output:\n\n```\nADAPTER                          STATUS  PUSHED  DETAIL\n-------                          ------  ------  ------\ninstacart-pp-cli                 ok      33\nairbnb-pp-cli                    ok      25\nebay-pp-cli                      ok      51\npagliacci-pp-cli                 skip            no matching cookies\ntable-reservation-goat-pp-cli    ok      36\n\nlast run: 4s ago\n```\n\n## Status\n\nmacOS only on both ends today. The source side reads Chrome on macOS via the Keychain-backed decrypt path; the sink relies on macOS LaunchAgent and Keychain conventions.\n\nWorking:\n\n- Continuous laptop to second-Mac sync via fsnotify on Chrome's Cookies file, debounced, blocklist filtered, AES-256-GCM over Tailscale.\n- Three cookie delivery surfaces on the sink (Chrome SQLite, plaintext sidecar, per-CLI adapter session files).\n- Works with Printing Press CLIs like Stripe, Linear, Notion, Granola, Slack, Kalshi, ElevenLabs, Mercury, and dozens more: anything with a bearer token or API key reads the secrets bus, anything that reads cookies reads the plaintext sidecar. Five PP CLIs (instacart, airbnb, ebay, pagliacci, table-reservation-goat with OpenTable + Tock) additionally get a bespoke zero-config cookie adapter.\n- Per-CLI secrets bus: bearer tokens, API keys, and `KEY=VALUE` auth blobs ride the same encrypted push and land at `~\u002F.agentcookie\u002Fsecrets\u002F\u003Ccli>\u002Fsecrets.env` (mode 0600) with an optional sealed twin.\n- `agentcookie secret list \u002F get \u002F set \u002F rm \u002F revoke \u002F import-from \u002F env` for managing the bus, and `pkg\u002Fagentcookiesecret` as an in-process Go reader library.\n- v2 adoption standard: drop an `agentcookie.toml` in your repo and `agentcookie discover` auto-detects it. Three integration tiers (explicit-manifest, pp-cli-derived auto-synthesized from `.printing-press.json`, and legacy v1 directories) coexist.\n- Tailnet-only listeners on both ends; pair endpoint rate-limited with a 64-bit code.\n- Persistent replay defense; per-peer pairing-derived keys.\n- Universal cookie delivery: one macOS login-password entry at install (no GUI click) opens the sink's Chrome Safe Storage key to any cookie reader via a partition list (`apple-tool:,apple:,teamid:\u003Cyour-team>`), so unmodified cookie tools (yt-dlp, gallery-dl, browser-driving agents, the Printing Press CLIs) read the real synced Default Chrome profile. Verified live on macOS 15.x.\n- Apple Developer ID signed binaries; the sink daemon reads Chrome Safe Storage via the `teamid:` partition (no per-binary trust list, no recreate of the key value).\n- Headless second-Mac install over SSH: one login-password entry, no GUI SecurityAgent click. A box with no password available installs in degraded mode (sidecar + adapters still work) and prints the one-line upgrade command.\n- `agentcookie doctor` runs fifteen health categories including cookie delivery (universal vs degraded, with duplicate-keychain-item race detection), binary signature + install, Tailscale, config, keystore, listener bind, sink\u002Fsource state, sealing posture, adapter coverage, CDP injector health, secrets-bus + secret coverage, and DBSC-suspect cookies.\n- 520+ unit tests across 26 packages.\n\nNot yet:\n\n- Python reader library at `clients\u002Fpython\u002Fagentcookie_secret` (planned; the Go reader ships today).\n- Signature verification on adoption manifests (`signed_by` field reserved; v2.1).\n- `[secrets.command]` and `[secrets.keychain]` source kinds (reserved; v2.1).\n- `agentcookie pair --rotate` for live key rotation. Today: re-run `wizard install` on both sides.\n- One first-Mac, many second-Macs fan-out.\n- At-rest sealing of the sidecar + adapter session files is wired in but off by default; turns on via `wizard set-keychain-access --enable-sealing` once consumer-side support lands.\n\n## What about Chrome's device-bound cookies (DBSC)?\n\nChrome's Device Bound Session Credentials (DBSC) tie a session to one machine's secure hardware so a stolen cookie cannot be replayed elsewhere. That is exactly the \"move a cookie to another machine\" shape agentcookie is built on, so it is worth being precise about what DBSC does and does not change here.\n\nDBSC is opt-in per site. A cookie becomes device-bound only when the site's own backend asks for it; nothing binds automatically, and a site binds only the specific session cookies it nominates. As of May 2026 the one broad adopter is Google's own account and Workspace cookies, and that protection went generally available on Chrome for Windows first. macOS support began rolling out gradually in the next Chrome release. The vast majority of sites agentcookie syncs, and every Printing Press CLI it feeds, do not use DBSC, so their cookies replicate to the second Mac and keep working exactly as before.\n\nFor a site that has adopted DBSC, a copied cookie works on the second Mac only until its short-lived window (minutes) lapses, because the second Mac cannot sign the refresh challenge that the source Mac's Secure Enclave holds. agentcookie does not try to defeat that. Instead the source flags cookies that look device-bound and, by default, ships them with a warning you can see in `agentcookie doctor`. Pass `--skip-dbsc-suspect` (or set `AGENTCOOKIE_SKIP_DBSC_SUSPECT=1`) to drop them instead of shipping cookies that will not survive on the sink.\n\nTwo things blunt the impact:\n\n- The secrets bus is untouched. DBSC is a cookie protocol. Bearer tokens, API keys, and OAuth refresh tokens that ride the bus to `~\u002F.agentcookie\u002Fsecrets\u002F\u003Ccli>\u002Fsecrets.env` are outside its scope and replicate normally.\n- For Google sessions specifically, copying cookies was never the right tool. Sign the second Mac's Chrome into the same Google account once and it establishes its own device-bound session there, no copy required. The agent on the sink reads that local session.\n\nIn short: DBSC narrows one corner of the web (today, mostly Google) and agentcookie is honest about it, while the bulk of what it syncs, non-DBSC site cookies and the entire secrets bus, is unaffected. See [docs\u002Fthreat-model.md](docs\u002Fthreat-model.md) for the full treatment.\n\n## Documentation\n\n| Doc | Use |\n|---|---|\n| [Quickstart](docs\u002Fquickstart.md) | install on a laptop + second-Mac pair |\n| [Architecture](docs\u002Farchitecture.md) | module layout, sync lifecycle, security boundaries |\n| [Protocol v1](docs\u002Fprotocol.md) | wire format spec for future client implementations |\n| [Threat model](docs\u002Fthreat-model.md) | what agentcookie does and does not protect against |\n| [FAQ](docs\u002Ffaq.md) | common questions |\n| [Headless quickstart](docs\u002Fquickstart-beta.md) | SSH-only install on a headless second Mac |\n| [v0.13 one-password keychain runbook](docs\u002Frunbook-v0.13-one-password-keychain.md) | universal delivery: the one-password Safe Storage partition open, the duplicate-item race + converge, and the unsigned-CGO boundary |\n| [v0.10 keychain runbook](docs\u002Frunbook-v0.10-keychain-access.md) | legacy sink Keychain ACL setup (superseded by v0.13 for the grant path) |\n| [v0.11 adapter runbook](docs\u002Frunbook-v0.11-adapter-cookie-push.md) | adapter mechanism + how to write your own |\n| [v0.12 security runbook](docs\u002Frunbook-v0.12-security-hardening.md) | sealed master key, tailnet-only listeners, rate-limited pairing |\n| [v0.12 codesign runbook](docs\u002Frunbook-v0.12-codesign.md) | Developer ID signing, notarization, CI secrets, renewal |\n| [Secrets bus v1 spec](docs\u002Fspec-agentcookie-secrets-bus-v1.md) | wire format and on-disk layout for non-cookie auth |\n| [Secrets bus v2 adoption spec](docs\u002Fspec-agentcookie-secrets-bus-v2-adoption.md) | `agentcookie.toml` manifest format and discovery rules |\n| [Secrets bus adoption runbook](docs\u002Frunbook-secrets-bus-adoption.md) | migrating a CLI from imperative `secret import-from` to manifest-driven sync |\n| [gh shim worked example](docs\u002Frunbook-secrets-bus-gh-example.md) | 50-line bash shim consuming the bus from a non-PP CLI |\n| [Install skill](skill\u002FSKILL.md) | Claude Code skill so an agent can drive the install |\n\n## License\n\nMIT.\n","agentcookie 是一个用于同步Mac之间会话状态的工具，特别适用于那些运行在非日常使用的Mac上的自动化代理。它能够持续地、加密地通过Tailscale网络同步Chrome cookies、CLI访问令牌、API密钥等认证信息，确保如OpenClaw或Hermes这样的代理程序在启动时已处于认证状态，无需额外的手动登录步骤。采用Go语言开发，支持点对点通信，不依赖云服务作为中间件，非常适合需要在多台Mac之间保持一致身份验证状态的场景，尤其是对于开发者和自动化运维人员来说，可以极大简化跨设备的工作流程。","2026-06-11 04:09:19","CREATED_QUERY"]