The sandbox’s lifecycle is independent of the PR so that the same user or someone else in your team, like an engineer can come back to the same session and keep building until the result is ready to merge. So you can choose to iterate on the first drafts on the same sandbox. Curious, what flow you envision in your case?

Thanks! Lots of use cases. For the workflow you mentioned, the idea is marketing sends you a PR with the live preview. You can see the UI changes and if you need to change anything, you can open the session, which will let you modify, backtrack, or continue their work inside the same sandbox they used.

I agree, I do see static analysis and runtime sandbox as complementary tools. Do you see static analysis tools performed by the agent itself inside the sandbox or via CI tools in the pull request itself (like github actions or buildkite)?

all of our customers are using Anthropic APIs for programmatic use. Codex and other providers let you use Oauth. But inside of a sandbox, you can technically use max plan since it is the same as using Claude locally.

Good point. We launched our cli recently exactly for this. It comes with skills, so you can use your own local setup (Claude Code, Cursor, Codex), to build up templates, spin up sessions, and set things up. You can scope what agents can and can't do. I wouldn't recommend using an agent to set up guardrails. There should be some human oversight for this.

Thanks! The demo is not the best we have. Probably did a lot of zooming in and zooming out.

thanks! we used to build a lot of internal software / scripts for conferences or one-off data crunching. We saw LLMs getting better and how the world would go from building software for localhost to needing it to deploy. I then wrote an essay about my thoughts as software goes to zero back in January. https://www.gustrigos.com/essays/on-abundant-ephemeral-softw...

I wrote a simpler version of this for Claude Code as open source if that's useful to you: https://github.com/smithy-ai/smithy-ai

It's doing context management in the same way, but adds a learning loop based on code reviews. Currently works with Gitlab, Forgejo and Gitea but happy to accept a PR for Github support or co-write it.

We're using a split license: apache-2.0 for the CLI/SDK/sandbox, MIT for templates, AGPLv3 for server components. Not copyrighted.

But beyond that, we are managing a higher level abstraction than sandboxes.

Nori looks really cool, will set up sometime to exchange notes. But with regards to your questions: - Proxying keys: We allow users to setup keys in the sandbox and use CLIs for some cases but we also support an egress gateway that intercepts and injects keys on the way out, which supports the major api integrations we offer. - We still allow fly.io for deployments (so after a sandbox has a final app, you can deploy it and move out of the ephemeral sandbox). We never used them for sandboxing, but we will integrate into https://sprites.dev/ soon. - For the CLI, we allow you to SSH into the remote sandox since a lot of workload add too much stress to local machines

Curious about what sandbox provider you use to power Nori and how you are handling the secrets/keys issue?