Who is agentcookie for?

Developers running browser agents on a separate Linux or Mac machine, who are comfortable with Tailscale, Chrome's debug port and editing YAML config files.

What can you build with agentcookie?

Run a browser agent on a cloud VM that can act on sites you are logged into on your Mac. Keep a homelab server's headless Chrome authenticated without pasting cookies by hand. Feed the same sessions to several agent machines from one Mac. Sync cookies from an existing Linux browser to another sink through its CDP endpoint. Limit what an untrusted agent box sees by syncing only chosen domains.

mvanhorn /

agentcookie

Syncs your Mac's Chrome logins to a Linux box so agents start already signed in

857 stars
14 stars since 3 Oct
Go
Updated 7 days ago
Some experience
Browser & computer use

Open on GitHub (opens in a new tab)

Agents often run on a different machine from the one you browse on, such as a cloud VM or a homelab server. That means logging in twice, once on your Mac and once where the agent lives, for every site. agentcookie removes the second login.

A source process on your Mac watches Chrome's Cookies file, decrypts the entries with the macOS Keychain, filters them by a policy, and seals them with a key made during pairing. It sends them over HTTPS on your Tailscale network. A sink process on the Linux box receives them and injects them into the running Chrome through the Chrome DevTools Protocol. New tabs and browser contexts get the cookies too.

It is one-way and unattended, unlike tools built for merging browser profiles between two laptops that a person uses. The README states the limits: Google and Workspace sessions bound to device keys (DBSC) stay logged out unless someone signs in on the box. On Linux the default policy ships nothing until you write a blocklist or allowlist.

What it does

Continuous Mac-to-Linux sync
Watches Chrome's Cookies file and ships changes as they happen, sealed with AES-256-GCM over Tailscale.
Live injection through CDP
The Linux sink sets cookies in a running Chrome via the DevTools Protocol, so Puppeteer, Playwright, browserUse or other Chromium tools see the session.
Cookie policy filters
Allowlist or blocklist files control which domains sync. Linux sinks accept nothing until you configure one.
Multiple sinks and pull mode
One source can push to several sinks. A sandbox that can't accept inbound traffic can poll the Mac with --pull-from instead.
Doctor and status commands
agentcookie doctor and status --json check the endpoint, the Tailscale bind address and the last push for each sink.

What you could build

Run a browser agent on a cloud VM that can act on sites you are logged into on your Mac.
Keep a homelab server's headless Chrome authenticated without pasting cookies by hand.
Feed the same sessions to several agent machines from one Mac.
Sync cookies from an existing Linux browser to another sink through its CDP endpoint.
Limit what an untrusted agent box sees by syncing only chosen domains.

Get started

Install Tailscale and Chrome on both machines, download the release binary for each, and start Chrome on Linux with --remote-debugging-port=9223. Run the wizard on the Mac, write sink.yaml and blocklist.yaml on Linux, pair with the printed code, then start the sink and check with agentcookie doctor.

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

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

agentcookie sink

Commands are copied from the project's README. Read it on GitHub for the full setup.