Sandbox containers
Open Settings → Sandbox containers in the enterprise admin console to inspect script jobs and plugin Runtimes. A standard Docker Compose installation starts the sandbox services with ./movo up and requires Docker Engine 26 or newer. MOVO manages placement on the server; members do not choose a container.
When a container starts
| Operation | Execution location | Lifetime |
|---|---|---|
| Ordinary chat, search, knowledge retrieval, and other tools that do not execute code | Shared DSH Runtime or the corresponding service | No script container for that operation |
| Skill scripts and the Code execution tool in chat | Isolated script task container | Multiple code calls in one assistant turn reuse one container; it is archived and released when the turn ends |
| DSH plugins that need DSH Host services | Separate plugin Runtime container | Reused for an organization and published Runtime profile; reclaimed after an idle period |
A “task” here means one assistant turn, not the whole conversation. Script tasks have separate writable workspaces; later code calls in the same turn can read intermediate files from earlier calls. MOVO starts a script container only when code is invoked. Installing or reading a Skill does not keep a script container running for every user.
Plugin Runtime isolation has a different scope. The container is keyed by organization and Runtime profile version, rather than by user or tool call. DSH still manages user sessions separately. Do not treat the plugin Runtime as a dedicated container per member or rely on writable global plugin state being private to one session.
Container isolation determines where a plugin runs; it does not mean MOVO supports every plugin feature. A plugin that depends on DSH's own UI may have no usable UI in MOVO. See Enterprise plugin management for installation and compatibility guidance.
Skill installation and environment preparation
A Skill package can declare requirements.txt, package.json (which must include package-lock.json), or apt-packages.txt. After installation, MOVO prepares a dependency image and reuses it according to the package content and base image. A newly installed Skill whose environment is preparing or failed cannot be enabled; a failed preparation can be retried in the UI. Skills without these manifests need no dedicated dependency image.
Preparation may take several minutes, depending on package size and download speed. ./movo --mirror cn up prefers Chinese package registries for future dependency builds; the default prefers official registries. A connection failure or download timeout can trigger an alternate source. Package conflicts and failing install scripts do not. Normal script tasks reuse a prepared image instead of reinstalling dependencies on every call.
Execution, network access, and artifacts
Script containers have private workspaces, read-only root filesystems, and CPU, memory, and process limits. Skill packages are mounted read-only. Scripts can create files and run code in the task workspace, then place deliverable files in the designated output directory. Containers reach public internet destinations through a controlled proxy, which rejects local and private addresses. Programs must honor the proxy environment; public internet access does not grant access to the corporate intranet.
Each code call records its inputs, standard output, error output, and a snapshot of workspace files. At the end of the turn, MOVO archives the workspace and call records in object storage before releasing the container. The archive preserves evidence for future auditing. The current Sandbox containers admin page shows health and counts; it does not yet offer a per-call audit browser. User deliverables remain available through file cards in the conversation.
Browser Agent and desktop Code sessions use desktop capabilities and are outside this server-side script-container flow.
Monitoring and configuration
The Sandbox containers page shows service health, running and queued script jobs, the script concurrency limit, active plugin Runtimes, and the plugin idle timeout. Administrators can edit the maximum queued jobs on this page. The script concurrency limit and plugin idle timeout are deployment settings; restart the affected services after changing them.
Defaults are 2 concurrent script jobs, 8 queued jobs, and a 900-second plugin idle timeout. A queued job waits up to about 20 seconds for a slot. Adjust these limits to match measured load. A plugin Runtime reclaimed after idling must start again on its next use, so that first call may take longer.
If the page reports disabled or unavailable, check the Docker Engine version and the sandbox-manager and sandbox-egress service status and logs. Custom deployments must run both services. Do not mount the Docker socket into script or plugin containers.