How to Fix the Phantombuster "Expired Session Cookie" Error (2026)
Resolve from the console of the failing Phantom, then re-connect from its Setup page. And know the cause nobody suspects: switching IP, VPN or device mid-run invalidates the session.
You set the Phantoms running in the afternoon and come back to a row of Expired session cookie errors. Nothing scraped, nothing sent, and several hours of automation gone because a token quietly stopped being valid.
Renewing the cookie takes about a minute once you know where the button is, and most guides send you to the wrong place. The more useful part is why it expired, because one of the common causes catches people repeatedly and has nothing to do with LinkedIn logging you out: changing your IP address mid-run.
Why the cookie expired
A session cookie is proof that a browser somewhere is logged in as you. Phantombuster holds a copy so it can act on your behalf, and anything that invalidates the original invalidates the copy. Five things do that, and they leave different traces.
| Cause | How you recognise it | Prevention |
|---|---|---|
| You logged out, or were logged out | Failed at a moment you remember touching the account | Stay logged in while automations run |
| Session lapsed through inactivity | The account is one you rarely open yourself | Log in periodically to keep it alive |
| You switched IP, VPN or device | Failed while you travelled, or toggled a VPN | Do not switch mid-run, or set up a proxy |
| The platform reset the session for security | A security check or unusual-activity prompt appeared | Complete the check, then reconnect |
| Rate limits triggered a precautionary logout | Followed a burst of activity in a short window | Use safe behaviour settings, spread actions out |
The third row is the one that surprises people, and it is worth dwelling on. Toggling a VPN, moving between office and home, or picking up work on a laptop instead of a desktop can all invalidate the session while your Phantoms are mid-run. Nothing about it feels like an action against the account, which is why the resulting error looks random.
Reconnect in about a minute
The path matters here, because the obvious route through account settings is not the one that clears the error on the affected jobs.
Open the Phantom showing the error
Go to the specific Phantom that failed rather than to your global settings. The error is attached to the job, and the console for that job is where the recovery action lives.
Click Resolve in the console
The console offers a Resolve action on the session error. This is the step most write-ups skip, sending readers to paste a cookie into a settings page instead, which does not clear the error state on the jobs that already failed.
Re-connect the account from the Setup page
Follow through to the Setup page for that Phantom and re-connect the affected account. Make sure you are logged into that platform in the browser you are doing this from, otherwise you will hand it a session that is already stale.
Relaunch, at a lower rate than before
Resume the jobs. If the expiry followed heavy activity, drop the volume for a day or two before returning to your previous pace. A session that was ended for security reasons is a signal, not just an inconvenience.
Keep the session alive
Four habits cover almost every cause in the table above.
- Stay logged in while automations run. Logging out of the platform in another tab is the most direct way to kill a session your Phantoms depend on, and it is easy to do without thinking.
- Do not change network mid-run. If you use a VPN, keep it on or off for the duration rather than toggling. If you genuinely need to move between networks, set up a proxy so the automation's apparent location stays stable.
- Log into the account periodically. An account you automate but rarely open yourself will eventually lapse through inactivity. A weekly manual login costs nothing and keeps the session fresh.
- Use conservative behaviour settings. Rate limiting is not only about restrictions: a burst of activity can end the session outright, which looks like a cookie problem and is actually a volume problem.
Notice that three of the four are about your own habits rather than about configuration. A browser-held session is a shared dependency between you and the automation, and most breakages come from the human side of it.
For the other Phantombuster error that stops runs without being a Phantombuster problem, see how to fix profile out of network.
Sessions that are not yours to maintain
Every prevention tip above is a constraint on how you use your own computer. Do not log out, do not change networks, do not travel mid-campaign, remember to log in weekly. That is a strange set of rules to accept in exchange for a scheduled job running.
ReactIn holds the connection on our servers rather than in a browser you also use for everything else. Your laptop can be closed, your VPN can toggle, you can work from anywhere, and none of it touches a campaign, because the campaign was never depending on your machine's state.
It also removes the copy-a-cookie step entirely. There is no token for you to fetch, paste and refresh on a schedule, which is both less work and one less place for a credential to sit in a browser extension or a settings field.
To be clear about what does not change: LinkedIn can still challenge an account, ask for a verification code or restrict it if the activity looks wrong, and ReactIn does not and should not bypass any of that. When a platform asks you to confirm who you are, you confirm it. What server-side sessions remove is the everyday breakage from your own browser, not the platform's right to check.
For how the two products compare across the board, see our ReactIn vs Phantombuster comparison.
The cookie is not really the problem. The problem is that a scheduled job depends on the state of a browser you use for other things, and that dependency breaks in ordinary, unremarkable ways.
Frequently Asked Questions
Sources & Further Reading
- Phantombuster documents the recovery flow in how to fix expired or invalid session cookie errors.
- For the broader disconnection cases, see how to fix Disconnected by LinkedIn and other account disconnection errors.
- The initial setup is covered in how to connect your LinkedIn account to Phantombuster.
- Phantombuster keeps an index of common LinkedIn and Sales Navigator errors.
Related Articles
How to Fix Expandi Messages Not Sending (Pending Invites)
A connector campaign opens with a connection request, and a lead who already has one pending cannot receive a second. So the campaign has nothing it is allowed to do, and it says so in a tab most people never open.
How to Fix Phantombuster "Error During Loading of Chat Widget"
Phantombuster documents this one, and the documented fix is mostly to wait. The expensive part is a Phantom left looping against it, burning execution time on attempts that cannot succeed.
Working Around the Limitations on Salesflow (2026 Guide)
CSV import exists, so does a campaign type for contacts you already hold, and so do shared blacklists. The constraints that actually bite are narrower: rejected Sales Navigator URLs, per-route caps, and a deliberate block on duplicates.
How to Fix Dripify Lead Collection Stalls (2026 Guide)
Most stalled collections have finished or are waiting. The Lead Collection Report names the cause, the search cap ends runs silently, and working hours suspend lead loading as well as sending.