The task had been running a while on my remote box — one of those long, multi-step jobs I kick off and step away from — and I was somewhere else entirely when my phone buzzed. It was a Telegram ping from a small notifier I'd built, claude-code-notify, which reaches me whenever a Claude Code turn needs my input, finishes, or dies — so I don't have to sit and watch. This one was the first kind: Claude had hit a decision it couldn't make alone and stopped to ask.
I didn't catch the ping in time. When I finally saw it, I reached for my phone to answer the way I'd planned: this session had Remote Control turned on, so I should have been able to reply straight from the Claude app. But the session there was already disconnected
— nothing to type into. So I went back to the VS Code extension panel on my laptop, reconnected, and the question wasn't there either. When the session picked back up it never asked again; it had quietly stepped over the gap where I was supposed to be and kept going. Not answered — gone, with no record in the history of what it had decided. The only proof the moment had ever existed was that notification still sitting on my phone — Claude needs you — pointing at a question that no longer had anywhere to be answered.
That mismatch is what nagged at me. I knew, from the ping, that an exchange had happened and that I'd missed my half of it — but I couldn't find the exchange anywhere to see what I'd missed. It took me the better part of a day to work out where the break actually was. The fix, once I found it, was a single line of configuration.
Back up, because the setup is the whole story.
I've been writing software for over a decade, and that leaves you with an intuition that's hard to switch off: every system fails in ways you didn't plan for, so you don't hand unvetted software unbounded reach over anything you care about. AI agents don't get an exception — if anything they earn the rule, because they act fast, confidently, and across your entire filesystem. So from the first day I used one, I ran it somewhere it could do its worst without touching my laptop: a personal cloud VM, isolated and disposable.
That instinct got paid back. Claude Code once printed a git token in plaintext, right there in the chat window. It caught the mistake itself and told me to treat the token as leaked and rotate it — which I did. It caught that one. The point of isolation is the one it doesn't catch. If that had been a wallet key instead of a git token, "oops, rotate it" isn't a sentence that saves you.
My first attempt at remote was Claude Code's Telegram channel — drive the agent entirely from chat messages. It worked the way pure vibe-coding works: you can't see the files, you can't see the diffs, you're steering blind, and the results showed it. Then I found the combination that actually fit: VS Code's Remote-SSH manages the project on the remote box directly, and the Claude Code extension runs against it. Safe and legible at the same time. The compute lives on the server, so it doesn't touch my laptop's resources — and, the part I loved, the task keeps running when my laptop sleeps or shuts down. I could start something heavy, close the lid, and it would just keep going.
To close the last gap — actually answering the agent when it needs me, without sitting at the machine — I leaned on two things. The notifier from the top of this post was one half: it tells me when Claude needs me. The other half was Remote Control (/remote-control
), which lets me approve prompts and answer questions from the Claude app on my phone — the how. Get pinged that it needs me, answer from my pocket. That was the workflow. (Hold onto that split between the when and the how; it's exactly where this broke.)
To figure out what had actually happened, I spent some time digging into Claude Code's mental model and how it runs under the hood.
A Claude Code session isn't a running program. It's data on disk — the transcript, the message history — that a process loads and continues. When the process is idle, nothing is computing; it's waiting for input. Kill the process and the session doesn't die, it just goes cold: the transcript is still on disk, and you can resume it later.
So what actually runs? A process. And in my setup — the VS Code extension panel driving a remote box — that process has a parent I'd never thought about. I only saw it when I finally looked at the process tree on the server: the claude process is a child of the VS Code Server's extension host, the thing that lives on the remote machine and backs your editor windows.
Now put my laptop to sleep. From the remote server's point of view, my laptop is a client, and it just disconnected. VS Code Server doesn't tear things down immediately — it holds the extension host open for a grace period, waiting for the client to come back. But past that window it gives up and disposes the extension host. And when the host goes, every child goes with it — including the claude process, including the d question it was holding in memory, waiting for my answer.
That's the whole failure. My laptop slept longer than the grace period. The remote server reclaimed the extension host. The process died mid-question. When I later reconnected and resumed, I got the transcript back — but the transcript ends at the point of interruption, with a question and no answer, and resume restores a conversation, not a d execution that knows how to press play. The task didn't re-ask, and it didn't pick up the gated step. (That's what I saw, at least; resume's exact behavior around a dangling prompt isn't something I'd bet is identical across versions.) The exchange was simply gone.
And here's the part that stung, given why I chose this setup in the first place: I went remote so that sleeping my laptop wouldn't stop the work. And it didn't stop the compute — the server never slept. What it stopped was the process's right to stay alive, on a timer I didn't know existed.
That disconnected
I hit in the Claude app wasn't a fluke, and it's worth being precise about why the answer-from-my-phone plan couldn't save me. Remote Control gives you a channel to reach the session — the docs are clear that it routes outbound through the Anthropic API, phone to relay to the machine running claude, never touching my laptop. But a channel to answer is worthless once the thing you'd answer is dead. By hour three the process was gone, and with it the session's registration; there was nothing left on the other end to say "yes" to.
The grace period is the whole game, and it's a setting: remote.SSH.reconnectionGraceTime
. Its default is three hours. That's the trap I fell into — my laptop had been asleep longer than three hours.
You set it in your local VS Code User settings. It's a client-side Remote-SSH setting, even though it governs how long the remote server waits for you:
"remote.SSH.reconnectionGraceTime": 86400
The unit is seconds, which I confirmed the hard way — 86400
is 24 hours. Now my laptop can sleep overnight and the remote process stays put, question and all.
Two things that will waste your afternoon if you don't know them:
Re the window isn't enough. The value is applied when the remote server starts. If a server is already running under the old value, reconnecting just reattaches to it — old value intact. You have to force a fresh server. From a remote terminal:
pkill -f vscode-server
then reconnect, and VS Code brings up a new server carrying the new value.
Verify it, don't trust it. After reconnecting, on the remote:
ps aux | grep -- '--reconnection-grace-time'
Remote-SSH passes your setting to the server as that flag. If you see your number, it's live. If you see nothing, you reattached to an old server — pkill
and reconnect.
One nuance worth respecting: this grace period is for unexpected disconnects — sleep, a dropped network. Deliberately quitting VS Code is a different event that can dispose the session immediately, no grace. (Remote Control's own docs say it plainly: close the terminal or quit VS Code and the session ends.) "Sleep" and "quit" both make your editor go away, but they are not the same thing to the server.
And don't confuse this with Remote Control's other timer — the roughly ten-minute one. That fires when the machine running claude is awake but can't reach the network for ten-odd minutes; it's about the server's uplink to Anthropic, not about your laptop being gone. Two different clocks, and my laptop's sleep only ever touched the grace-period one.
Worth admitting how I actually found this, because it's a lesson in itself: I debugged it with Claude Code, and Claude Code was wrong more than once on the way. It first told me /remote-control
wasn't a real command — it was; I'd just run past its knowledge cutoff. Then, chasing the grace period, it quoted me an old figure — "a few seconds to a few minutes" — from a stale GitHub issue, which sent me down a "there's no way to fix this" hole before we checked the current docs and found the real default was three hours with a real knob to turn.
The takeaway isn't "AI is unreliable." It's the same instinct that put my agents on a remote box to begin with: don't trust the first answer about how a tool behaves — check it against ps
and the current docs. The model corrected itself both times, which is the good case. The safety net is for when it doesn't.
I'd assumed a problem this disorienting — a task silently skipping a decision, an exchange I couldn't even locate — would have a proportionally complicated cause. It didn't. It was a three-hour timer with a one-line override.
If you run a walk-away workflow — kick off long tasks, answer from your phone — the weak point isn't the notification channel everyone reaches for first. It's whether the process is still alive when you get back to it. Remote isolation is what lets me let go of a running agent at all; but letting go safely needs two things held at once — the process kept alive long enough to answer (grace time), and the blast radius kept small enough to survive its mistakes (isolation). Hold both, and closing your laptop on a running agent stops being a gamble.
If you run Claude Code against a remote box, check your reconnectionGraceTime
before you next trust a closed lid — and if your resume behaves differently than mine did when it lands on a question with no answer, I'd genuinely like to hear about it.