Clawdbot Persistent Session
A Clawdbot persistent session usually means one thing: your browser automation stays logged in across restarts. The foundation is a persistent Chrome profile directory (--user-data-dir) that lives on disk and is owned by the same service user every time.
Quick answer
- Persistent: cookies, local storage, saved sessions, and your browser login state — if you use a stable profile directory.
- Not persistent: ephemeral tab state and “whatever was open” unless you implement it explicitly.
- Most common failure: the browser is launching with a different
--user-data-dir(or a different OS user), so it looks like it “forgot” your login.
Common symptoms
- You must log in again after every restart/reboot.
- Automation works only when you run it manually (but not via systemd).
- Chrome starts, but CDP tools can’t connect (profile lock / port collision).
- Sessions persist sometimes, but “randomly” disappear (usually split-brain: root vs non-root).
What persistence means
When people say “persistent session,” they often mean “keep me logged in.” In practice, persistence happens at multiple layers:
- Browser persistence (Chrome profile): cookies + local storage + saved sessions. This is the big one.
- Gateway/console persistence (DATA_DIR): transcript, PM board, worklogs, uploads — durable state for the system itself.
- Auth profile persistence (.clawdbot): provider tokens, profiles, and tool credentials tied to HOME.
If any of those move (different user, different home, different data directory), persistence will appear to “break.”
Browser persistence: use a stable user-data-dir
To keep logins across restarts, Chrome must start with the same profile directory every time, and that directory must be writable by the service user that runs Chrome.
Known-good pattern
google-chrome \
--headless=new \
--remote-debugging-address=127.0.0.1 \
--remote-debugging-port=18800 \
--user-data-dir=/home/master/clawd/apps/console-data/chrome-profileVerify persistence is actually working
- Start Chrome with the profile directory.
- Log in once (interactive or via an operator flow that writes cookies).
- Restart Chrome.
- Confirm the session remains logged in.
Verify CDP endpoint
curl -s http://127.0.0.1:18800/json/versionGateway/console persistence: DATA_DIR matters
Your PM board, transcript, and worklogs should live in a single durable directory (commonly referred to as DATA_DIR). This is separate from browser session persistence, but both are required for long-lived, operator-grade reliability.
- If DATA_DIR is on ephemeral storage, you’ll lose state after reboot.
- If you have multiple DATA_DIRs (or multiple installs), you’ll read/write different “realities.”
Start with the high-level guide: Clawdbot User Guide.
Troubleshooting: when persistence fails
If your session doesn’t stick, the cause is usually one of these:
- Different OS user starts Chrome (root vs master) ⇒ different home, different permissions, different profile path.
- Different user-data-dir each run ⇒ you’re creating a new profile every time.
- Profile lock / singleton issues ⇒ another Chrome instance still holds the profile directory.
- Port collision ⇒ CDP port is already in use, automation connects to the wrong instance (or none).
- Snap sandbox oddities ⇒ Chrome/Chromium packaging causes inconsistent behavior; prefer deb install when possible.
Where to go next
- Two Brains Are Not Better Than One (split-brain root cause)
- Clawdbot debugging (CDP/ports)
- Clawdbot troubleshooting hub
Get Early Access!
Hosted Clawdbot + ClawdConsole workspaces are coming very, very soon.
Join the waitlist and we’ll spin up your workspace the moment access opens.
- Same operator cockpit you’re seeing here
- Private hosted workspace
- We’ll email you your link when it’s ready