GitHub Trusted Remote Execution/trusted Remote execution: Sandboxed Rhai script execution engine with Cedar policy authorization for every system operation.

Justy Okay so — you know that feeling when someone hands you a script and goes 'just run this on the server'? And you're like, sure, what could it possibly do. That's the whole problem REX is solving.

Cody Yeah, and the uncomfortable truth is most teams just… accept that. You either audit the script manually or you trust the person who wrote it, and neither of those scales.

Justy Right, right.

Cody REX is a script execution engine — scripts are written in Rhai, which is an embedded scripting language that compiles into a Rust runtime. The key thing is the script has zero direct access to the host. Every operation — opening a file, reading a directory, making a network call, touching a process — goes through a Rust API layer, and that layer checks a Cedar policy before anything actually executes.

Justy Mm-hm.

Cody Cedar is Amazon's authorization policy language — it's the same thing that powers some of the IAM-adjacent stuff in AWS. You write permit statements that say, this principal can perform this action on this resource. REX just wires that into every single syscall the script tries to make.

Justy So it's not like a one-time sandbox check at startup — it's checking on every operation as the script runs.

Cody Every operation. And there's a detail in the repo I actually liked — they use file descriptors instead of paths wherever they can, which mitigates TOCTOU attacks. That's the class of bug where you check if a path is safe, then something swaps the file out before you actually open it. Using the descriptor means you already have the handle, nothing can be swapped underneath you.

Justy Oh interesting.

Justy Okay I want to come back to who actually builds with this. But — did you sleep on the flight? Because you look like you got maybe two hours.

Cody Three. I had a middle seat and the guy next to me had a podcast going with no headphones. Anyway — yeah, who's the user here.

Justy My read is it's ops teams and platform engineers, anyone building something where semi-trusted or fully external code has to touch real infrastructure. SaaS vendors that let customers run automation scripts, internal platforms where different teams have different trust levels. That's the story.

Cody Yeah, that fits. And honestly the workspace structure in the repo reflects that — there are separate SDK crates for file I/O, networking, process management, system info, disk. Each one is a safe Rust wrapper with Cedar authorization baked in. So if you only want to expose file operations and nothing else, you just don't register the network bindings.

Justy That's a clean way to do it. What's your honest read on the adoption friction though? Because Cody, I looked at the quick-start and Cedar is not exactly something most people already know.

Cody That's real. Cedar is expressive but it has a specific mental model — entities, actions, attributes, conditions. If you've never touched it the first policy file feels a little ceremonial. And Rhai is not Python. The people who'll reach for this fastest are already living in Rust or have a security-first culture that makes the overhead feel worth it.

Justy Sure.

Justy Though — the quick-start is genuinely not bad. It's cargo install rex-runner, write a Cedar policy file, write a Rhai script, pass in JSON arguments, run it. That's five steps and you have a working example.

Cody And the repo actually suggests removing one of the permit statements and re-running to watch it deny. Which is a smart way to demo it — you feel the enforcement immediately rather than just reading about it.

Justy 'Here's how to break it on purpose.' That's good onboarding honestly.

Cody Right? Most security tools show you the happy path and you don't actually believe it works until something gets blocked.

Justy Exactly. So for someone who wants to actually try this — what's the move?

Cody Start with the quick-start, run it clean, then pull out a permit and watch the authorization error come back. After that, the Cedar Policy Guide in the repo docs is the right next read — it maps Cedar entities and actions to the actual REX operations so you understand what you're writing permissions for. That's where it clicks.

Justy Mm-hm.

Cody Solo builder angle I'd try: take a maintenance script you already have — something that reads logs, checks disk, whatever — and try wrapping it. Write the Cedar policy for only what it actually needs to touch. I'd bet most people over-permit by default and this forces you to be precise about it.

Justy That's a good forcing function. I like that framing — you're not building something new, you're just putting a real fence around something you already trust too much. Alright Cody, I'm going to go find coffee that actually exists in your kitchen — this was a good one.