Condor Sandbox & Builder — Docker Workspace + Low-Code Agentic Definitions
Audiences: developer, internal
Two subsystems of the Condor engine: the Sandbox (a Docker-backed workspace/computer the agent can operate — filesystem + terminal + exec) and the Builder (a low-code CRUD surface for the agentic definitions the engine composes: agents, tools, workflows, processors, predicate/tool kernels, context schemas, memory).
Sandbox subsystem — sandbox/
SandboxModule (condor-parity 21, security-reviewed 2026-06-09) gives the Condor
agent a real, isolated compute environment.
Wiring
SandboxRegistryModule(driver/) provides the Postgres-backed slot registry, atarnpool, and the sharedDockerSandboxdriver (dockerode).SandboxServiceis the orchestration brain (ownership + exec + restart).- Three controllers expose the HTTP surface under
@Controller('ai/condor/sandbox/sessions/:id'):SandboxController— status / exec / restartSandboxFsController— workspace filesystem readsSandboxPtyController— NDJSON terminal stream (manual@Res, NOT@Sse/WS)
Security model (hardened)
- The ONLY
APP_GUARDis the globalGatewayAuthGuard(validatesX-API-Key+ buildsreq.userfromX-Gateway-*— AuthN). On top, all three controllers add an explicit ROLE gate (@UseGuards(RolesGuard)+@Roles(DOCTOR, NURSE, CLINIC_ADMIN, ORG_ADMIN, SUPER_ADMIN)) — a PATIENT/non-clinical principal is 403'd. - Ownership is enforced per-session inside
SandboxService(unconditional, no service bypass). - Container isolation is the ultimate boundary for
exec: read-only rootfs,cap-drop ALL,no-new-privileges,Internal: true(no network egress), resource limits. - Deps:
AiModuleexportsPrismaAiService(ddx_api_ai—SandboxSlot/SandboxEventmodels). The stream-hub uses a dedicatedredispub/sub client (sandbox:exec:*channel).
Inode-safe writes (known trap)
Filesystem tools must write in-place (flag: 'w'), never tmp+rename — a rename
swaps the inode and detaches the macOS Docker bind mount, losing the mounted
sandbox folder. (See the fs-patch / fs-find-replace inode-safe-write helper.)
Builder subsystem — builder/
The low-code CRUD surface for Condor agentic definitions, exposed under
@Controller('admin/builder/*') (admin-scoped):
| Controller | Base path | Manages |
|---|---|---|
AgentsController | admin/builder/agents | agent definitions (role templates, prompts) |
ToolsController | admin/builder/tools | tool definitions |
ToolKernelsController | admin/builder/tool-kernels | reusable tool kernels |
WorkflowsController | admin/builder/workflows | workflow-template definitions |
ProcessorsController | admin/builder/processors | processors |
ProcessorKernelsController | admin/builder/processor-kernels | processor kernels |
PredicateKernelsController | admin/builder/predicate-kernels | branch/predicate kernels |
ContextSchemasController | admin/builder/context-schemas | context schema definitions |
MemoryController | admin/builder/memory | agent memory definitions |
BuilderService + builder-crud.base.ts provide the shared CRUD base; the
mastra-registry.module.ts registers the compiled definitions so the
orchestrator compiler can resolve ctx.tools,
ctx.roleAgents, and workflow templates at runtime.
Related Topics
- Condor Engine — the runtime that consumes these definitions and drives the sandbox.
- Agent Templates — the configurable agent-factory concept the builder generalizes for Condor.