Answer
There is no officially documented idle timeout that causes the VS Code Remote - Tunnels server to shut down solely due to inactivity. The server process does not include a built‑in inactivity timer, and no user‑exposed setting, environment variable, or code tunnel CLI flag exists to configure such a timeout.
Likely explanation
Observed shutdowns are usually caused by factors external to the tunnel server:
- Host machine sleep, hibernate, or power‑saving settings.
- Network NAT or firewall idle timers that drop the underlying tunnel connection.
- Periodic refresh of the tunnel token or service registration, which may appear as a restart if the host process is terminated.
- Updates to the Remote - Tunnels extension or CLI that restart the server.
Because the tunnel registration (the Azure Relay/devtunnels connection) can remain active while the local server process idles, the perceived "timeout" often reflects the host OS or network behavior rather than a server‑side idle threshold.
Steps to verify on your system
- Run
code tunnel --help and confirm that no idle/timeout‑related flags are listed.
- Start a tunnel interactively (
code tunnel), connect once, then disconnect.
- Monitor the tunnel status with
code tunnel status or attempt to reconnect at regular intervals (e.g., every 5 minutes) while keeping the host awake.
- Check OS power settings and system logs (journalctl on Linux, Event Viewer on Windows) around any observed shutdown to rule out sleep/hibernate.
Practical recommendation
If you need predictable availability for low‑traffic workloads, control the server lifecycle externally:
- Run
code tunnel service install to manage the server as a system service, letting your service manager or host orchestration handle start/stop.
- Or automate start/stop of the tunnel (or the host VM) based on a schedule or on‑demand triggers.
To tailor this advice, please let me know: are you running the tunnel as a background service or interactively?
vscode