Summary
oc checkpoint create fails with "sandbox does not belong to this organization" on a sandbox that was just created under the same authenticated session, even though the sandbox is fully reachable via oc exec and its org_id matches oc whoami. The sandbox also never appears in oc sandbox list/oc ls, despite being live and exec-accessible.
Environment
oc version: 0.6.0.39 (macOS arm64)
oc whoami: confirmed org bd2db151-436c-48c5-961b-d85add39ec29
Repro
$ oc sandbox create --timeout 600 --json
{
"sandboxID": "sb-e88df370",
"status": "running",
...
"token": "eyJhbGc..." # decodes to org_id bd2db151-436c-48c5-961b-d85add39ec29, matching `oc whoami`
}
$ oc exec sb-e88df370 --wait -- echo hello
hello # exec works fine, immediately and repeatedly, over several minutes
$ oc sandbox list
ID TEMPLATE STATUS CPU MEM AGE
# sb-e88df370 never appears, even after 30+ seconds
$ oc checkpoint create sb-e88df370 --name env-ready --kind disk_only
Error: sandbox does not belong to this organization
Retried the checkpoint create call after a 5s and again after a 20s delay (in case of index propagation lag) — same error both times, while oc exec against the same sandbox ID kept succeeding throughout.
Reproduction rate
Hit this on 2 of 2 sandboxes created and checkpointed in a single debugging session (a third sandbox, created earlier in the same session, did appear correctly in oc sandbox list — I didn't test checkpoint create on it before killing it, so I can't confirm whether it would have succeeded).
Impact
Not fully blocking for us — our workflow treats checkpoint create failure as non-fatal (prints a warning, continues) — but it means the "fault-tolerance baseline" checkpoint silently never gets created for a meaningful fraction of sandboxes, and a caller that does treat it as fatal would fail outright on a sandbox that's otherwise completely healthy.
Expected
oc checkpoint create should succeed on any sandbox that's currently exec-accessible under the authenticated org, or oc sandbox list should reliably list every live sandbox belonging to the org shortly after creation.
Summary
oc checkpoint createfails with"sandbox does not belong to this organization"on a sandbox that was just created under the same authenticated session, even though the sandbox is fully reachable viaoc execand itsorg_idmatchesoc whoami. The sandbox also never appears inoc sandbox list/oc ls, despite being live and exec-accessible.Environment
oc version:0.6.0.39(macOS arm64)oc whoami: confirmed orgbd2db151-436c-48c5-961b-d85add39ec29Repro
Retried the
checkpoint createcall after a 5s and again after a 20s delay (in case of index propagation lag) — same error both times, whileoc execagainst the same sandbox ID kept succeeding throughout.Reproduction rate
Hit this on 2 of 2 sandboxes created and checkpointed in a single debugging session (a third sandbox, created earlier in the same session, did appear correctly in
oc sandbox list— I didn't testcheckpoint createon it before killing it, so I can't confirm whether it would have succeeded).Impact
Not fully blocking for us — our workflow treats
checkpoint createfailure as non-fatal (prints a warning, continues) — but it means the "fault-tolerance baseline" checkpoint silently never gets created for a meaningful fraction of sandboxes, and a caller that does treat it as fatal would fail outright on a sandbox that's otherwise completely healthy.Expected
oc checkpoint createshould succeed on any sandbox that's currently exec-accessible under the authenticated org, oroc sandbox listshould reliably list every live sandbox belonging to the org shortly after creation.