Your AI session dies with the laptop, and the transcript will not bring it back
Two different things get called persistence. Only one of them is the thing that breaks when you shut the lid.
You have long-running agent or terminal sessions on a laptop. You want to go away for two weeks, switch the laptop off, and still reach that work from a phone. Nothing about this is exotic, but the first attempt usually solves the wrong problem.
Two different things called persistence
Ask what actually breaks when the machine powers down, because the answer splits in two.
The transcript is a file on disk. It survives a shutdown perfectly well. It is still there when you come back, and it is not what you are losing.
The session is a running process holding context, open tools and a working directory. That dies with the machine, and no amount of history syncing recreates it.
If you diagnose this as a sync problem you will spend a day shipping transcripts around and still have nothing running. The process is the thing. Move the process.
Put the process where the power is
If you already run a server, that server is the answer. It is always on, it is already next to your databases and containers, and it does not sleep when you shut a lid. Running the session there means the laptop becomes a screen rather than a dependency, which is the actual goal.
The obvious objection is reachability. A process on a server is not much use if you can only talk to it from a terminal.
Outbound control beats an open port
The old answer was a terminal multiplexer over SSH, and it still works. The better answer, where your tooling supports it, is a control channel the process opens itself.
The process makes an outbound HTTPS connection to a coordination service and polls for work. Your phone or browser talks to that service, which routes messages back down the connection already established. You open no inbound ports, you punch no holes in a firewall, and it works from behind NAT without any of the usual tunnelling.
This is the same shape as a build runner or a monitoring agent checking in. Anything that phones home rather than waiting to be called avoids the entire class of problems that comes with exposing a service.
Supervise it, because it will exit
These channels are not indefinitely patient. A common design gives up after a short network outage and exits the process rather than hanging forever in an unknown state, which is correct behaviour and also means a brief blip leaves you with nothing running.
Run it under your service manager with an unconditional restart and a short delay. That covers the network blip, the process crash and the reboot in one line of configuration, and it is the difference between a setup that survives a fortnight unattended and one that survives until the first hiccup.
Starting a service proves it runs. Only enabling it at boot and then actually rebooting proves it comes back. These are separate things and people routinely ship the first believing they did the second.
The trap: prompts nothing can answer
Interactive tools guard themselves with first-run prompts. Trust this directory. Accept these terms. Confirm this workspace. Every one of those is fine when a human is at a keyboard and fatal when a service manager starts the process at boot, because there is no keyboard and the prompt blocks forever or the process exits.
Before you automate the start, run the thing by hand once in the exact directory and as the exact user the service will use, and clear every prompt. Then check that the acceptance was written somewhere persistent rather than held in memory for that session only. This is the single most common reason a service that works when you start it by hand does nothing at boot.
Expect more than one gate. Tools of this kind often have several, asked at different moments and stored in different places: one to trust the directory, another to consent to the feature itself. They are not presented as a list, so clearing the first simply reveals the second on the next run, and the failure looks identical each time. A service that starts and immediately reports a clean exit, with no error and nothing in the log but a question, is almost always sitting on a prompt rather than suffering a fault.
Note where each acceptance lands, too. Some are recorded against the working directory and some against the whole machine, so clearing one for a directory tells you nothing about whether the other will need clearing again elsewhere.
The reliable test is not whether you answered the prompts. It is whether the service manager can start it from cold without you present. Until you have seen that, you have not finished.
Count the new blast radius
This is the part worth thinking about before you enable it rather than after.
You have just connected an account login to a shell on a machine that runs things that matter. Whatever that account was worth to an attacker yesterday, today it is worth a session on that server, reachable from any browser. The credential did not get weaker; the room behind the door got considerably bigger.
That is not a reason to avoid the pattern, it is a reason to put multi-factor authentication on the account, and to think twice before turning off the permission prompts that make the agent ask before it acts. Approving from a phone is mildly annoying. It is also the only thing standing between a compromised login and an unattended root shell.
Back up the sessions, never the credentials
Once the work lives on the server, the session store is business data and belongs in the backup you already run. Fold it into the existing job so it inherits the retention and the alerting rather than becoming a second thing to remember.
Exclude the credential file explicitly. It is a live token, re-authenticating costs nothing, and the one thing you do not want is your active credentials sitting in offsite storage for the next thirty days. Verify the exclusion by listing the archive rather than trusting the pattern you wrote.
The general shape
When something breaks because a machine went away, separate the state from the process. State is usually fine and usually not the problem. The process needs a host that stays up, a way to be reached that does not require inbound access, a supervisor that restarts it, and a non-interactive first run. Get those four right and the laptop becomes optional, which is what you wanted in the first place.
Need help with any of this?
These notes are free and always will be. If you would rather someone just set it up, or you are stuck on something similar, get in touch at hello@opsira.io.