agentcookie: one-way Chrome cookie replication from a Mac to an agent box
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.
At a glance
- What is it?
- agentcookie is a Go CLI that watches Chrome's cookie database on a Mac and pushes changes to a Linux sink over Tailscale, where they are injected into a running Chrome through the DevTools Protocol. It is built for unattended agent runtimes, and its own documentation warns that the sink wizard path on Linux is a trap.
- Who is it for?
- Adopt agentcookie if you run an agent on a trusted Linux box that you control, you already have Tailscale on both machines, and you accept that cookie-authenticated sites will work while Google and Workspace sessions will not unless a human signed in on the sink. Do not adopt it for a multi-tenant agent host, for Windows, or for anything where the sink box is not yours.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The double login problem agentcookie targets
The README states the problem directly: logging in twice, once on your Mac and once again on the Linux box where your agent runs, per site, forever. The stated target is an agent on a Grok Bot VM, a cloud agent runtime, or a homelab server that has to act as you on sites where you are already logged in. The existing tools in this space, according to the README, assume a human will click merge, unlock a vault, or open the destination browser. That assumption holds when one person is moving accounts between two laptops. It fails when nobody is home and the agent needs the session in thirty seconds. agentcookie takes the second pattern: one-way, continuous, unattended replication from the Mac you browse on to the Linux box your agents act from. Note the direction. This is not bidirectional sync and not account switching. It is a one-way feed, which is a narrower promise than most cookie-transfer tools make and a more honest one for the agent case.
What actually moves, and what does not
The mechanism is a pipeline, not a file copy. On the Mac, fsnotify watches Chrome's Cookies file. The source process reads the SQLite database read-only, decrypts with a Keychain key, applies a cookie policy filter, wraps the result in an envelope, and seals it with a per-peer key derived at pairing. That sealed payload travels over HTTPS on the Tailscale tailnet, with AES-256-GCM. The sink decrypts, applies its own policy filter, attaches to Chrome over CDP, and calls Storage.setCookies per browser context. There is no Keychain on Linux and no rewrite of Chrome's SQLite store on the sink. Injection is into Chrome's in-memory store. The README says the inject happens on every sync and on every new browser context, so an agent that opens a fresh tab inherits the session. The boundary is DBSC. Google and Workspace sessions stay logged out unless a human signed in on the box itself, because device-bound session credentials bind those sessions to device keys. That is not a bug to be filed. It is the shape of the thing: non-DBSC sessions replicate, DBSC sessions do not.
Pairing, config files and the Linux wizard warning
Installation is a release archive plus a checksum check, or go install github.com/mvanhorn/agentcookie/cmd/agentcookie@v1.0.0. Prerequisites are Tailscale on both machines, Chrome on both machines, and Chrome on Linux started with --remote-debugging-port=9223 or another configured port. On the Mac the source runs agentcookie wizard install --as source --peer <linux-tailscale-hostname>, which prints a pairing code and a pair URL such as http://your-mac.tailnet:9998/pair. The README then contains an instruction that deserves to be read twice: do not run wizard install --as sink on Linux, because the wizard omits the policy file, which means allowlist-empty and ships nothing. Instead you write three files by hand. sink.yaml holds listen.addr (your Tailscale 100.x address and port 9999), peer.hostname, live_cdp.enabled, live_cdp.endpoint, and skip_chrome_sqlite: true. blocklist.yaml holds version: 1, policy: blocklist, and an empty domains list for sync-all on a trusted box. Then agentcookie pair --as sink with --peer, --code and --pair-url. The README also notes that if Tailscale re-auth changes the sink IP, the sink auto-rebinds to the new 100.x address on next start. A silent empty-policy default on the sink path is the kind of failure that looks like a network problem for an hour, so the manual route is the correct one.
Where the design stops being the right tool
The README frames the sink as a trusted single-operator box, and that framing is load-bearing. Everything that reaches the sink is injected into whatever browser context asks for it, so a shared agent host turns one person's live sessions into a resource available to every workload on that machine. There is no per-agent identity in the described flow. The platform constraint is just as sharp: the source side depends on macOS Keychain and Chrome's App-Bound Encryption, so this is a macOS-to-Linux tool, not a Linux-to-Linux or Windows-to-anything tool. The sink depends on Chrome running with a debug port open, which is a browser you should not also be using for personal browsing. The DBSC exclusion means the sites most people care about for agent work, Google properties among them, are exactly the ones that will not transfer. If your agent's job is Gmail or Google Docs, this tool does not solve your problem and the README says so. And because replication is continuous and unattended, a cookie you logged out of on the Mac propagates the change to the sink rather than leaving a stale session behind, which is the correct behaviour but also means there is no undo window.
How it differs from vault-style cookie transfer tools
The obvious comparison is a cookie manager or vault extension that exports a session and imports it on another machine. Those tools are pull-based and human-triggered: you export, you carry the file, you import, and the session is a snapshot that ages. agentcookie is push-based and event-driven. fsnotify fires on the Mac's Cookies file, the diff ships, the sink injects, and the loop repeats without a person in it. The second difference is the transport. A vault tool typically moves an encrypted blob through a cloud account or a file you copy by hand. agentcookie rides the Tailscale tailnet and seals with a pairing-derived per-peer key, so there is no cloud middleman holding the payload, and the README explicitly lists that as a property. The third difference is the destination. Vault tools target a browser profile on disk. agentcookie targets a live Chrome over CDP, which is why an agent that opens a new context gets the session immediately rather than after a browser restart. If you only need to move a session once, a vault tool is less machinery. If you need an unattended box to stay authenticated across days, the snapshot model is the wrong shape.
Maintenance surface and licence terms
The maintenance cost here is mostly environmental, not code. Two machines must keep Tailscale up, the sink must keep Chrome alive with the debug port open, and the sink's listen address must track the Tailscale IP, which the README says it re-resolves on start. The source side depends on macOS Keychain access and on Chrome's App-Bound Encryption continuing to work the way the source expects, so a Chrome change that alters that encryption is a breaking event for the source, not a config tweak. The release history shows v1.0.0 in August 2026, v1.1.0 later that month, and a v0.17.1 before the 1.0 line, which suggests an active project rather than a frozen one, but the README does not describe a migration or upgrade procedure, so treat upgrades as a re-pair-and-retest event until you confirm otherwise. Licensing is MIT, which permits commercial use, modification and redistribution with the copyright notice and permission notice retained. That is a permissive grant, not legal advice, and it says nothing about the terms of Tailscale, Chrome or the sites whose cookies you are replicating. Those are separate agreements and worth reading before you point this at a production account.
Editorial conclusion
Adopt agentcookie if you run an agent on a trusted Linux box that you control, you already have Tailscale on both machines, and you accept that cookie-authenticated sites will work while Google and Workspace sessions will not unless a human signed in on the sink. Do not adopt it for a multi-tenant agent host, for Windows, or for anything where the sink box is not yours. Before trusting it, verify three things on your own machines: that Chrome on the sink answers on the debug port you configured, that your sink.yaml addr matches the output of tailscale ip -4, and that blocklist.yaml exists with policy: blocklist and an empty domains list, because the README states the Linux wizard omits the policy file and an allowlist-empty policy ships nothing.
Community notes