Support declarative artifact delivery and stable endpoint for governed sandboxes #2818

Activity

1. github-actions

   added

   state:triage-neededOpened without agent diagnostics and needs triageOpened without agent diagnostics and needs triage

   on Aug 19, 2026
2. elezar

   added

   state:needs-infoAssessment needs specific evidence or reproduction detailsAssessment needs specific evidence or reproduction details

   area:gatewayGateway server and control-plane workGateway server and control-plane work

   area:sandboxSandbox runtime and isolation workSandbox runtime and isolation work

   area:compute

   area:sdkSDK-related workSDK-related work

   and removed

   state:triage-neededOpened without agent diagnostics and needs triageOpened without agent diagnostics and needs triage

   on Aug 20, 2026
3. elezar commented on Aug 20, 2026

   

   elezar

   on Aug 20, 2026

   Member

   More actions

   📋 triage-agent

   Triage Assessment

   Classification: needs-information

   Summary

   The issue describes useful security and lifecycle invariants, but it does not
   yet establish the concrete user story or explain why existing and in-progress
   OpenShell lifecycle primitives cannot be composed to support the workflow.

   OpenShell already has gateway-owned service endpoints that bind to an
   immutable sandbox ID, fail closed unless the sandbox is Ready, and are removed
   during sandbox teardown. Issue #2710
   and PR #2726 introduce a
   canonical supervised main process, while
   PR #2798 adds gateway-owned
   restart policies.

   These capabilities may cover much of the request if the digest-pinned bridge
   can run as the sandbox's canonical main process. A distinct feature would
   still be needed if the bridge must be delivered as an additional artifact,
   run as an auxiliary managed process, use application-specific readiness, or
   move an endpoint between different OpenShell sandbox IDs.

   Information requested

   Please update the issue with:

   1. A user story identifying the control plane, the workload it manages, and
      the desired outcome.
   2. The current workflow and why composing a digest-pinned sandbox image, the
      canonical main process, its restart policy, and the existing service
      endpoint API would not satisfy it.
   3. Whether the bridge is:
      • the sandbox's canonical main process,
      • an auxiliary process within the same sandbox policy boundary, or
      • an independently isolated service.
   4. Whether “sandbox replacement” means replacing the backing process or pod
      while preserving the OpenShell sandbox ID, or creating a new sandbox ID
      for the same logical workload.
   5. The readiness signal required before endpoint activation, such as process
      liveness, a TCP connection, an HTTP probe, or an authenticated application
      report.

   If replacement creates a new sandbox ID, please also describe which explicit
   control-plane operation should authorize moving the stable endpoint. A
   same-named sandbox should not inherit the previous sandbox's endpoint or
   authority automatically.

   Once this context is available, we can determine whether the request is an
   existing-capability composition/documentation task or a new managed-process,
   readiness, or endpoint-handoff capability.
4. github-actions commented on Sep 4, 2026

   

   github-actionsBot

   on Sep 4, 2026 – with GitHub Actions

   More actions

   This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.
5. github-actions

   added

   state:staleInactive item at risk of automatic closure.Inactive item at risk of automatic closure.

   on Sep 4, 2026
6. lbelyaev commented on Sep 5, 2026

   

   lbelyaev

   on Sep 5, 2026

   Author

   More actions

   Thanks @elezar — answering directly.

   1. User story. A control plane provisions a sandbox for an untrusted workload and must attach its own digest-pinned bridge process, reachable on a stable authenticated address other services use. The control plane supplies only digest-pinned, independently verified artifact coordinates; OpenShell owns installation, lifecycle, routing, and teardown. The address always resolves to the currently-active sandbox, fails closed during replacement, and a replaced sandbox never inherits the prior authority.

   2. Why the current composition falls short. The canonical main (feat(sandbox): add canonical main process #2726) + restart policy (feat(sandbox): add main restart policy #2798) + service endpoint cover a single, image-supplied, liveness-gated workload on one sandbox. The topology work (feat(kubernetes): add proxy-pod topology (in-pod process supervisor, out-of-pod proxy) #2885, feat(kubernetes): add cni-sidecar supervisor topology #2606) and SandboxProfile.trustedInjection (Proposal: Split Supervisor and Agent into Separate Pods with gVisor Isolation #981) add image-volume delivery — but only for trusted OpenShell components launched as the entrypoint. Support declarative artifact delivery and stable endpoint for governed sandboxes #2818 needs four things outside that: an auxiliary managed process alongside the workload, not the canonical main; caller-supplied digest-pinned delivery — independently verified, not an OpenShell component, not baked into the image — reusing the trustedInjection mechanism rather than pod exec/copy; an application-level readiness gate before endpoint activation, not main-process liveness; and endpoint continuity bound to the sandbox's immutable identity across replacement.

   3. The bridge is an auxiliary managed process in the same sandbox policy boundary — its own digest-pinned image, run as the sandbox's identity — not the canonical main, not an independent service.

   4. Replacement means a new runtime instance, not a reused sandbox ID. feat(kubernetes): add proxy-pod topology (in-pod process supervisor, out-of-pod proxy) #2885 already keys companions on the immutable sandbox UUID and refuses name reuse; Support declarative artifact delivery and stable endpoint for governed sandboxes #2818 extends that so the artifact and endpoint bind to the UUID and a replacement provisions a fresh instance the endpoint re-targets once ready. A same-named successor never inherits the prior endpoint or authority.

   5. Readiness is an authenticated application report, not liveness/TCP/HTTP. If replacement creates a new instance, an explicit control-plane operation binds its identity before the endpoint follows — never name-based adoption.

   Once you classify it, we'll contribute the neutral integration test.
7. github-actions

   removed

   state:staleInactive item at risk of automatic closure.Inactive item at risk of automatic closure.

   on Sep 6, 2026
8. github-actions commented on Sep 20, 2026

   

   github-actionsBot

   on Sep 20, 2026 – with GitHub Actions

   More actions

   This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.
9. github-actions

   added

   state:staleInactive item at risk of automatic closure.Inactive item at risk of automatic closure.

   on Sep 20, 2026
10. github-actions commented on Oct 13, 2026

    

    github-actionsBot

    on Oct 13, 2026 – with GitHub Actions

    More actions

    Closing this issue after 14 days with no activity since it was marked stale. Reopen it if the work is still relevant.
11. github-actions

    closed this as not plannedon Oct 13, 2026