A few weeks ago, I kicked off a big agentic job. I tasked it to build a dummy exchange so I could test messaging from the Dagenta Trading Platform that I’m building. A big job traversing a lot of Linear Issues (i.e. work packages) that would take some time.

Then my attention drifted. It was almost home time. Distracted, I closed my laptop and left the office.

The next morning, I realised what I’d done and opened the laptop to see that Claude had stopped the very instant I closed my computer. No pushes, no diffs, no further activity at all.

The agent didn’t fail here, the session did.

This is totally expected behaviour, and it’s triggered by more than just a laptop close. Moving WiFi networks, changing VPN connections or dropping off of sandboxes can all do the same thing.

As agents move from 30-second completions to 45-minute autonomous runs, we’re still hosting them on the most portable, frequently suspended machine we’ve got.

You wouldn’t run a migration from a laptop on a train. Stop running your agent there, too.

For many, Claude Code on the web, or Cursor cloud agents, solve exactly for this. Anecdotally, a lot of online chatter suggest agents-in-the-cloud will rapidly become the de facto modus operandi of agentic work. It does seem relatively obvious as an idea.

They might not be the right answer if you have privacy constraints, however. If you run in your own VPC, or use private package registries, or are working from a repo that can’t leave your network, as examples.

At the same time, unless you’re using the API and have enough money for elevated token costs, you’re probably running Claude or Cursor in a subscription model.

What you need is a way to both not turn off your session when you’re not directly running the compute layer but preserve that subscription usage.

Caveat 1: do remember never to run Claude in —-dangerously-skip-permissions on real data or infrastructure. Get yourself a shadow environment dataset and make triple sure any perms your box has are bulletproof.

Caveat 2: it’s your responsibility to ensure you’re aware of the T&Cs of your AI service, including any risks you might be taking against their stated terms and conditions about automated usage of subscription accounts.

tmux is a terminal multiplexer that creates sessions running on servers and ensure they keep running when your SSH client goes away.

At Temrel, we routinely run Claude using tmux on ephemeral AWS EC2 servers, but any cloud provider will do.

Three commands are 90% of it:

tmux new -s claude to create a new tmux session called ‘claude’.

ctrl-b d to detach the session (that’s ctrl+b then d on its own).

tmux attach -t claude to come back to it.

Assuming you’ve already got an EC2 box up and running (instructions not included here), getting back to a session is simple:

Reach the box using
aws ssm start-session —target i-<your_instance_id>.

Get back into your tmux session using tmux new-session -A -s claude. This will either create the new session or attach if it already exists.

tmux ls reminds you of what sessions are running, if any. You can read the last 500 lines via tmux capture-pane -pt claude -S -500.

The rub is logging in. You shouldn’t try and do this programmatically. You might risk your account with your AI provider (they don’t like this kind of automation).

You can forward the port back to your laptop, or do what we do and take three seconds to manually copy the login code to the local browser and then copy back the authentication code that your provider gives you.

This task is one-and-done at the start of your session. Easy peasy.

Running Claude in dangerously-skip-permissions or bypassPermissions modes (aka Bypass mode) used to be the way to launch it on sandboxed environments. Now we have Auto mode. Think of it like this:

Auto mode replaces you as the reviewer.

Bypass mode doesn’t have a reviewer.

Auto mode is now default on Pro, Max and Team plans for Claude Code (v2.1.228+ on Linux/macOS/WSL and v2.1.233+ on Windows).

I haven’t fully experimented with it on ephemeral, long-running boxes, so DYOR. With Bypass mode on sandboxed environments, I haven’t yet had any problems.

Assuming you’re now in a tmux session, you’re now going to launch Claude Code.

Run either claude --permission-mode auto or claude -—dangerously-skip-permissions to get your instance running.

You can allow dangerously-skip-permissions without actually starting in that mode via claude -—allow-dangerously-skip-permissions. You’ll need a manual shift-tab in-session to activate this mode, then.

You can also set the permissions mode by default via permissions.defaultMode in .claude/settings.json. If you ask me, though, this is a disaster waiting to happen. Much better to manually decide each time.

Accept the Claude Code startup dialog once, interactively, before you ever detach. Non-interactive runs show no warning dialog, and a --bg session is refused until you have accepted it in an interactive session. Your beautifully automated bootstrap will otherwise sit there doing nothing.

SSM starts you as ssm-user. Get a login shell as the right non-root user (sudo -i -u ec2-user) rather than running the agent under sudo, which the binary refuses outright: --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

What does Anthropic say about using subscriptions in this way? It’s important not to fall foul of the T&Cs.

OAuth sign-in is "intended exclusively for purchasers of Claude Free, Pro, Max, Team, and Enterprise subscription plans and is designed to support ordinary use of Claude Code". You, signing into an unmodified binary on a box you own, for your own work, is exactly that.

Anthropic addresses hosted setups head on: nothing there prevents "an end user from signing in to the unmodified Claude Code binary with their own Claude subscription"

Where you need to be careful: Anthropic also state that "advertised usage limits for Pro and Max plans assume ordinary, individual usage of Claude Code and the Agent SDK."

Detached mode makes it easy to stop being ‘ordinary’ and ‘individual’ without noticing. Proceed at your own risk, therefore. Avoid running Claude on ephemeral EC2 in prompt mode like this:

claude -p “<your_prompt>”

Furthermore, what you should categorically not do is offer this as a service to other people. Anthropic "does not permit third-party developers to offer Claude.ai login into their own applications, or to route requests through Free, Pro, or Max plan credentials on behalf of their users".

No collecting, storing or intermediating credentials or session tokens either.

A rule of thumb is one human, one subscription, one box. The moment anyone else’s prompt runs on your machine, you need to switch to the API key mode.

Link: Claude Code legal and compliance

As mentioned, we must constrain the environment that the box runs in. Ephemeral boxes, finely-scoped IAM roles and git tokens that reach exactly one repo will all help do this. Use SSM, don’t SSH directly onto open port 22.

Autonomy is cheap. The blast radius you configure is what costs you.

It’s as cheap as chips, as we say in the UK. You’re renting a shell, not a GPU. Inference happens on Anthropic’s side, so the box can be relatively lightweight. Try either of these two instances:

An overnight 8-hour run on a t3.large costs 77 cents. Leaving that same box idling all month costs $70.08. The agent is not the expensive part. The forgetting is, so ensure you have a mechanism to kill idle boxes.

For Dagenta, we at Temrel created a dedicated, sandboxed environment augmented by EBS storage volumes with an automatic tear-down 48h after the last human interaction. This doesn’t count machine activity, only human, so a forgotten long-running Claude won’t keep it alive.

It’s really cost-effective. A t3.xlarge is the "I am running a real test suite" tier at $1.54 a night, it’s less than an americano in a Parisian café.

Storage rounds to nothing at $1.43 a month, but remember that EBS bills per GB-month whether or not the instance is running. It is the one cost line that survives your shutdown schedule.

The industry is racing to sell you hosted agent runtimes, and they are good. The primitive underneath is a session that outlives your terminal, and that has been free and boring for twenty years.

Detached Mode is a habit change more than a tech change. Once the agent's life is decoupled from your laptop's, you start giving it work you would never have started at 4:55pm.

Your laptop, a hosted cloud agent, or a box you own? And if you have gone self-hosted, what broke first?

See you next week.

Ben