SESSIONS & CONTROL
Keep browser sessions with persistent Chrome profiles
Stopping Chrome can free memory without throwing away its cookies. Tallylamp uses persistent profiles by default, so an agent can return to the same saved browser state.
Stop and delete do different things
| Action | Effect on a persistent profile |
|---|---|
| Stop Chrome | Ends the browser process and keeps the profile on disk. |
| Idle timeout | Stops the process. A persistent profile remains available for later use. |
| Replace the container | Keeps saved data only if the same persistent volume is attached. |
| Delete the browser | Destroys its profile, including saved website state. |
Browser creation uses persistent: true by default. If you choose persistent: false, the idle expiry policy can also delete the profile. Use the persistent setting for a workspace you plan to revisit.
Keeping a profile does not keep Chrome running. After a stop or redeploy, Chrome can start again on the next use. Do not treat a saved profile as an uninterrupted task: check the current page before the agent resumes work.
Check persistence before relying on it
Choose a low-risk account
Create a browser with a clear project and purpose. Take control and sign into a site you are comfortable allowing the agent to use.
Stop, then reopen
Stop that browser from the dashboard. Reopen the same browser rather than creating another one, then visit the site and check the session.
Check the volume
On Railway, confirm the service has its persistent volume mounted at /data. Keep that volume attached across redeploys. With Docker, reuse the same named volume.
A saved cookie can still expire
Websites decide how long their sessions last. They may revoke one after a password change, request another verification, or reject a copied session. Tallylamp can keep the profile data; it cannot make another site's login permanent.
The signed-in-site inventory is an observation log. A confirmed entry means someone saw authenticated UI when it was recorded. Ask the agent to check the site again before relying on an older entry.
Name browsers for the work they hold
Choose Edit browser details to change the browser's name, project, purpose, or task. These details belong to the browser; you do not need to load a saved profile first. The action does not edit a saved snapshot.
Use Copy browser ID beside Browser ID on the browser page, or in the browser-list menu. The dashboard URL's /browsers/<id> segment contains that same ID. The name-derived slug is separate. Renaming the browser changes neither.
Names such as Research workspace or Staging account are easier to reuse than a series of untitled browsers. Record a project and purpose so both you and the agent can find the right profile without opening each one.
Keep unrelated accounts in separate profiles to reduce mistakes. They still share the deployment's container and Unix user, so use separate deployments when you need a stronger isolation boundary. Protect backups of the data volume as carefully as the live profiles.
Docs behind this guide
Based on Tallylamp's documented behaviour. See the source for API details and release-specific settings.