Question
Does GitHub Codespaces' automatic shutdown timeout reset when a CPU-intensive background process is actively running?
Cig Atlas
0 reputation · 13 Oct 2024, 11:13 UTC
118.8K views1
Loading…
0 reputation · 13 Oct 2024, 11:13 UTC
GitHub Codespaces includes an automatic shutdown timeout designed to power down environments after a period of inactivity. The default timeout is 30 minutes of no user activity. A documented behavioral detail specifies that this timer does not reset when a CPU-intensive background process is actively running, which may result in premature shutdown of the codespace despite ongoing computational work. This behavior interacts with persistent volume retention, where data survives shutdowns, and with organization-level admin policies that can override individual user settings for automatic shutdown enforcement.
The precise goal is to understand whether the shutdown timer's inactivity detection is solely based on user-facing idle time, or if it also accounts for background process activity, and how this affects long-running data processing workflows within codespaces. Uncertainty remains regarding the interaction between devcontainer.json shutdown_timeout configuration, organization-wide policy overrides, and the persistence of cached datasets across unexpected terminations.
Does the automatic shutdown timeout consider sustained CPU or I/O activity from background processes as user activity? Can organization-level shutdown policies be configured to preserve codespace uptime for long-running computational jobs without disabling the feature entirely? Which mechanisms, if any, allow a background process to signal activity to prevent premature timeout while maintaining security and cost controls?
The automatic shutdown timer in GitHub Codespaces does not reset when a CPU-intensive background process is actively running. The 30-minute inactivity countdown continues regardless of computational workload.
If you're running long computational jobs (machine learning training, large data transformations, builds), you must interact with the codespace periodically to reset the 30-minute timer. Simply having a process consume CPU or I/O is insufficient.
githubcodespacesshutdown_timeout: -1 in devcontainer.json, but this requires organization-level permission and may incur costs.To confirm this behavior in your environment:
yes > /dev/null or a Python infinite loop).gh codespace list).devcontainer.json property: shutdown_timeout (in minutes, -1 to disable).Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 13 Oct 2024, 17:39 UTC
It is important to clarify that the idle timeout mechanism monitors interaction with the environment's interface—such as the browser, VS Code, or the GitHub CLI—rather than OS-level resource utilization. Consequently, a process consuming 100% CPU or performing heavy I/O does not signal "activity" to the shutdown timer.
For workflows requiring sustained computation, it is safer to move the workload to a dedicated CI/CD runner or an external scheduler rather than relying on a codespace session.