Orchestrate sandboxed coding agents in TypeScript with sandcastle.run()
by mattpocockTypeScript
Last 12 weeks · 721 commits
2 of 6 standards met
Got sandcastle setup and followed the instructions (selected the parallel-planner-with-review option during setup) and then ran it and got this output. As you can see it found my issues in github and then just wasn't able to run. I am using npm and my node_modules was present and correct. The only slight weirdness I guess is I am using this in a python project that I am working on, but everything is standard other than that. Here was my init output:
Summary Fixes scaffolded dependency install behavior for Sandcastle init templates. What changed Added to both and sandbox options so container-side dependency directories such as can be mounted as anonymous volumes instead of mutating host bind mounts. Updated container teardown to remove attached anonymous volumes (). Updated the non-blank templates to isolate from the host bind mount. Threaded the detected package manager into scaffolding so generated non-blank templates use , , , or in . Removed hard-coded / wording from scaffolded verify prompts. Updated init next-step text, README docs, and patch changesets. Closes #745. Closes #872. Closes #786. Closes #873. Testing passes: 234 tests. passes. was attempted; it fails on existing environment issues unrelated to the init package-manager/prompt fix: macOS temp path canonicalization expectations ( vs , vs ). Podman tests requiring a running Podman Machine. existing worktree-reuse expectations that now hit the checked-out-branch guard. Notes This branch originally addressed host corruption from sandbox installs. The latest commit also covers #872 and #786 by making generated install hooks package-manager-aware and prompt verification wording project-agnostic.
Good idea and I really wish it worked, but... Looks like not under windows. First iteration run smoothly, but failed right after And indeed this file is no longer there. The branch looks like it was reset to a state before Sandcastle installation. For some reason a few 7zips were running in the background anyway.
Use case Allowing agent to run a test suite which relies on Testcontainers for Node.js to provision ephemeral databases etc. Problem Exposing host docker socket basically negates sandboxing. Setting up a one of the various socket proxy solutions is error prone and manual, needs to be managed outside of sandcastle, and most are not granular enough (Example: allow running container XWZ with no bind mounts). Solution Implement docker socket proxying in sandcastle, and allow a configured allowlist (image, commands etc..). See https://github.com/wollomatic/socket-proxy/blob/main/cmd/socket-proxy/handlehttprequest.go for example. When docker socket proxying is setup inject container with DOCKER_HOST Other solutions Maybe there should be a generic run (no agent just some other container), so dependancies for the workspace can be setup (mcp servers, databases, etc..). A "dependsOn" option which could be a list of SandboxProviders to run along side. Docker compose support as mentioned in a different issue. A different SandboxProvider which starts a lightweight vm instead of a container. All of these solutions except for the last one will not work with testcontainers.. But maybe that is out of scope TBH. Still there does seem to be a gap in the project as far as being able to setup a full environment for the agent to work in for anything non trivial.
Repository: mattpocock/sandcastle. Description: Orchestrate sandboxed coding agents in TypeScript with sandcastle.run() Stars: 6595, Forks: 657. Primary language: TypeScript. License: MIT. Open PRs: 30, open issues: 50. Last activity: 3d ago. Community health: 42%. Top contributors: mattpocock, github-actions[bot], dichioniccolo, bwcampbell9, jerome-benoit, mellson, lautarosegura, NitayRabi, screenfluent, aravindcm49.