Why does my Pkg Change fail during storage migration?

A Change that reports New package sandboxes are temporarily disabled during the storage migration could not start the compute needed to edit its managed workspace. The failed Change does not produce a successful Checkpoint. Retrying the same Change cannot remove that service restriction.

Registry installation and ordinary package uploads use a different path from managed Change execution. A working install therefore does not show that managed Changes can run.

Inspect the Change

Use the Socra CLI with the Account and Pkg plugins, signed in to the Package's Account. Replace PACKAGE with its name or pkg_… ID, and CHANGE_ID with the pchg_… ID returned when the Change was requested:

socra pkg change retrieve PACKAGE CHANGE_ID

Check the status and error. Creating a Change returns a queued record before the work finishes; that initial response does not mean the requested source change succeeded.

If you do not have the Change ID, list the Package's Changes:

socra pkg change list PACKAGE

Continue through the returned pagination cursor when more rows remain. Keep the failing Change ID and exact error when you report a problem.

Why a Release may also be blocked

A native Release needs a successful Checkpoint. If the Package has none, Release creation reports Package has no successful Checkpoint to release.

List existing Checkpoints before trying a native Release:

socra pkg checkpoint list PACKAGE

A Checkpoint records a successful managed source state. The storage restriction also prevents the new package compute needed to build a native Release, so an existing Checkpoint alone does not clear that restriction.

A Package created by a direct npm upload is distribution-only. Pkg does not invent a managed source workspace for it when you request a Change or native Release.

What can I do while this is restricted?

Continue consuming already published versions and managing the dependency records supported by your Package. If you maintain the source outside the managed workspace, prepare and verify a local package for ordinary publication instead of claiming that a failed Change produced a new managed Release.

The restriction needs a service-side change before the blocked managed path can resume. Keep the Change ID and error when asking Socra for help. Do not change package identity, discard source, or create replacement Cloud resources merely to bypass this error.