kvcache-ai/AgentENV

Fork 0

mirror of https://github.com/kvcache-ai/AgentENV.git synced 2026-11-05 01:17:36 +00:00

[GH-ISSUE #188] Support opt-in package download caching across sandboxes #61

New issue

Closed

opened 2026-10-29 14:19:00 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-29 14:19:00 +00:00

Owner

Originally created by @ztting01 on GitHub (Aug 18, 2026).
Original GitHub issue: https://github.com/kvcache-ai/AgentENV/issues/188

Affected component

Cross-cutting / other

Problem statement

AgentENV caches OCI image layers and snapshot artifacts, but packages installed inside sandboxes with commands such as apt install or npm install are still downloaded independently by every sandbox.

When many short-lived sandboxes or template builds install overlapping dependencies, the same package objects are repeatedly downloaded. This increases startup and build latency, wastes upstream bandwidth, and can trigger public repository rate limits.

Use case

Typical workloads include:

concurrently building multiple templates from the same base image;
creating many short-lived sandboxes that install similar dependencies;
repeatedly running apt install, npm install, or npm ci across isolated sandboxes; and
RL or evaluation workloads where package-manager caches disappear with each sandbox.

Sandboxes should remain filesystem-isolated while being able to reuse package downloads already fetched on the same AgentENV node.

Current behavior and workarounds

Each sandbox has its own package-manager cache, so downloaded packages are not reused after the sandbox is deleted.

Users can manually configure repository proxies in individual templates, but there is no standard AgentENV integration for enabling the capability per sandbox or keeping it correct across start, resume, fork, and node changes.

Desired behavior

AgentENV should support an optional integration that allows sandboxes on the same node to reuse downloads of public software packages.

The expected behavior is:

the feature is opt-in and disabled by default;
non-enabled sandboxes keep their current behavior;
package-manager state and writable guest directories remain isolated;
repeated downloads of the same public package can be served from a shared cache;
the integration remains correct across sandbox start, resume, fork, and template-based launch;
cache failures have explicit behavior rather than silently changing the network path;
cache capacity is bounded and observable; and
credentials and authenticated private-package responses are not shared in the initial scope.

Proposed approach

The implementation approach is intentionally left open. A separate Discussion can cover possible responsibility boundaries between AgentENV, Custom Extension, guest configuration, networking, and external package-cache providers.

Compatibility and operational impact

API/config changes:

To be determined through design discussion. The feature should remain optional and backward compatible.

Snapshot or storage format changes:

The package cache should not become part of, or a correctness dependency of, AgentENV snapshots.

New host/runtime requirements:

Only deployments enabling the feature should require additional cache capacity or services.

Upgrade and rollback considerations:

Disabling the feature should restore the existing direct-download behavior without affecting existing sandboxes, templates, images, or snapshots.

Alternatives considered

Rely only on template and snapshot reuse. This does not cover dependencies installed dynamically after sandbox startup.
Share writable package-manager directories between sandboxes. This risks lock conflicts, corruption, permission problems, and cache poisoning.
Let every deployment build an unrelated custom solution. This works, but produces inconsistent lifecycle, security, and failure semantics.

Non-goals

Replacing AgentENV templates or snapshots.
Sharing writable guest package-manager directories.
Caching arbitrary HTTP or HTTPS traffic.
Supporting authenticated private repositories in the first version.
Requiring AgentENV itself to implement APT, npm, or another repository protocol.

Contribution

I can provide more design details.

Pre-submission checklist

I searched existing issues and discussions and did not find a duplicate.
I described a concrete problem and use case, not only a proposed technology.
I understand that acceptance of the problem does not imply approval of a particular implementation.

Originally created by @ztting01 on GitHub (Aug 18, 2026). Original GitHub issue: https://github.com/kvcache-ai/AgentENV/issues/188 ### Affected component Cross-cutting / other ### Problem statement AgentENV caches OCI image layers and snapshot artifacts, but packages installed inside sandboxes with commands such as `apt install` or `npm install` are still downloaded independently by every sandbox. When many short-lived sandboxes or template builds install overlapping dependencies, the same package objects are repeatedly downloaded. This increases startup and build latency, wastes upstream bandwidth, and can trigger public repository rate limits. ### Use case Typical workloads include: - concurrently building multiple templates from the same base image; - creating many short-lived sandboxes that install similar dependencies; - repeatedly running `apt install`, `npm install`, or `npm ci` across isolated sandboxes; and - RL or evaluation workloads where package-manager caches disappear with each sandbox. Sandboxes should remain filesystem-isolated while being able to reuse package downloads already fetched on the same AgentENV node. ### Current behavior and workarounds Each sandbox has its own package-manager cache, so downloaded packages are not reused after the sandbox is deleted. Users can manually configure repository proxies in individual templates, but there is no standard AgentENV integration for enabling the capability per sandbox or keeping it correct across start, resume, fork, and node changes. ### Desired behavior AgentENV should support an optional integration that allows sandboxes on the same node to reuse downloads of public software packages. The expected behavior is: - the feature is opt-in and disabled by default; - non-enabled sandboxes keep their current behavior; - package-manager state and writable guest directories remain isolated; - repeated downloads of the same public package can be served from a shared cache; - the integration remains correct across sandbox start, resume, fork, and template-based launch; - cache failures have explicit behavior rather than silently changing the network path; - cache capacity is bounded and observable; and - credentials and authenticated private-package responses are not shared in the initial scope. ### Proposed approach The implementation approach is intentionally left open. A separate Discussion can cover possible responsibility boundaries between AgentENV, Custom Extension, guest configuration, networking, and external package-cache providers. ### Compatibility and operational impact API/config changes: To be determined through design discussion. The feature should remain optional and backward compatible. Snapshot or storage format changes: The package cache should not become part of, or a correctness dependency of, AgentENV snapshots. New host/runtime requirements: Only deployments enabling the feature should require additional cache capacity or services. Upgrade and rollback considerations: Disabling the feature should restore the existing direct-download behavior without affecting existing sandboxes, templates, images, or snapshots. ### Alternatives considered - Rely only on template and snapshot reuse. This does not cover dependencies installed dynamically after sandbox startup. - Share writable package-manager directories between sandboxes. This risks lock conflicts, corruption, permission problems, and cache poisoning. - Let every deployment build an unrelated custom solution. This works, but produces inconsistent lifecycle, security, and failure semantics. ### Non-goals - Replacing AgentENV templates or snapshots. - Sharing writable guest package-manager directories. - Caching arbitrary HTTP or HTTPS traffic. - Supporting authenticated private repositories in the first version. - Requiring AgentENV itself to implement APT, npm, or another repository protocol. ### Contribution I can provide more design details. ### Pre-submission checklist - [x] I searched existing issues and discussions and did not find a duplicate. - [x] I described a concrete problem and use case, not only a proposed technology. - [x] I understand that acceptance of the problem does not imply approval of a particular implementation.

bsakaguchi closed this issue

2026-10-29 14:19:00 +00:00

bsakaguchi commented

2026-10-29 14:19:01 +00:00

Author

Owner

@yingdi-shan commented on GitHub (Aug 19, 2026):

Thanks for raising this. The recommended approach is to preinstall commonly used dependencies in a sandbox, create a snapshot, and then start subsequent sandboxes from that snapshot. This avoids repeatedly downloading and installing the same dependencies while preserving sandbox isolation.

Deployments can maintain either a comprehensive base snapshot with most common dependencies or several workload-specific snapshots for different languages and toolchains.

@yingdi-shan commented on GitHub (Aug 19, 2026): Thanks for raising this. The recommended approach is to preinstall commonly used dependencies in a sandbox, create a snapshot, and then start subsequent sandboxes from that snapshot. This avoids repeatedly downloading and installing the same dependencies while preserving sandbox isolation. Deployments can maintain either a comprehensive base snapshot with most common dependencies or several workload-specific snapshots for different languages and toolchains.

bsakaguchi commented

2026-10-29 14:19:01 +00:00

Author

Owner

@ztting01 commented on GitHub (Aug 19, 2026):

Thanks for raising this. The recommended approach is to preinstall commonly used dependencies in a sandbox, create a snapshot, and then start subsequent sandboxes from that snapshot. This avoids repeatedly downloading and installing the same dependencies while preserving sandbox isolation.

Deployments can maintain either a comprehensive base snapshot with most common dependencies or several workload-specific snapshots for different languages and toolchains.

Thanks for reply.

@ztting01 commented on GitHub (Aug 19, 2026): > Thanks for raising this. The recommended approach is to preinstall commonly used dependencies in a sandbox, create a snapshot, and then start subsequent sandboxes from that snapshot. This avoids repeatedly downloading and installing the same dependencies while preserving sandbox isolation. > > Deployments can maintain either a comprehensive base snapshot with most common dependencies or several workload-specific snapshots for different languages and toolchains. Thanks for reply.

bsakaguchi referenced this issue

2026-10-29 14:20:13 +00:00

[PR #61] [MERGED] Add contributing guidelines and templates #147