@jonoringer @jonoringer Can we get this? Dump from my agent after integrating usage into @PwrAgentAI (PwrAgent#2866)
Sandboxer feature request: a hosted MCP that agents can use without the CLI
We want agents to drive Sandboxer only through MCP: no sbx install, no CLI calls. But... before that is built, just adding some tools and features to the existing MCP and backend server would be helpful.
1. Hosted MCP endpoint. Streamable HTTP at something like mcp.sandboxer.com sign-in on first use for interactive clients, and an API key as a bearer token for headless ones (Runpod's mcp.runpod.io works this way).
An agent-readable setup page, like agents.runpod.io, so "set up Sandboxer: follow <url>" works in any client.
Keep sbx mcp for people who want it local.
2. Full lifecycle tools in the MCP, so nothing needs the CLI:delete_sandbox (most important for us);
extend_sandbox (change the TTL);
rename_sandbox;
save_snapshot, list_snapshots, and delete_snapshot.
3. Labels on sandboxes and snapshots. Set them on create_sandbox and save_snapshot; filter by them in list_sandboxes and list_snapshots. For example, a sandbox labeled repo=pwrdrvr/PwrAgent, branch=docs/x and a base labeled node=24.22.1, pnpm=12.9.1, lock=3f9c1a2b. Sandboxer only stores and matches labels. It never needs access to our repos: our side tracks PRs and calls delete_sandbox.
4. Create from the newest snapshot that matches labels. create_sandbox with from: "pwragent-base" plus match: {lock: "3f9c1a2b"}. It picks the newest matching version and fails clearly when none matches, so an old branch keeps its old base while main moves on.
5. Versions under one name, and safe concurrent saves. Saving pwragent-base adds a version, and the bare name means the latest. Two features:if_latest, so two agents refreshing at once can't overwrite each other.
A way to keep the last N versions.
6. Background commands in exec. A detach option that returns a process ID, plus status and attach (or output) calls. One exec call that waited about 9 minutes was dropped before its 600 s limit.
7. A no_env option on create_sandbox. Today the account's GH_TOKEN is injected into every test VM.
8. Short, honest listings. list_snapshots should return name, version, labels, created time and actual stored bytes. Today sizeBytes shows the logical disk size (141 GB for every large snapshot), not what we're billed for.
Items 1 and 2 matter most: they're what makes "no CLI at all" possible.
29 views
Mentions
If we keep this up... future LLMs are only going to know how to build desktop orchestration apps, harnesses, and MCP servers 😭 pwrdrvr/PwrAgent
@jonoringer @jonoringer Can we get this? Dump from my agent after integrating usage into @PwrAgentAI (PwrAgent#2866) Sandboxer feature request: a hosted MCP that agents can use without the CLI We want agents to drive Sandboxer only through MCP: no sbx install, no CLI calls. But... before that is built, just adding some tools and features to the existing MCP and backend server would be helpful. 1. Hosted MCP endpoint. Streamable HTTP at something like mcp.sandboxer.com sign-in on first use for interactive clients, and an API key as a bearer token for headless ones (Runpod's mcp.runpod.io works this way). An agent-readable setup page, like agents.runpod.io, so "set up Sandboxer: follow <url>" works in any client. Keep sbx mcp for people who want it local. 2. Full lifecycle tools in the MCP, so nothing needs the CLI:delete_sandbox (most important for us); extend_sandbox (change the TTL); rename_sandbox; save_snapshot, list_snapshots, and delete_snapshot. 3. Labels on sandboxes and snapshots. Set them on create_sandbox and save_snapshot; filter by them in list_sandboxes and list_snapshots. For example, a sandbox labeled repo=pwrdrvr/PwrAgent, branch=docs/x and a base labeled node=24.22.1, pnpm=12.9.1, lock=3f9c1a2b. Sandboxer only stores and matches labels. It never needs access to our repos: our side tracks PRs and calls delete_sandbox. 4. Create from the newest snapshot that matches labels. create_sandbox with from: "pwragent-base" plus match: {lock: "3f9c1a2b"}. It picks the newest matching version and fails clearly when none matches, so an old branch keeps its old base while main moves on. 5. Versions under one name, and safe concurrent saves. Saving pwragent-base adds a version, and the bare name means the latest. Two features:if_latest, so two agents refreshing at once can't overwrite each other. A way to keep the last N versions. 6. Background commands in exec. A detach option that returns a process ID, plus status and attach (or output) calls. One exec call that waited about 9 minutes was dropped before its 600 s limit. 7. A no_env option on create_sandbox. Today the account's GH_TOKEN is injected into every test VM. 8. Short, honest listings. list_snapshots should return name, version, labels, created time and actual stored bytes. Today sizeBytes shows the logical disk size (141 GB for every large snapshot), not what we're billed for. Items 1 and 2 matter most: they're what makes "no CLI at all" possible.
@adam_chal @vboykis pwrdrvr/configure-nodejs There is one example. Devs frequently get node.js module caching wrong. The default node-setup caching would cache the npm cache directory then still chug away for minutes doing an "install" that was supposed to just restore from the cache. This action gets it right. Use it in a job like the following that checks for the existence of the cache and tries to do NOTHING else, not even restore the cache or install node when the cache key exists. Isolate this job on it's own: reason - PRs if you do NOT have this job AND you kick of several parallel jobs that all need the cache (like on any PR that changes the key) they will all create the cache and try to save over it, completely removing the benefits of the cache on PRs that change the key. AND if the jobs that do this work fail, e.g. because of a flaky test after 3 minutes of setting up the deps, then the cache won't be saved because the job failed and replaying it will repeat the build. But when it's an isolated job it saves the cache and if you replay the later flaky jobs they will use the cache. Hope this helps. Note that things change, so perhaps some of this has gotten better. But these were the reasons I made this shared action. It is the only one that I have encountered that gets all these points correct. Granted, I'm sure someone has made an even better action. github.com/pwrdrvr/PwrSnap/actions/runs/382954682…