Skip to main content
When an Expert needs to get things done — write code, run programs, operate on files — it works inside an isolated cloud container. One chat gets one sandbox. Experts inside that chat share the machine. On the web that machine mounts the member’s whole disk. An API key caller mounts only that chat’s directory.

​
Why a Sandbox?

Security Isolation

Code executed by AI may contain errors or even risks. The sandbox ensures all operations are confined within the container, unable to affect the host system or other users.

Consistent Environment

Pre-installed with a complete development toolchain (Node.js, Python, system tools), so the Expert doesn’t spend time setting up — it can start working immediately.

Persistent State

The file system persists throughout the conversation. Code written, dependencies installed, and files generated by the Expert are still there when the next message arrives.

On-Demand Start

Sandboxes are only created when the Expert actually needs to execute tools — pure conversations incur zero resource cost.

​
Sandbox Lifecycle

1

Lazy Provision

Sandboxes are not created when the conversation starts, but only when the Expert first needs to execute a tool operation. Pure text conversations consume zero resources.
2

Sub-Second Warm Start

Based on pre-warmed container images, sandboxes typically go from creation to ready in under 1 second. Users barely notice any wait.
3

Cross-Message Persistence

Multiple messages within the same session share a single sandbox instance. Dependencies installed in the first message are still available in the fifth.
4

Idle Hibernation

When the conversation pauses, the sandbox automatically hibernates, releasing compute resources. The file system persists through cloud file storage (CFS), nothing is lost.
5

Seamless Resume

When the user sends another message, the sandbox is woken up to its previous file system state. The Expert can seamlessly continue its previous work.

​
Image Pre-Baking

The sandbox is not an empty container — it comes pre-installed with a rich development toolchain, ready for the Expert to use out of the box:
  • Node.js + bun (JavaScript/TypeScript full-stack)
  • Python 3 + uv package manager (data science + AI development)
  • TypeScript compiler + language server
  • Biome code formatting and static analysis
  • pandas, numpy, matplotlib, seaborn
  • scipy, scikit-learn
  • Pillow image processing
  • openpyxl Excel handling
  • Pandoc document format conversion
  • WeasyPrint PDF rendering
  • Tesseract OCR text recognition
  • ImageMagick image processing
  • Poppler PDF tools
  • TanStack Start (pre-baked + node_modules)
  • FastAPI / Flask (Python Web)
  • Complete HTTP client toolchain
The core idea behind pre-baking is “shifting wait time from runtime to build time.” Users don’t need to wait for npm install or pip install — hundreds of megabytes of dependencies are already installed during image build.

​
Working Directory Architecture

This design lets the Expert quickly start from a template (zero installation delay) while ensuring the user’s actual work is not affected by subsequent image updates.

​
Dev Server Lazy Start

Web preview is a commonly used Expert capability — letting users see the visual effects of code in real time. But a Dev Server is a resource-intensive process: Invariant: The only entry point for starting a Dev Server is the Expert proactively calling the initialization tool. Conversations that don’t need preview (data analysis, script execution, document processing) never pay the memory and CPU cost of a Dev Server.

​
Network and Security Policies

Sandboxes have controlled network access capabilities:

Outbound Access

Experts can access external APIs, download resources, and make network requests. This is essential for web development and data collection.

Process Isolation

Each sandbox is an independent Linux container with complete process namespace isolation. One user’s operations can never affect another user.

Resource Limits

CPU, memory, and disk usage all have container-level hard limits, preventing malicious or runaway programs from exhausting shared infrastructure.

File System Isolation

Cloud file storage is mounted with per-session isolation, inaccessible across sessions. Even different sessions from the same user cannot see each other’s files.

​
Provider Abstraction

The sandbox system uses a Provider abstraction design, allowing the underlying implementation to be transparently swapped: The Runtime doesn’t care about the specific container implementation details — it interacts with sandboxes through a unified Provider interface. This means new container providers can be seamlessly integrated in the future without any changes to the upper-layer Agent logic.

​
File Sync and Preview

Files created by the Expert in the sandbox can be previewed and downloaded by users in real time:
  • Code files: Displayed with syntax highlighting, supporting diff comparison
  • Web projects: Real-time preview via Dev Server, supporting HMR hot reload
  • Data files: Tables and charts rendered inline
  • Documents: PDF and Markdown instant preview
Users can also sync files from the sandbox to cloud storage for access after the conversation ends.
The sandbox is the technical foundation of Profy’s “AI doesn’t just talk, it does” philosophy. Without it, Experts can only generate text; with it, Experts can write code, run programs, create projects, generate documents — working like a true digital colleague.

​
Desktop Mode Tool Execution

The Profy Desktop client uses a local Python sidecar to execute tools directly, bypassing the cloud sandbox container. Tool execution strategies differ by operation type:

​
Cross-Platform Sandbox Isolation (MXC)

Desktop bash command execution uses Microsoft MXC (Execution Containers) for OS-level isolation across all three platforms: Each platform’s sandbox denies network access by default — outbound connections are only allowed when the Expert explicitly needs them (e.g., npm install). The file system is writable only within the working directory; system paths are read-only.
In Desktop mode, grep and glob use Python native implementations rather than bash commands, ensuring consistent behavior across all operating systems — especially on Windows where /bin/bash and find do not exist. Cloud glob runs rg --files in the container. An older image without rg uses the container’s python3 for the same path match. * does not cross /. ** does.
If the MXC SDK is unavailable on the current platform (e.g., runtime not installed), the system gracefully degrades: macOS falls back to the original Seatbelt direct call, other platforms fall back to unsandboxed execution. Degradation does not affect functionality but lacks isolation protection.

​
Disk layout

One chat gets one sandbox. Switching chats starts another machine. Switching experts inside the same chat stays on that machine. /home/user/workspace is not the workspace table. On the web, every machine mounts that person’s whole disk {workspaceId}/members/{userId}, so two chats can see the same tree. The directory the team shares comes from {workspaceId}/shared and is mounted at /home/user/workspace/shared. Other members’ directories are not on this machine.
The platform agent profy has no expert row and still gets a directory named profy. A new session directory is the full session id. shared/ is readable and writable by every member of the workspace. Two writes to the same file keep the later one. An API key caller gets one machine per chat. That machine mounts only end_users/{endUserId}/session-roots/{chatSessionId}. The session path inside the sandbox stays /home/user/workspace/<expert>/<session>/, and there is no shared/. The machine is stopped after one idle hour. Files stay on the cloud disk. The file tree in the web app is a different picture. See Workspace files.

​
Design Trade-offs