Launching today
cdbx.ai
AI-native development platform for full-stack apps
9 followers
AI-native development platform for full-stack apps
9 followers
cdbx.ai is an AI-native dev platform merging a browser IDE with an execution sandbox for humans and AI agents. • Experiments: Instant, client-side browser environments for zero-latency UI prototyping. • Projects: Full server-side containers for heavy full-stack and backend workloads. • Runner API: Secure sandbox executing code across 30+ languages in milliseconds. • MCP Connectors: Native support linking Cursor or Claude straight to your workspace.
The MCP connector piece is the interesting part to me, not the sandbox speed. Once Cursor or Claude has a direct line into the workspace, what actually stops an agent from running something destructive or reaching outside the container it's scoped to, is that enforced at the container boundary or is it more of a permissions/trust thing on the agent's side? Curious how much of that is your responsibility versus the agent tool's.
@galdayan Good question, thanks for asking. It's the container, not the agent's good behavior. When Cursor or Claude connects over MCP, it doesn't get a shell into your workspace. It only gets a handful of specific tools: read files, run code, create a project, each tied to an API key that's scoped to read/write/execute and checked against what you actually own. There's no "run any command" option in there, so there's nothing for a rogue prompt to hijack even in the worst case.
Code execution itself runs in a throwaway container with no network access and dropped permissions, so even if something went sideways it can't reach out and touch anything else. For our persistent project workspaces we run an extra layer of kernel isolation plus network rules blocking things like cloud metadata and private IPs.
So it's on us, not the agent. Cursor or Claude is just an API client with limited scopes — it doesn't get extra trust for being an AI.
One thing that would really level this up for me is a built-in shareable preview link so teammates can view a running app without needing their own account or setup. Right now collaboration feels like it needs more friction than it should.
@eyllyaskb3pm you can make your experiments or projects public and share them with anyone 😊
honestly the Runner API sounds super useful, but it would be great if there was a way to share a live preview link with someone outside your workspace, basically like a public deploy option directly from the sandbox so collaborators can see what you are building without needing their own account
@nerimanelifzkq you can make your experiments or projects public and share them with anyone 😊
the runner api supporting 30+ languages in milliseconds is honestly wild, kind of wish something like this existed when i was wrestling with local dev setups last year
@dceteli47457 I hope you can use it now at least. Let me know if there is something missing or if you think there is a way to improve it 😊