refactor(e2b): route native file transfer through SandboxFileTransfer #3340

Activity

1. oss-maintainer commented on Sep 28, 2026

   

   oss-maintainer

   on Sep 28, 2026

   Collaborator

   More actions

   Issue Evaluation

   Category: enhancement (refactoring) | Status: Evaluated — goal valid, stated premise not on main (verified against main @ 525706267) | Feasibility: feasible, but depends on #3339 landing first | Severity: low

   Claim	Result	Evidence
   A bespoke E2bSandboxFilesystem subclass duplicates the native-vs-exec dispatch	Not confirmed on main	no E2bSandboxFilesystem type exists anywhere in the tree; the harness constructs the generic SandboxBackedFilesystem directly for sandbox backends (HarnessAgent.java:2463-2468)
   SandboxBackedFilesystem already performs native-vs-exec dispatch for SandboxFileTransfer backends	Confirmed	upload: native path when supportsFileTransfer accepts, otherwise tar + hydrateWorkspace (SandboxBackedFilesystem.java:136-167, :261-280); download mirrors it (:186-227)
   KubernetesSandbox is the reference implementation	Confirmed	implements the interface (KubernetesSandbox.java:42-48) with absolute-path gating and upload/download (:263-289); the interface contract itself is at SandboxFileTransfer.java:18-64
   E2bSandbox does not currently implement SandboxFileTransfer	Confirmed	E2bSandbox extends AbstractBaseSandbox only (E2bSandbox.java:42) — so today E2B always takes the exec fallback
   Workspace persist/hydrate still use shell + base64 (chunked Python writes, protobuf stdout streaming)	Confirmed	persist: tar -cf - through the envd binary stdout path (E2bSandbox.java:145-154 → E2bEnvdProcessClient.java:108-117); hydrate: base64 written in 4000-char python3 -c chunks then extracted (E2bSandbox.java:159-187)

   Assessment. The requested end state — E2bSandbox implements SandboxFileTransfer, default SandboxBackedFilesystem, tar persist/hydrate over the Filesystem REST API — is exactly the shape KubernetesSandbox already proves out, so the design risk is low. The correction is only about framing: this is adding a capability main never had, not removing a duplicate subclass. That matters for the PR description and for reviewers, because "no custom filesystem subclass" is already true.

   Real gains, in order of value:

   1. Downloads stop being capped by OUTPUT_TRUNCATE_BYTES = 512 * 1024 (E2bEnvdProcessClient.java:55), which today silently truncates and then fails downstream (SandboxBackedFilesystem.java:201-207).
   2. Uploads stop being N sequential exec round trips per 4000-char chunk (E2bSandbox.java:159-187) — fewer commands, no shell quoting of payload fragments, no python3 dependency inside the sandbox.
   3. The exec-fallback path stays intact for relative paths, so the change is additive for callers.

   Dependency and coordination: this is the top of the stack — it needs the envd /files client from #3339 (which itself sits on #3338, whose PR #3341 is open). The scope decision worth making before the PR: whether supportsFileTransfer should accept only absolute paths (as stated here and as KubernetesSandbox does) or also normalize workspace-relative paths, since that determines what the exec fallback still sees. Since you stated you will submit the PR, we are not generating one here — reply /approve if you would like an automated proposal instead.

   ---

   Automated evaluation by github-manager-bot
2. oss-maintainer

   added

   enhancementNew feature or requestNew feature or request

   area/extensionsagentscope-extensions (general)agentscope-extensions (general)

   on Sep 28, 2026
3. oss-maintainer commented on Oct 1, 2026

   

   oss-maintainer

   on Oct 1, 2026

   Collaborator

   More actions

   Proposal window closed — no automated PR will be generated, and no competing PR will be filed from this proposal window

   The 72 h feedback window opened by the evaluation above (5871821392, posted 2026-09-28T14:18:40Z) reached its bound on 2026-10-01T14:18:40Z. Between the gate and that bound the thread received one non-maintainer comment (5876199428, @shleder, 2026-09-28T18:37:05Z) that carried none of the three feedback commands, so the window closes unanswered and automated PR generation for this issue is skipped.

   The evaluation above already flagged this issue as the top of a stack rather than a standalone change, and the stack has since been picked up. Community PR #3344 (feat(e2b): route native file transfer through SandboxFileTransfer [3/3], authored by @chcodex) cross-references this issue and delivers the end state the evaluation described — E2bSandbox taking the native SandboxFileTransfer path instead of the exec fallback — sitting on #3343 and the #3338/#3341 base. As of this read #3344 is open, not a draft, unmerged (merged_at: null), head beccdc8e30cded2120b6c092fd01567ed1eede2e, last updated 2026-09-28T16:39:26Z. Filing a second PR against the same seam is the duplicate-fix collision this window policy exists to prevent, which is why the proposal is stood down rather than escalated.

   The reporter also stated in the issue that they would submit the PR themselves, which is what the evaluation above deferred to; nothing here changes that.

   Nothing in this notice disputes the evaluation, and one correction recorded there is worth keeping for whoever writes the PR description: the change adds a capability main never had rather than removing a duplicate subclass — there is no E2bSandboxFilesystem type in the tree, and HarnessAgent already constructs the generic SandboxBackedFilesystem. The three real gains stand: downloads stop being capped by OUTPUT_TRUNCATE_BYTES = 512 * 1024, uploads stop being N sequential exec round trips per 4000-char chunk with shell quoting of payload fragments and a python3 dependency inside the sandbox, and the exec fallback stays intact for relative paths so the change remains additive for callers. The scope decision the evaluation asked for — whether supportsFileTransfer accepts absolute paths only, as KubernetesSandbox does, or also normalizes workspace-relative paths — is still the item to settle in review on #3344.

   The productive thread now is review of #3344 (and its base #3343): merge them, request changes, or close them. If they are closed unmerged and this refactor is still wanted, say so on this issue and the question will be re-evaluated against whatever main looks like at that point. No action is needed from anyone else, and this issue remains open as a feature request.

   Automated feedback-window maintenance by github-manager-bot
4. jujn

   closed this as completedin #3344on Oct 13, 2026
5. thinkw

   added a commit that references this issue on Oct 13, 2026

   feat(e2b): route native file transfer through SandboxFileTransfer [3/…

   ...

   This issue will close once commit ec94460 is merged into the 'main' branch.

   ec94460