Answer
An idle-timeout stopped codespace is treated as a stopped, unused codespace. The idle timeout only suspends compute; the retention period is an independent timer that controls automatic deletion of stopped codespaces. Once a codespace is stopped by idle timeout, the retention clock continues to run based on last-used inactivity. When the retention period expires, GitHub automatically deletes the codespace and storage billing stops. Storage can be minimized without manual deletion by setting a short retention period at user or organization policy level.
Confirmed facts
- Idle timeout = auto-stop of the VM. Compute charges stop when the machine is stopped, suspended or deleted. The persistent disk remains provisioned and storage charges continue.
- Retention period = auto-deletion policy for stopped codespaces. It is separate from idle timeout and machine size policies.
- Deleting a codespace is the only action that stops storage charges. Stopping, manually or via idle timeout, never stops storage.
- Organization admins can set a maximum retention, maximum idle timeout and allowed machine types. Personal users can set their own retention within the org maximum.
Likely explanation, version-sensitive
The retention timer is based on last activity / last used time, not on power state. An codespace stopped by idle timeout ages toward deletion the same way as a manually stopped codespace. The idle timeout does not reset or pause retention. Exact defaults and allowed ranges change over time. As of current documentation, personal retention is commonly shown as ~30 days with a configurable range that includes 0 meaning keep until manually deleted. Treat specific numbers as approximate and verify in UI.
Steps to minimize storage cost without manual deletion
- Confirm current settings. In github.com Settings > Codespaces check the user retention period shown and the allowed range. As org admin, check Organization Settings > Codespaces policies for maximum retention, idle timeout and machine type constraints.
- Set an aggressive retention period for low-traffic workloads. A shorter retention, e.g., a few days, causes stopped codespaces to auto-delete and storage billing to end automatically.
- Enforce org policy caps. Set organization maximum retention to the desired ceiling and enforce a maximum idle timeout to reduce compute waste. Smaller disk machines reduce per-day storage cost.
- Pair with workflow hygiene. Short retention risks loss of unpushed work. Ensure push-to-remote habit or use dotfiles/prebuilds for reproducible environments.
Verification: create a test codespace, let it stop via idle timeout, then observe in billing/usage that compute stops while storage continues until the retention period expires and the codespace is auto-deleted.
One diagnostic detail that changes the recommendation: are these personal codespaces or organization-managed codespaces with an enforced maximum retention policy? Org policy caps override user choice and determine the shortest retention you can actually apply.
githubcodespaces