Skip to content

docs(sandbox): drop the stale Cloud Run launcher rationale from GCP comments - #490

Closed
ItamarZand88 wants to merge 1 commit into
mainfrom
itamar/sandbox-drop-stale-cloud-run-comments
Closed

docs(sandbox): drop the stale Cloud Run launcher rationale from GCP comments#490
ItamarZand88 wants to merge 1 commit into
mainfrom
itamar/sandbox-drop-stale-cloud-run-comments

Conversation

@ItamarZand88

Copy link
Copy Markdown
Contributor

Summary

The GCP sandbox is an Agent Platform engine and template, but several comments still
explained the AWS-only remote-sandbox and permission-reach rules as if GCP were a Cloud Run
launcher subprocess. This rewords them to state the real reason — remote sandbox has only an
AWS binding and the platform gate refuses GCP — without the obsolete mechanism.

What I did

  • Reworded five comments across four files, keeping the invariant each protects (remote
    sandbox is AWS-only; the platform gate refuses GCP; a Kubernetes sandbox must deny the
    metadata server itself) and dropping the Cloud Run launcher description.
  • No code changed — the GcpSandboxLauncherMutation and blanket sandboxLauncher grant the
    old comments named no longer exist.

Files touched

  • alien-manager/src/routes/bindings.rs — the remote-sandbox AWS-only rationale.
  • alien-permissions/src/registry.rs — the MicroVM-session permission-reach scan.
  • alien-preflights/src/mutations/remote_bindings.rs — a reachability note and a test's doc.
  • alien-helm/src/emitters/sandbox.rs — the metadata-server block, named as the managed
    runtime rather than a cloud (which kept it consistent with the GKE note below it).

How I tested

  • Manually: comment-only; confirmed the wording matches current behavior — the AWS-only
    gate and the GCP refusal are unchanged.
  • Ran the OSS-boundary scrub over the diff and commit message — clean.

…omments

The GCP sandbox is an Agent Platform engine and template, not a Cloud Run
launcher subprocess. Five comments still explained the AWS-only remote-sandbox,
the permission-reach scans and the Kubernetes metadata denial through that old
model; restate the real invariant — remote sandbox has only an AWS binding and
the platform gate refuses GCP — without the obsolete mechanism.
@greptile-apps

greptile-apps Bot commented Aug 25, 2026

Copy link
Copy Markdown

Greptile Summary

This PR updates stale sandbox documentation without changing executable behavior.

  • Clarifies that remote sandbox bindings and MicroVM-session permission scans are AWS-specific.
  • Explains that the GCP platform gate runs before AWS-shaped reachability checks.
  • Describes metadata-server blocking in terms of managed sandbox runtimes versus Kubernetes.

Confidence Score: 5/5

The PR appears safe to merge because it changes documentation comments only and preserves the existing runtime behavior.

The revised comments remain consistent with the adjacent AWS-only checks, GCP refusal path, and Kubernetes metadata-server isolation logic; no executable code or public contract changes.

Important Files Changed

Filename Overview
crates/alien-helm/src/emitters/sandbox.rs Rewords the metadata-server isolation comment while preserving the Kubernetes-specific rationale.
crates/alien-manager/src/routes/bindings.rs Replaces the obsolete Cloud Run launcher explanation with the current AWS-only binding and authorization rationale.
crates/alien-permissions/src/registry.rs Clarifies that the permission scan identifies AWS MicroVM-session verbs and does not apply to other cloud stack grants.
crates/alien-preflights/src/mutations/remote_bindings.rs Updates reachability documentation and test commentary to describe the GCP platform gate without referencing removed launcher behavior.

Reviews (1): Last reviewed commit: "docs(sandbox): drop the stale Cloud Run ..." | Re-trigger Greptile

@ItamarZand88
ItamarZand88 deleted the itamar/sandbox-drop-stale-cloud-run-comments branch August 25, 2026 09:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant