Summary

  • Editing or deleting an organisation’s Codespaces retention policy leaves existing workspaces with their assigned periods. The new conditions are applied at creation.
  • Stopped workspaces continue using storage. Automatic deletion proceeds even when changes have not been pushed, so cutting the fleet requires a plan for getting the work out.

The savings presentation is ready before the storage has gone anywhere. An organisation changes its Codespaces retention period from thirty days to seven, takes a screenshot and has something satisfyingly concrete to show finance. Its older workspaces keep the periods they were given.

That change of numbers is an illustration. The rule is in GitHub’s retention-policy documentation: a codespace receives its retention period when it is created. Editing the policy does not change the period of an existing codespace. Deleting the policy leaves that period intact as well.

The organisation has changed the terms at the entrance. Clearing the rooms already occupied remains a separate job. That is a useful distinction for anyone whose cost-saving announcement is about to outrun the resources it supposedly retired.

The stopped machine still has luggage

Codespaces sells a useful convenience: a development environment in the cloud that someone can stop, return to and resume with saved files. Keeping that return possible occupies storage.

GitHub’s lifecycle documentation separates compute usage while a codespace is running from storage usage that continues after it stops. Storage keeps accumulating until deletion. Deleting the space ends future accrual; usage already accumulated during the billing month remains in the account. Closing a browser tab does not itself stop the remote environment, either.

Those distinctions give three apparently similar gestures different financial consequences. Closing the window, stopping the machine and deleting the workspace leave different things behind. A cost programme needs to know which one actually happened.

It also needs to know who pays. An organisation’s retention policy covers codespaces paid for by that organisation. Ownership of the repository alone does not bring a personally paid codespace within that rule. At creation, the shortest applicable period among organisation, repository and personal settings determines the retention assigned.

A repository list is therefore an incomplete map of the fleet being governed. The useful record pairs each environment with its payer and its actual assigned period. Public documentation supplies no customer inventory, assigned periods, unpushed-work inventory or bill from which to calculate actual savings or losses.

The documented mechanism nevertheless explains a very ordinary management disappointment. A stricter current policy can coexist with old storage under old periods. The setting worked; the assumption about what it would clear was too generous.

Saved is one stop short of delivered

A saved file lives on the cloud virtual machine. Getting the change into the remote repository requires committing and pushing it. Between those steps, completed-looking work can still depend on the survival of one rented environment.

GitHub’s automatic-deletion guidance says deletion proceeds regardless of unpushed changes. The timer has a deadline to enforce. It has no opinion about the value of the afternoon left inside.

The default deletes a stopped, inactive codespace after thirty days. Reconnecting resets the retention clock, which starts again when the environment stops. Personal settings allow zero to thirty days. Zero means deletion on stopping, including a stop caused by the idle timeout.

A shorter period thus gives newly covered workspaces less room for a leisurely handover. Zero also gives up the convenience of returning to the same preserved environment after a stop. A team choosing it needs its work outside the workspace and a practical way to rebuild what it wants to use again.

Nor does age alone identify the next environment to disappear. An older space that someone revisits can remain while a newer one with a short period expires. Eligible personal codespaces can be kept until manual deletion, with storage usage continuing. That keep option is unavailable for organisation-owned codespaces covered by an organisation retention policy.

Creation date, assigned period and recent activity answer different questions. Compressing them into one reassuring number makes the report shorter and the cleanup harder to understand.

A branch-sized exit

GitHub offers exporting changes to a branch without starting the codespace. That is useful when, for example, a spending limit prevents reopening the environment. The exit has a defined width: it exports the currently checked-out branch, leaving other branches out. Files larger than 100 MiB prevent the relevant push and export.

The sensible test is at the destination. Can the team see the required changes in the intended branch? Has it dealt with work elsewhere in the environment? Can it reconstruct the setup it is about to discard? A successful branch export has a specific scope; the working environment can contain more.

Once that handover is verified, the economic choice becomes clearer. A team can keep paying for a convenient return or retire the environment while retaining the results it produced. Before handover, storage may be serving as an expensive postponement of an unfinished transfer.

The new policy shapes the next arrivals. Decisions about identifiable existing workspaces shrink the current fleet. Counting those separately lets finance distinguish a changed intention from resources that have actually stopped being retained.