There's a Claude Code plugin that knows exactly where the "Renew Permit" button is on a municipal parking website — it's mapped every form field, every navigation path, every validation rule. It understands that you select "Residential Zone B" from a dropdown, upload a PDF of your registration, and click through three confirmation screens. But the moment it navigates to the login page, it hits a wall. There's no API key to hand it, no OAuth flow to trigger — just a username field, a password field, and a session that lives and dies in the browser.
Daniel's been building plugins like this, defining skills for Claude Code by mapping out the UI elements of websites that don't expose public APIs. The question he sent us is really three questions layered on top of each other. First, the mechanism itself — how do you get cookies out of a browser and into an agent's hands? Second, once you've done that, how durable is that authentication actually? And third, does anything out there approximate the refresh-token pattern from OAuth — prove authentication once, then use a token to maintain access indefinitely?
The central tension here is that the web was built for humans clicking around in browsers. Cookies were designed to remember that a human logged in, not to provide programmatic session material for an AI agent. And that mismatch — the cookie as a human convenience versus the cookie as an agentic credential — is where this whole thing gets interesting.
So let's start with the pattern itself — what does it actually mean to build a plugin that gives an agent a mental model of a website?
The way Claude Code plugins work, you define what are called skills — scoped actions the agent can take. And you do that by mapping the website's UI elements into a structured representation. Buttons, forms, dropdowns, navigation paths, validation states — all of it gets described in a way the agent can reason over. You're essentially giving it a floor plan of the interaction surface. "Here's where the login form lives, here's what happens when you submit it, here's the error state if the password is wrong, here's the page you land on after authentication."
The reason this matters quantitatively is that the vast majority of web functionality has no public API at all. Municipal services, internal corporate dashboards, legacy CRM systems, healthcare portals — these are interaction surfaces that exist only as browser-rendered HTML. There's no REST endpoint you can hit with an API key. The only way to interact with them programmatically is to simulate a browser session, and that means you need to be logged in.
Which brings us to the authentication paradox. A plugin can model every interaction on a site — every button, every form, every possible navigation path. But the very first thing any real session needs is a logged-in state. Without an API key or an OAuth flow, the agent has to borrow the user's authenticated session. And that means cookies — a mechanism designed for human browser sessions, not for programmatic access by an AI.
The agent can't just type in your username and password. Well, it could, technically — but storing credentials in a plugin configuration is a security nightmare, and many sites now use multi-factor authentication, CAPTCHAs, device fingerprinting. The login flow itself might be the hardest thing on the site to automate. So the cookie becomes the credential. Export it once, and the agent carries it around like a borrowed key card.
But before we can talk about keeping an agent authenticated, we need to understand what a cookie actually contains and how you get it out of a browser in the first place.
Let me walk through the export process concretely. In Chrome, you open DevTools, go to the Application tab, find Storage in the left sidebar, then Cookies, and there's an export button that dumps everything as JSON. Firefox has a similar path through about colon debugging, then Storage. Safari uses the Web Inspector under the Storage tab. Edge is the same DevTools as Chrome, same path. Every major browser gives you a way to do this, but it's always a manual step — there's no "export cookies for agent use" menu item anywhere.
Chrome stores its cookies in a SQLite database — on macOS it lives at tilde slash Library slash Application Support slash Google slash Chrome slash Default slash Cookies. Each record in that database has a specific set of fields: the cookie name, its value, the domain it belongs to, the path it's valid for, a secure flag that says "only send this over HTTPS," an httpOnly flag that prevents JavaScript from reading it, a SameSite attribute that controls cross-site request behavior, and the expiration date — if it has one.
And every one of those fields constrains where and how the cookie can be replayed.
Well, not exactly, but yes. The domain field means you can't take a cookie from parking-permits-dot-city-gov and use it on some other site. The path field narrows it further — a cookie scoped to slash admin won't be sent to slash public. The secure flag means your replay tool has to connect over HTTPS. The httpOnly flag means JavaScript can't touch it, which matters for how you inject it. And SameSite — SameSite equals Strict means the cookie won't be sent on cross-site requests at all, which can break your replay if you're not navigating from the right origin.
So you export this JSON blob. Now what? The import side is where the agentic keychain concept comes in. You'd store these cookies somewhere the agent can access, and then inject them into a browser emulator — Playwright, Puppeteer, a headless Chromium instance — before navigating to the target site. Playwright has a feature called storageState that does exactly this: you can save cookies and localStorage to a file, and restore them on the next run. The agent opens the browser context with those cookies already loaded, navigates to the site, and the server sees an authenticated session.
It's a snapshot, though. Not a live session.
That's the critical limitation. Session cookies — the kind that get set when you log in and have no expiration date — die when the browser closes. Not when the tab closes, when the browser process ends. Persistent cookies have explicit max-age or expires attributes. But here's the thing: many modern sites set short-lived cookies even for "remember me" flows. Fifteen minutes, thirty minutes, sixty minutes. A cookie exported at ten in the morning may be dead by ten forty-seven with no way to refresh it. You'd need to go back to the browser, log in again, export again, and feed the new cookie to the agent.
Forty-seven minutes of autonomous access, then a human has to intervene. That's the durability ceiling for a lot of real-world sites.
And there's a security boundary that makes this harder to automate than you'd think. Browser extensions cannot access the cookie store directly — the sandbox prevents it. The chrome dot cookies API exists, but it has restrictions: it can't read httpOnly cookies, and cross-origin access is blocked. So you can't write an extension that says "give me every cookie and I'll hand them to my agent." The export has to be manual through DevTools, or programmatic through the Chrome DevTools Protocol — CDP — which is a lower-level interface that debugging tools use. There is no standard "export all cookies for agent use" API anywhere in the browser ecosystem.
Contrast this with the public API world. OAuth2 access tokens typically last one hour. When they expire, the client uses a refresh token — which lives thirty to ninety days — to silently obtain a new access token. The user logged in once, maybe weeks ago, and the system keeps renewing access automatically. Cookies have no equivalent of a refresh token. Once the cookie expires, the agent is locked out until a human re-exports. This isn't a design flaw — cookies were never designed for programmatic access. They were designed so a website could remember that you, the human sitting at the keyboard, already typed your password.
Let me make this concrete with the parking permit example. You export your session cookie from the municipal site at ten in the morning. You feed it into a Playwright script using storageState. The agent navigates to the site, the server sees the cookie, and the agent successfully renews your permit — fills out the form, uploads the PDF, clicks submit, gets the confirmation number. Everything works. Then you check back at ten forty-seven. The agent tries to navigate to the permit status page to confirm the renewal went through, and the server returns a login redirect. The session cookie expired. The agent has no way to get a new one. It's stuck.
So we've got the cookie out of the browser and into the agent's keychain. The question is: how long will it actually work?
The honest answer is: it depends on the cookie, and the range is wide. A session cookie might give you hours if you keep the browser context alive — but the moment something restarts, it's gone. A persistent cookie with a thirty-day expiration gives you a month of access, assuming the server doesn't invalidate it early for other reasons — IP address changes, device fingerprint mismatches, suspicious activity detection. Some enterprise sites rotate session tokens every few hours regardless of the cookie's stated expiration. There's no standard behavior you can rely on.
So what tools exist to make this more durable? Playwright's storageState is the most commonly cited. It saves cookies and localStorage to a JSON file, and you restore it on the next run. But it's a static snapshot — it doesn't handle expiration, it doesn't refresh, it doesn't even warn you that the cookies are about to die. Puppeteer has a cookies API with the same limitation. These tools persist state, not sessions. They're great for reusing a session within its natural lifetime, but they don't extend that lifetime.
There's a pattern people try called session recycling — keep the session alive by periodically sending lightweight requests to the target site. A heartbeat ping to some endpoint that doesn't invalidate the session but resets the idle timer. The problem is this is fragile, site-specific, and can trigger anti-bot detection. If the site sees a request every nine minutes on the dot from an IP address that doesn't match the user's normal browsing pattern, that's a signal that something automated is running.
The closest thing to a refresh token in the cookie world comes from enterprise SSO systems. Okta and Azure AD can issue session cookies tied to a silent refresh mechanism — the browser re-authenticates using a stored token when the session cookie expires, all without the user seeing a login screen. But this requires the SSO provider's cooperation. It's an architectural feature of the identity layer, not something you can bolt onto an arbitrary municipal parking website. The site has to be integrated with the SSO provider, and the SSO provider has to support silent refresh. That covers maybe the top few percent of web applications.
And the sites Daniel's talking about — the ones without public APIs — are exactly the ones least likely to have SSO integration.
There's an emerging pattern worth watching: agentic credential vaults. Startups and open-source projects are building keychains that store not just cookies but the full authentication context. localStorage tokens, IndexedDB state, service worker registrations, even WebAuthn credentials. The idea is to reconstruct a session from its component parts rather than relying on a single cookie export. If the session cookie expires but the site also stored a long-lived token in localStorage, you might be able to use that to re-establish the session without human intervention.
The problem is this is deeply site-specific. Every web application stores authentication state differently. Some use httpOnly cookies exclusively. Some store JWTs in localStorage. Some use a combination with a refresh endpoint that expects specific headers and a CSRF token. Reconstructing a session from component parts means reverse-engineering each site's auth flow individually — which is exactly the kind of work a plugin could do, but it's not a general solution.
Let's talk about the security implications, because a cookie export is a powerful thing to have lying around. It contains everything needed to impersonate the user — the session token, CSRF tokens, authentication state. If you store these in an agentic keychain, you've created a new attack surface. Compare this to API token vaults like HashiCorp Vault or Doppler. Those have audit trails, rotation policies, time-bound access, scoping — you can grant an agent access to a specific API endpoint for a specific duration and revoke it at any time. Cookie stores have none of that. A cookie export is a bearer instrument — whoever holds it is the user, full stop.
And there's no revocation mechanism. With an OAuth token, the authorization server can revoke the refresh token and every access token derived from it dies within an hour. With a cookie, the only way to revoke access is to invalidate the session on the server side — which also logs out the human user. You can't selectively revoke the agent's access while keeping the human's session alive. They share the same cookie.
So to return to Daniel's core question with a precise answer: manually-exported cookie authentication is durable for the lifetime of the cookie. That's minutes to hours for session cookies, days to months for persistent cookies. But with no refresh mechanism, it is fundamentally less durable than OAuth2 with refresh tokens. And no general-purpose tool bridges this gap for arbitrary websites today. If the site doesn't offer an API, and it doesn't integrate with an SSO provider that supports silent refresh, you're stuck with manual re-export.
I want to be clear about something, because there's a misconception that cookies are just small text files you can copy anywhere and they'll work forever. They're not. They're tied to domains, paths, secure flags, and they have expiration dates. A cookie exported from Chrome on your laptop may not work when injected into a headless Chromium instance running in a data center — the server might see a different IP address, a different user agent, missing browser fingerprint signals, and reject the session. The domain and path constraints determine where the cookie can be replayed, and the server can impose additional validation beyond what the cookie itself declares.
Another misconception: that browser extensions can just read any cookie. They can't. The chrome dot cookies API has restrictions on httpOnly cookies and cross-origin access. Extensions can't touch httpOnly cookies at all — those are the ones most commonly used for session tokens, specifically because they're invisible to JavaScript. The export has to be manual through DevTools or done through the Chrome DevTools Protocol, which is a debugging interface, not a user-facing feature.
And the biggest one: that exporting cookies is the same as having an API key. It's not. API keys are designed for programmatic access — they have revocation mechanisms, scoping, rate limiting, refresh flows. Cookies are designed for human browser sessions and have none of those properties. No standard refresh mechanism, no scoping, no programmatic revocation. You're borrowing a human session and hoping it lasts long enough to do the work.
That question of durability — how long a session actually lasts — is something our producer Hilbert has some unexpected experience with.
Hilbert: You know, we had this exact problem fifteen years ago.
Hilbert: I was doing QA engineering at a company that built browser automation tools for enterprise CRM testing. This was the late two thousands — Salesforce was the big one, Siebel, Microsoft Dynamics. Our test scripts would log into these systems, run a few hundred assertions, and then the session would expire mid-test and everything would fall apart. Forty-five minutes of green checkmarks and then suddenly the whole suite is red because the login page came back.
Hilbert: We built this whole system called Session Shepherd. It would monitor cookie expiration times across every open browser context and proactively re-authenticate through the login flow before the session died. It kept a headless browser running in the background — well, headless wasn't really a thing yet, it was just a browser window minimized to the taskbar — and every twenty minutes it would navigate to the login page, fill in the credentials, submit the form, grab the new cookies, and distribute them to all the test contexts. It was janky as anything. The timing had to be tuned per site because some CRMs would invalidate the old session the moment a new login happened, and some wouldn't, and you'd end up with two sessions fighting each other.
It was essentially a human-in-the-loop bypass that predates modern agentic patterns by a decade.
Hilbert: A human had to set up the login flow once — record the sequence of form fills and clicks. After that it ran on its own. We had a library of login flows for about forty different enterprise applications. Salesforce changed their login page twice while I was there and both times it broke everything for a week.
Would that approach work for AI agents today?
Hilbert: It would, but it requires the agent to know the login flow. Which is exactly the kind of UI mapping Daniel's plugins are doing. The plugin that models the site's permit renewal workflow could also model the login workflow. Same pattern — identify the username field, the password field, the submit button, the error states, the post-login landing page. Once you've mapped that, re-authentication becomes automatable. The agent doesn't need the cookie to live forever. It just needs to know how to get a new one.
Hilbert: The funny thing is, nobody's really improved on that pattern since then. Session Shepherd was two thousand lines of Perl and a Firefox extension that barely worked. But the core idea — monitor expiration, re-authenticate proactively, distribute the new session — that's still what you'd build today. The tools are better, but the pattern hasn't changed.
That's actually a really interesting point, because it reframes the whole problem. The question Daniel's asking is "how do I make the cookie last longer?" But Hilbert's approach says "don't make the cookie last longer — just get a new one automatically."
Which means the plugin that models the site's functionality should also model its login flow. You're not exporting a cookie once and hoping it lasts. You're giving the agent the ability to re-authenticate on its own schedule.
Hilbert: The credential storage becomes the hard part. With Session Shepherd we just had a config file with usernames and passwords in plain text. That was acceptable for a test environment in two thousand nine. It's not acceptable for an agent that's running production tasks on real user accounts. You'd need something like a proper vault — and now you're back to the problem of storing credentials securely, which is what the cookie export was supposed to avoid in the first place.
Hilbert: We also learned the hard way that some sites notice when you log in from the same account every twenty minutes from an automated browser. We got IP-banned from a Siebel instance twice. The security team at that company was not amused.
The re-authentication approach works, but it surfaces the credential storage problem that cookie export was trying to sidestep.
It only works for sites where the login flow is automatable. If the site uses CAPTCHA, or hardware token MFA, or behavioral biometrics — the agent can't re-authenticate on its own. You're back to needing a human in the loop.
Hilbert: We had one client whose login page had a security question that changed every time. "What was your first pet's name?" one day, "What street did you grow up on?" the next. We had to build a lookup table of answers. It worked until someone changed their security questions and didn't tell us.
Hilbert: Anyway, the point is the pattern works where the login flow is simple enough to automate. For everything else, you're exporting cookies and racing the clock.
The pattern Hilbert's team built fifteen years ago is still relevant today. But it raises a bigger question about where this is all heading.
Here's what I think the misconception is that most people carry into this topic: they think cookies are just portable tokens — grab one, drop it anywhere, and you're authenticated forever. The reality is that cookies are session artifacts tied to specific browsers, domains, paths, and time windows. They're not credentials — they're evidence that a credential was presented at some point in the past. And the server gets to decide how long that evidence remains valid, on its own terms, with no obligation to tell you when it's about to expire.
The open question this leaves us with is whether the web is going to adapt. As AI agents become more autonomous, the pressure to solve this will grow. One possible path is browser vendors adding agent-friendly session management APIs — a "session delegation" standard where you can grant an agent a scoped, refreshable session without exposing your raw cookies. Another path is a new web standard for agentic refresh tokens that sites could opt into — something that sits between a cookie and an OAuth token, designed for programmatic browser sessions. Neither exists today. But the gap between what OAuth2 gives API consumers and what cookie-based auth gives agentic browser users is wide, and it's not closing on its own.
The thing that strikes me is that the Session Shepherd approach — re-automating the login flow — might actually be the more durable pattern in the long run. Not because it's elegant, but because it doesn't require any changes to the web. It works with every site that has an automatable login flow, which is most sites that don't use advanced bot detection. And as the UI mapping tools get better — as plugins get better at modeling login flows — the set of sites where this works grows.
We should thank Hilbert Flumingtop for producing, and for reminding us that the janky Perl script from two thousand nine is still the state of the art.
This has been My Weird Prompts. If you've got a question about how the internet's plumbing actually works — or doesn't work — email the show at show at my weird prompts dot com.
We'll be back soon.
