Limits on resizing disk storage for an existing GitHub Codespace

Goal

I want a repeatable development environment using a committed devcontainer.json, and I need to understand the limits around persistent disk capacity for a Codespace that already exists. Specifically, I want to know whether storage can be increased in place, or whether the only supported path is selecting machine and storage size at creation time and rebuilding afterward.

Constraints and uncertainty

The repository configuration is fully reproducible: image, features, extensions, and postCreateCommand all come from the committed file. What is not reproducible is uncommitted local state, so deleting and recreating a Codespace means losing anything outside the repository. Available machine types and storage options also appear to depend on the plan and organization policy, which makes it hard to state a universal default disk size.

Assume current GitHub Codespaces behavior as of late 2026; exact limits are plan-sensitive and should be verified rather than assumed.

Questions

1. Can the disk of an existing Codespace be resized without deleting it, and if so, does the change require a rebuild or restart to take effect?
2. When recreating from the same commit, is there any supported way to retain data stored outside the repository working tree?
3. Besides df -h inside the Codespace, is there a reliable way to confirm actual disk, CPU, and memory before choosing a machine type?