A phone is close to the worst server you can have. It changes networks all day, it reboots, it leaves Wi-Fi, and the port you connect to changes every time it restarts.
I'm Tyler, a software engineer at Kratos Defense & Security. At home I run a Linux server with a set of Claude Code agents on it, and I wanted them to reach me by text and read the replies that arrive by SMS, from a real phone number. That meant a real phone: a stock Pixel 10 with no root, no cable after a one-time pairing, and no laptop that has to stay awake.
How the server reaches the phone
The phone and the server are both on my Tailscale network. The server drives the phone over wireless adb across that network. One adb server on the box holds the connection, and I paired it with the phone once over USB. That pairing trust survives reboots, so when the phone restarts nobody has to pair it again.
The port moves on every boot
Wireless debugging listens on a port that's regenerated on every reboot. The usual way to find it is mDNS, but mDNS only works on the phone's own local network, and my server is one hop away over the VPN. So the job that syncs messages scans the phone's VPN address over the range where Android picks that port, connects, and writes down the port it found.
Hardcoding a port is the trap. On November 6 a job that still dialed a fixed port failed every run for two and a half hours while the phone itself was working fine. Now nothing dials a fixed port.
adb is only up while the phone is on Wi-Fi
Wireless debugging only listens while the phone is on Wi-Fi, and a phone leaves Wi-Fi constantly. One night I measured adb up for about three minutes, then gone, with no second window in the next 100 minutes.
So anything that drives the phone for more than a couple of minutes keeps what it has already measured and resumes from there. Retrying from the start doesn't help when the window is shorter than the job.
Getting back after a reboot
Two things don't survive a reboot: wireless debugging turns off, and Tailscale doesn't start on its own, even with the always-on VPN setting enabled. I wrote a small device-policy app that handles both. At boot it turns wireless debugging back on and starts the VPN, and any time it fails to reach the server it starts the VPN again, at most once every five minutes.
None of that can run before the first unlock. The phone has a PIN, and my app can't do anything useful until it's entered, because Android keeps the phone's storage locked until the first unlock. I measured one reboot on October 17: from the first unlock to the phone's first check-in with the server took 59 seconds, with nobody opening an app.
The phone counts as alive when its last check-in is recent. The VPN toggle can say on while nothing gets through, so it proves nothing. After a reboot an alert fires about ten minutes later and stays up until someone unlocks the phone, which is exactly what it should do.
Texts go through an outbox
To send a text, the server puts it in an outbox. The phone checks the outbox every 60 seconds, sends from its own SIM, and reports back. The outbox has three rules, each with its own status code:
- A number that isn't on the allow-list gets 403.
- More than 30 texts in 30 minutes, the limit Android enforces on this phone, gets 429.
- The same text to the same number within 10 minutes gets 409, along with the id of the first send. A retry never texts twice.
A text the phone claimed but never confirmed is never sent again automatically, because its delivery is unknown.