# agentcookie: Continuous Chrome session sync from a Mac to the Linux box your agent runs on

> agentcookie replicates Chrome cookies one way, continuously, from the Mac you browse on to a Linux sink over Tailscale, then injects them into Chrome through CDP. It is built for unattended agent VMs, not for sharing accounts between two people.

**mvanhorn/agentcookie** — 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.

- Repository: https://github.com/mvanhorn/agentcookie
- Stars: 839 · Forks: 70
- Language: Go
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/mvanhorn-agentcookie

## The problem: two logins per site, forever

An agent that runs on a Linux box (the README names a Grok Bot VM, a cloud agent runtime, or a homelab server) needs to act as you on sites where you are already logged in. The naive answer is to log in again on that box, once per site, and keep doing it as sessions expire. The README states the project exists to remove that second login. It is aimed at a single operator who browses on a Mac and runs agents elsewhere, and who wants the agent's Chrome to look authenticated without a human present.

The README draws a line against existing cookie-transfer tools. It says they assume a human will click merge, unlock a vault, or open the destination browser, because they were designed for switching accounts between two laptops used by the same person. agentcookie targets the other pattern: one-way, continuous, unattended replication from the Mac to the Linux box. That framing is the whole product. If a human is available to press a button, this is more machinery than you need.

## How the source watches Chrome and the sink injects cookies

The README's diagram splits the system into a macOS source and a Linux sink. On the source, fsnotify watches Chrome's Cookies file. When it changes, the source reads the SQLite database read-only, decrypts with the Keychain key, applies a cookie policy filter, wraps the result in an envelope, and seals it with a per-peer key derived at pairing. The envelope travels over HTTPS on the Tailscale tailnet, which the README describes as AES-256-GCM inside the tailnet's WireGuard channel.

The sink listens on a Tailscale address at port 9999 by default, decrypts the seal, filters again by policy, then attaches to Chrome through the DevTools Protocol and calls Storage.setCookies per browser context. There is no Keychain on Linux and no rewrite of Chrome's SQLite store: the sink injects into Chrome's in-memory cookie store. Injection happens on every sync and on every new browser context, so a fresh tab started by an agent inherits the session immediately.

The README is explicit about one boundary. Cookie-authenticated sites show the logged-in UI after live CDP inject, but Google and Workspace sessions stay logged out unless a human signed in on the box, because DBSC binds those sessions to device keys. That is a real limitation, not a configuration gap.

## Install agentcookie and complete a first sync

The README offers release archives per platform and a source build. The release page it links is tagged v1.0.0, and the archives follow a name pattern that includes the version and platform, such as agentcookie_1.0.0_darwin_arm64.tar.gz. The install section says to verify the download against checksums.txt before unpacking. The Go module path in go.mod is github.com/mvanhorn/agentcookie, and the README gives a tagged go install for building from source:

```bash
go install github.com/mvanhorn/agentcookie/cmd/agentcookie@v1.0.0
```

Prerequisites listed by the README: Tailscale running on both machines, Chrome installed on both, and on Linux Chrome started with --remote-debugging-port=9223 (or another port you configure).

On the Mac, the interactive wizard sets up the source and prints a pairing code and URL that the sink will use:

```bash
agentcookie wizard install --as source --peer <linux-tailscale-hostname>
```

The README shows output in the form of a pairing code like ABCD-EFGH-IJKL, a pair URL such as http://your-mac.tailnet:9998/pair, and a line saying it is waiting for the sink to pair. Keep that terminal open.

On the Linux sink, the README warns not to run wizard install --as sink, because the wizard omits the policy file, which it says means allowlist-empty and ships nothing. Write the YAML directly instead. The sink config names the listen address, the peer hostname, the live CDP endpoint, and skip_chrome_sqlite:

```yaml
listen:
  addr: 100.x.y.z:9999

peer:
  hostname: your-mac.tailnet

live_cdp:
  enabled: true
  endpoint: http://127.0.0.1:9223

skip_chrome_sqlite: true
```

Replace 100.x.y.z with the output of tailscale ip -4, and your-mac.tailnet with the Mac's Tailscale hostname from tailscale status. The README notes that if Tailscale re-auth gives the sink a new IP, the sink auto-rebinds to the new 100.x address on next start.

For a trusted single-operator box, the README's step four is a blocklist policy with an empty domain list, which means sync everything:

```yaml
version: 1
policy: blocklist
domains: []
```

Then pair the sink with the code and URL the Mac printed:

```bash
agentcookie pair --as sink \
  --peer your-mac.tailnet \
  --code ABCD-EFGH-IJKL \
  --pair-url http://your-mac.tailnet:9998/pair
```

Finally, the README says to probe whether Chrome is already listening on a debug port before starting a new instance, looping over ports 9223, 9222, 9224, 9228 and 9229 with curl against http://127.0.0.1:${port}/json/version. What you should see after a sync is the agent's browser already logged in on cookie-authenticated sites, with no auth login step.

## Where agentcookie stops working

The DBSC boundary is the first hard limit. Google and Workspace sessions will not carry over, because those sessions are bound to device keys and the README says a human has to sign in on the box. If your agent's job depends on a Google account, agentcookie does not solve it.

The sink configuration is the second trap. The README states plainly that wizard install --as sink omits the policy file and that this produces an allowlist-empty state which ships nothing. A reader who runs the wizard on Linux and then wonders why no cookies arrive has hit a documented dead end. The fix is manual YAML, which means the sink setup is not a one-command experience.

The empty-domain blocklist is a third consideration. The README presents it as the right choice for a trusted box, and it is: it syncs every cookie. On a machine you do not fully control, that is the wrong default, and the project provides allowlist and blocklist policy modes to narrow it. The README also does not document rollback, so if a bad sync lands on the sink, there is no documented procedure for undoing it.

Finally, this is macOS to Linux. The README describes the source as a Mac with Keychain and the sink as a Linux box with no Keychain. There is no Windows path in the README, and no cloud relay: the transport is your Tailscale tailnet, so both machines must be on it.

## How it differs from a vault-style cookie transfer tool

The obvious alternative is a cookie manager or vault that exports and imports browser sessions. The README describes that class of tool as built for switching accounts between two laptops the same person uses, and as requiring a human to merge, unlock, or open the destination browser. The difference is not encryption strength. It is who is present when the transfer happens.

A vault tool is pull-oriented and human-triggered: you decide when a session moves, and you are there to approve it. agentcookie is push-oriented and event-driven: fsnotify fires on the Cookies file, the diff is sealed and sent, and the sink injects it without anyone watching. That makes it suitable for an agent that needs a session in thirty seconds with nobody home, which is exactly the scenario the README names.

The cost of that design is trust surface. A vault keeps a human in the loop; agentcookie removes the loop by design. The README's answer is pairing-derived per-peer keys and policy filters on both sides, plus the Tailscale tailnet as the only network path. Whether that is enough depends on the sink box, and the README itself treats the sink as a trusted single-operator machine.

## Maintenance, upgrade cost and the MIT licence

The repository is not archived and the last push was on 2026-09-10, so it is current. Releases are frequent: v0.17.1 on 2026-06-18, v1.0.0 on 2026-08-14, and v1.1.0 on 2026-08-24. The Makefile documents the build pipeline, and it is more involved than a plain go build if you distribute binaries. Targets include build, sign, notarize, release and verify, with the comment that notarization takes 5 to 30 minutes and is required before deploying to a Mac other than the one the build ran on. Build alone does not require an Apple Developer ID; signing is split into make sign so contributors can build and test without a certificate. The signing identity can be overridden with AGENTCOOKIE_SIGN_IDENTITY.

Upgrade cost on the sink is low: the binary is a single Go executable, and the config is two small YAML files. The version is injected at link time, and the Makefile notes that goreleaser uses the same -X ldflag, so release binaries and local builds report the same tag format.

The project is MIT licensed. That is permissive: you can use, modify and redistribute it, including in closed products, provided the licence text and copyright notice are kept. The README describes no separate commercial tier and no network-service clause. This is a description of the licence identifier, not legal advice; read LICENSE in the repository if your situation is unusual.

## Conclusion

Adopt agentcookie if you run OpenClaw, Hermes, browserUse, Puppeteer or Playwright on a trusted Linux box that acts as you, and you already have a Tailscale tailnet plus a Mac as the cookie source. Skip it if you need Google or Workspace sessions on the sink, if the sink is a shared or multi-tenant machine, or if you want the wizard to configure the sink for you: the README says the sink wizard omits the policy file, so write sink.yaml and blocklist.yaml by hand. Before rolling it out, confirm Chrome on the sink is listening on the debug port you configured, and decide whether the default blocklist policy with an empty domain list is acceptable for that box.

## FAQ

### Does agentcookie sync Google or Workspace logins to the Linux box?

No. The README states that Google and Workspace sessions stay logged out unless a human signed in on the box, because DBSC binds those sessions to device keys. Cookie-authenticated sites are the ones that show the logged-in UI after live CDP inject.

### Why does the sink wizard ship no cookies?

The README says not to run wizard install --as sink on Linux because the wizard omits the policy file, which leaves an allowlist-empty policy and ships nothing. The documented workaround is to write sink.yaml and blocklist.yaml by hand and then run agentcookie pair --as sink.

### What does Chrome on the Linux sink need to be started with?

The README lists --remote-debugging-port=9223 (or another port you configure) as a prerequisite, and the sink config points live_cdp.endpoint at http://127.0.0.1:9223. The sink injects cookies into Chrome's in-memory store over the DevTools Protocol, so it does not rewrite Chrome's SQLite database.

### What transport does agentcookie use between the Mac and the Linux box?

The README describes HTTPS over the Tailscale tailnet, with AES-256-GCM sealing inside the tailnet's WireGuard channel, and per-peer keys derived from pairing. There is no cloud middleman in the path.

### How do I build agentcookie from source?

The README gives go install github.com/mvanhorn/agentcookie/cmd/agentcookie@v1.0.0 for a tagged build. The Makefile also defines make build for a local binary, with signing and notarization as separate targets.

## Sources

- [Issues](https://github.com/mvanhorn/agentcookie/issues)
- [License: MIT](https://github.com/mvanhorn/agentcookie/blob/main/LICENSE)
- [mvanhorn/agentcookie on GitHub](https://github.com/mvanhorn/agentcookie)
- [README](https://github.com/mvanhorn/agentcookie/blob/main/README.md)
- [Releases](https://github.com/mvanhorn/agentcookie/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mvanhorn-agentcookie