feat(workers): evaluate pydantic/monty as the sandboxed Python task runtime

[rickylabs]

Context

The worker plugin's python TaskType (like every non-deno runtime) inherits the worker host's OS privileges — filesystem, env, and network are unrestricted. This is the accepted trust boundary recorded as arch-debt workers-non-deno-task-sandbox-boundary: today deno is the only runtime with per-task permission enforcement, and the debt's close gate is either a documented enforced per-task sandbox or a public API that models the boundary as permanent.

pydantic/monty may be the missing enforcement mechanism for the Python side: "a minimal, secure Python interpreter written in Rust for use by AI."

Why monty fits NetScript's shape

• Capability-based by construction — "filesystem, env variables and network access are all implemented via external function calls the developer can control." The host decides what a task can touch, which is a stronger model than CPython-in-a-subprocess plus OS hardening, and is the moral equivalent of deno task .permissions(...).
• Resource limits built in — memory, stack depth, and execution time can be tracked and cancelled when limits are exceeded; that maps directly onto the task timeout/retry machinery in @netscript/plugin-workers-core.
• Embeddable where we already run — distributed as a Rust crate, a Python package (pydantic-monty), and npm (@pydantic/monty) / WebAssembly. The npm/WASM form could run in-process inside the Deno worker host, eliminating the per-message subprocess spawn entirely — the same in-process execution boundary the scriptc RFC run (PR docs(rfc): scriptc task runtime adapter — dispatch-path benchmark + RFC #1678) is studying for native/WASM tasks. Startup is "measured in single digit microseconds not hundreds of milliseconds."
• Crash isolation — worker-pool design where a crashed worker cannot take down the parent.

Constraints to evaluate honestly

• Experimental — upstream says "not ready for prime time" (pre-V1, MIT-licensed).
• Python subset — small stdlib slice (asyncio, collections, dataclasses, datetime, itertools, json, math, os, pathlib, re, sys, typing, unicodedata); no class inheritance/metaclasses yet, no match statements yet, and third-party libraries are explicitly a non-goal — so this cannot replace the existing python TaskType for numpy/pandas-style workloads; it would be a new, sandboxed runtime option (.runtime('monty') or a python sandbox mode), not a swap.
• Marshalling contract: how task input (argv/env today) and the last-JSON-line-of-stdout result contract map onto an in-process interpreter needs a design decision.

Relationship to existing work

• PR docs(rfc): scriptc task runtime adapter — dispatch-path benchmark + RFC #1678 (scriptc task-runtime RFC): its execution-boundary study (subprocess vs in-process WASM vs FFI) and TaskRuntimeAdapterLike adapter sketch give the seam a monty adapter would use; monty is the Python-flavored instance of the same in-process/sandboxed quadrant. The RFC will reference this issue as future work rather than absorbing it.
• Arch-debt workers-non-deno-task-sandbox-boundary: a monty runtime would be the first non-Deno runtime able to close (rather than document) that boundary for Python-authored tasks.

Acceptance

• Spike: run @pydantic/monty (npm/WASM) inside a Deno process in the repo workspace; execute a representative task body with host-controlled print/input plumbing; record startup latency, per-call overhead, and RSS alongside the PR docs(rfc): scriptc task runtime adapter — dispatch-path benchmark + RFC #1678 benchmark numbers
• Decision note: new TaskType (monty) vs sandbox mode on the existing python runtime vs recipe-only, with the input/result marshalling contract sketched against TaskRuntimeAdapterLike
• Security review: enumerate which capabilities the adapter exposes by default (proposal: none) and how .permissions(...)-style options map onto monty's external-function-call surface
• Verdict recorded (adopt experimental / wait for V1 / reject) with the upstream maturity caveat dated

[rickylabs]

Series update (owner ruling, run 4): Python gets no standalone RFC — this issue is Python's vehicle. Supporting data from the Go run's probe (same manifest as the whole series): python3 cold spawn is unremarkable at 36.8 ms wall / 9.3 MB RSS / 30 ms CPU (100k workload), but CPython per-iteration compute is ~100× off native — so every hot-path question collapses into the in-process sandboxed plane this spike covers. Suggested addition to the acceptance list: benchmark the monty spike against these rows (.llm/runs/claude-harness-profile-rfc-benchmark-shzhgv--golang-rfc/results/) plus run-1's dispatch-path numbers, using the series' MINSTD workload for exact cross-language identity.

---

Generated by Claude Code