How do you make your Windows laptop run Claude on a closed laptop forever
How I turned an ordinary Windows laptop into an always-on Claude Code server that I run from my phone, without walking back to the keyboard.
Windows 11, Ubuntu on WSL2, Claude Code 2.1
I have a Windows laptop that spends most of its time with the lid shut. Until recently that meant it was asleep. Now it's where my Claude Code sessions run, and I start them from my phone, from claude.ai in a browser, from wherever I happen to be.
The idea was simple: I never want to touch that terminal again. Getting there took one morning and more small surprises than I expected. Some settings were quietly working against me, a couple of commands meant something different from what I thought, and at one point Claude itself refused to do a step for me (more on that later, because it was the right call).
This is everything I did, in order, including the parts that went wrong.
What you'll need
- A Windows 10/11 laptop with WSL2 and an Ubuntu distro installed
- Claude Code installed inside Ubuntu (claude --version should work)
- A Claude account that can use Remote Control, plus the Claude mobile app or claude.ai/code
- Admin rights on Windows, for two clicks near the end
1. Stop Claude asking for permission
If you're going to drive this from a phone, every "Allow this command?" prompt is a small interruption. I wanted Claude to be able to read, write and run things without checking in each time, so I added an allow list to my user settings. These apply across every project.
{
"permissions": {
"allow": [
"Read", "Edit", "Write", "NotebookEdit",
"Glob", "Grep", "Bash",
"WebFetch", "WebSearch"
]
}
}MCP tools (the connectors to other services) aren't covered by those names. Each server needs its own rule in the form mcp__<server-name>, which allows every tool on that server. I added one line per connector I use.
Be honest with yourself
Allowing all of Bash means any shell command runs without asking, rm -rf included. That's a trade I'm happy to make on a personal machine. If you're not, add a "deny" list for the commands that scare you, like "Bash(rm -rf *)".
2. Make sure the laptop actually stays awake
I thought I'd already done this. I'd set Windows to "never sleep", and the first time I checked from my phone the machine had only been up for fifteen minutes. Windows had rebooted overnight, very likely for an update.
So I checked what the power plan was really doing. You can run Windows commands straight from WSL by adding .exe:
$ powershell.exe -NoProfile -Command "powercfg /query SCHEME_CURRENT SUB_SLEEP STANDBYIDLE; powercfg /a"
Current AC Power Setting Index: 0x00000000 # never, plugged in
Current DC Power Setting Index: 0x000000f0 # 240 s on battery
The following sleep states are available on this system:
Standby (S0 Low Power Idle) Network ConnectedThat told me three things:
- Plugged in, it never sleeps. Good.
- On battery, it sleeps after four minutes. If the charger ever slips out, I lose the machine almost straight away.
- It uses Modern Standby (S0 Low Power Idle). These laptops can drift into a low-power state with the lid shut even when sleep is set to "never".
Two settings fixed most of it:
- Control Panel → Power Options → Choose what closing the lid does → set Plugged in to Do nothing.
- Settings → Windows Update → Advanced options → set active hours so update reboots happen when you're asleep, not in the middle of a session. Step 6 makes reboots harmless anyway.
With everything set, I ran a quick health check with the lid closed on the charger. It ran at 109% of base clock (turbo still active, no thermal throttling), 2.1 GB/s disk writes, and CPU sitting around 13%. A closed lid is fine for this kind of work.
3. Give WSL more memory
By default WSL2 caps itself at about half your RAM. On my 16 GB laptop that meant Linux saw 7.7 GiB. You raise the cap with a small file in your Windows home folder:
[wsl2]
memory=12GB
swap=4GBThat leaves about 4 GB for Windows. WSL only takes memory when it needs it, so this is a ceiling, not a reservation. It applies after a restart: run wsl --shutdown from PowerShell, then reopen Ubuntu.
| Before | After | |
|---|---|---|
| Memory (from free -h) | 7.7 GiB | 11 GiB |
| Swap | 2.0 GiB | 4.0 GiB |
If you're wondering why it shows 11 and not 12: Linux counts in GiB, and the kernel keeps a small slice for itself.
4. Passwordless sudo (and the terminal that isn't one)
Claude can't type a password. If you want it to install packages or manage services on its own, sudo has to work without a prompt. The standard way is a one-line rule in /etc/sudoers.d, so I typed this into Claude's prompt using ! mode, which runs a shell command directly:
! echo "<you> ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/<you>
sudo: A terminal is required to authenticateWhere it bit me
Claude Code's ! mode runs commands, but it isn't a real terminal, so sudo can't show its password prompt there. You either do this in a normal Ubuntu window, or come at it from the Windows side, which is what I did.
WSL lets Windows open the distro as root directly, with no password. From WSL, calling back out to wsl.exe:
$ wsl.exe -u root -e sh -c 'echo "<you> ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/<you> && chmod 440 /etc/sudoers.d/<you> && visudo -c'
/etc/sudoers: parsed OK
$ sudo -n true && echo "no password needed"
no password neededAlways finish with visudo -c. A broken sudoers file can lock you out of sudo entirely, and this check catches it straight away. To undo the whole thing later, run sudo rm /etc/sudoers.d/<you>.
5. An always-on Remote Control server
This is the heart of the setup. A normal Claude session dies when its terminal closes. claude remote-control is different: it's a small server that registers the machine with your account, and from the phone app you can start as many new sessions on it as you like.
I run it inside tmux so it has no window to close, and wrap it in a loop so it comes back if it ever crashes.
A detour worth mentioning
I asked Claude to set this part up for me, and it wouldn't. Its auto-mode safety check flagged "a background process that starts itself" as unauthorized persistence and blocked it, even after I said yes. That annoyed me for about thirty seconds, then I saw the point: this is exactly what you'd want an agent to refuse to do quietly on its own. So I ran the commands myself with !, which takes the decision back out of the agent's hands. I'd leave that safeguard alone.
First, the script:
! mkdir -p ~/bin ~/work && printf '%s\n' '#!/bin/bash' 'cd "$HOME/work"' 'tmux has-session -t claude-rc 2>/dev/null || tmux new-session -d -s claude-rc "while true; do $HOME/.local/bin/claude remote-control --name laptop --permission-mode auto; sleep 10; done"' > ~/bin/claude-rc.sh && chmod +x ~/bin/claude-rc.shMy first version started in my home folder, and it failed every ten seconds with this:
Error: Workspace not trusted. /home/you is your home directory, and for
security home-directory trust is never saved ... Run `claude rc` from a
project directory instead.Where it bit me
Claude Code never saves trust for your home directory, on purpose. Give the server its own folder (I use ~/work) and trust it once from a real Ubuntu window, not ! mode, because the trust prompt is interactive.
$ cd ~/work && claude
# accept the trust prompt, then type /exitThen start it and look inside the tmux pane:
! ~/bin/claude-rc.sh
! tmux capture-pane -pt claude-rc | grep -v '^$' | tail -5
·✔︎· Connected · work · HEAD
Capacity: 1/32 · New sessions will be created in the current directory
laptop
Continue coding in the Claude mobile app or https://claude.ai/codeWhen I saw laptop show up in the Claude app on my phone, I knew the setup would work.
6. Start it automatically at Windows sign-in
tmux survives a closed terminal, but not a reboot. For that I dropped a tiny hidden launcher into the Windows Startup folder. It needs no admin rights and shows no window.
! printf 'CreateObject("WScript.Shell").Run "wsl.exe -d Ubuntu -u <you> -- bash -lc ""$HOME/bin/claude-rc.sh; exec sleep infinity""", 0, False\r\n' > "/mnt/c/Users/<windows-user>/AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup/claude-rc.vbs"The sleep infinity is the important bit. WSL shuts itself down shortly after its last Windows-side process exits, and this keeps one process alive so Linux, and tmux inside it, keeps running. The 0 in the VBScript means "hidden window".
7. Sign in without you
The Startup folder only runs once someone signs in. After a Windows Update reboot, the laptop would sit at the sign-in screen forever and nothing would start. It needs to sign in by itself.
The usual advice is to run netplwiz and untick "Users must enter a user name and password". On my machine that checkbox didn't exist. Neither did the Windows Hello option most guides tell you to turn off first.
Where it bit me
On recent Windows builds, a passwordless-sign-in policy hides the checkbox. One registry value brings it back. Run it in an administrator PowerShell, then reopen netplwiz.
PS> reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PasswordLess\Device" /v DevicePasswordLessBuildVersion /t REG_DWORD /d 0 /fUntick the box and enter your account password twice, not your PIN. If you'd rather not touch the registry, Microsoft's Sysinternals Autologon does the same job and stores the password encrypted.
8. Test it with a real reboot
The only honest test is to restart the laptop and not touch it. I tried to do that from WSL and got it wrong twice:
! reboot
Call to Reboot failed: Access denied ...
! shutdown -r -t 0
Failed to schedule shutdown: Access denied ...Where it bit me
Inside WSL, reboot and shutdown are Linux's commands. At best they restart the Linux VM, not the PC. The .exe suffix is what reaches Windows:
! shutdown.exe /r /t 0The screen went black and the session I was typing in disappeared, as expected. Then I picked up my phone and waited. Windows booted, signed itself in, the hidden launcher started WSL, and a couple of minutes later laptop was back in the Claude app, ready for a new session. I didn't touch the keyboard.
What I'd tell a friend before they copy this
This setup is convenient because it removes almost every safety catch between your Claude account and your laptop. Put together, it means:
- Anyone who gets into your Claude account can run commands on this laptop, as root, with no prompt. Use a strong password and two-factor sign-in.
- Anyone who picks up the laptop is signed straight into Windows. Keep it somewhere you trust.
- Windows programs that WSL launches run as your normal Windows user, not as admin. That's a useful limit, and I'd leave it that way.
If that's too much, drop step 7 and sign in yourself after reboots, or swap NOPASSWD:ALL for a short list of commands (apt, systemctl). Everything else still works.
The finished checklist
- Claude allowed to run tools without asking
- Lid closed, plugged in, never sleeping
- WSL allowed 12 GB of RAM
- Passwordless sudo, checked with visudo -c
- Remote Control server in tmux, restarting itself
- Hidden launcher in the Startup folder
- Windows signs itself in after reboots
- Tested with a real restart, hands off
From here on, the plan is simple: open the Claude app, tap laptop, and start working, while the machine doing the work sits somewhere else with its lid shut.
Comments
Post a Comment