zlacker

Fly's Sprites.dev addresses dev environment sandboxes and API sandboxes together

submitted by simonw+(OP) on 2026-01-09 23:57:31 | 41 points 18 comments
[view article] [source] [go to bottom]

NOTE: showing posts with links only show all posts
1. simonw+9[view] [source] 2026-01-09 23:58:30
>>simonw+(OP)
Here's the announcement on the Fly blog: https://fly.io/blog/code-and-let-live/ - and the Hacker News thread for that post: >>46557825

I wrote about this because it hits two of my current obsessions at once - developer environment sandboxes (for safely running Claude Code etc in YOLO mode) and APIs for executing untrusted code.

◧◩◪
6. avsm+Ox[view] [source] [discussion] 2026-01-10 05:59:24
>>shitco+0v
I just use Docker devcontainers using Anthropic's own Dockerfile as a base, and it gives me a persistent sandbox that have ports opened and work in any container environment (be it remote or local), and work in any IDE that supports devcontainers...

https://anil.recoil.org/notes/ocaml-claude-dev

◧◩
10. m-hodg+3q1[view] [source] [discussion] 2026-01-10 15:34:08
>>vivzke+uo
See: A field guide to sandboxes for AI¹ on the threat models.

> I want to be direct: containers are not a sufficient security boundary for hostile code. They can be hardened, and that matters. But they still share the host kernel. The failure modes I see most often are misconfiguration and kernel/runtime bugs — plus a third one that shows up in AI systems: policy leakage.

¹ https://www.luiscardoso.dev/blog/sandboxes-for-ai

18. messh+s6k[view] [source] 2026-01-15 20:03:53
>>simonw+(OP)
see also https://shellbox.dev/ which addresses similar problems. I like it better as it uses pure ssh
[go to top]