Skip to content

docs(sandbox): say the Azure binding lacks these, not the cloud - #465

Closed
ItamarZand88 wants to merge 1 commit into
mainfrom
fix/sandbox-azure-capability-docs
Closed

docs(sandbox): say the Azure binding lacks these, not the cloud#465
ItamarZand88 wants to merge 1 commit into
mainfrom
fix/sandbox-azure-capability-docs

Conversation

@ItamarZand88

Copy link
Copy Markdown
Contributor

Summary

The sandbox capability docs said Azure's data plane exposes no file transfer and takes no egress policy. Microsoft documents both as ADC data-plane capabilities, so what is absent is this binding's implementation of them. Wording only — no assertion and no behaviour changes.

What happens when someone reads the wrong version:

  1. They call capabilities() and see files: false for Azure. Correct, and unchanged by this PR.
  2. They look for why, and the field's own doc-comment tells them the cloud cannot do it.
  3. They conclude the gap is permanent and design around it — which is the wrong conclusion, and the reason this is worth a PR rather than a note.

Two of these strings are generated into sandboxCapabilities.json and the zod schema, so the claim ships in the package and reaches anyone reading it in an editor.

What was broken

Five statements, all asserting a cloud limitation where the limitation is ours:

Where Said
sandbox.rs:172 "whose data plane exposes exec and lifecycle and no transfer" — generated into two published artifacts
sandbox.ts:36-38 "Azure has no file transfer, and no platform supports a hostname egress allowlist"
sandbox.rs:865 assertion message: "the Azure data plane has no file transfer"
sandbox.rs:867 "The Azure data plane takes neither an egress policy nor a ceiling"
sandbox.rs:914, :976 "the Azure data plane takes no egress policy"

The assertion message is the one with teeth. Whoever implements the Azure file operations will hit that failing test and be told the data plane cannot do the thing they just made it do — the misconception sits exactly where it will next mislead someone.

What I did

Reframed each to name the binding rather than the cloud, then regenerated the two published artifacts from the Rust source. The capability set still reports files and egressDeny false for Azure, which is correct for what a caller can reach today.

Files touched

crates/alien-core/src/resources/sandbox.rs, packages/core/src/sandbox.ts, and the two regenerated files under packages/core/src/generated/.

How I tested

  • cargo test -p alien-core --lib sandbox — 34 pass. The assertions themselves are unchanged; only their messages moved.
  • npx tsc --noEmit in packages/core, and biome check on both touched TypeScript files.
  • Regenerated with pnpm -C packages/core generate rather than editing the generated files, and confirmed both now carry the corrected text.
  • Grepped the tree afterwards for the old phrasing; every remaining hit is the corrected string.
  • Checked the claim against Microsoft's own documentation, which lists file management as an ADC data-plane capability in four separate places — the architecture table, the sandboxes concept, the sandboxes-vs-sessions comparison, and the auto-suspend definition, which counts file operations as an idleness signal.

One thing deliberately left alone: .code(...) and .limits(...) do not reach the Azure provider, which starts every session from a fixed disk and size. That is a behaviour bug rather than a wording one and wants its own change.

The capability docs stated that Azure's data plane exposes no file transfer
and takes no egress policy. Microsoft documents both as ADC data-plane
capabilities, so what is absent is this binding's implementation of them.

The distinction is not pedantic. Two of these strings are generated into the
published schema and zod artifacts, so the claim reaches anyone reading the
package, and it tells them a capability is impossible when it is unbuilt. The
assertion message was the worst of them: whoever implements the Azure file
operations will hit that failing test and be told the data plane cannot do
what they just made it do.

Assertions and behaviour are unchanged; the capability set still reports
files and egressDeny false for Azure, which is correct for what a caller can
reach today.
@ItamarZand88

Copy link
Copy Markdown
Contributor Author

Reopened as a branch that satisfies the naming convention CI enforces; same commit, same content.

@ItamarZand88
ItamarZand88 deleted the fix/sandbox-azure-capability-docs branch August 21, 2026 12:25
@greptile-apps

greptile-apps Bot commented Aug 21, 2026

Copy link
Copy Markdown

Greptile Summary

This documentation-only PR clarifies that Azure sandbox file-transfer and egress-policy limitations belong to the current binding implementation rather than Azure’s underlying data plane.

  • Updates Rust capability documentation, test assertions, and diagnostic comments.
  • Aligns the TypeScript sandbox API documentation with the corrected implementation boundary.
  • Regenerates the published capability schema descriptions without changing capability values or runtime behavior.

Confidence Score: 5/5

The PR appears safe to merge because it only corrects documentation and diagnostic wording to match the existing implementation.

The revised descriptions agree with the current Azure capability flags, unsupported file-operation methods, and egress validation behavior, with no runtime or public data-shape changes.

Important Files Changed

Filename Overview
crates/alien-core/src/resources/sandbox.rs Corrects Azure capability descriptions and test diagnostics while leaving capability values, validation, and assertions unchanged.
packages/core/src/sandbox.ts Updates public TypeScript documentation to accurately attribute unsupported file transfer and hostname egress allowlists to binding implementations.

Reviews (1): Last reviewed commit: "docs(sandbox): say the Azure binding lac..." | Re-trigger Greptile

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