Sandboxed Execution

See LuaU Sandbox for the technical details of what is and is not available inside rule scripts.

Supply chain security implications

When you add a third-party codegen rule as a dependency, you are running code that has full access to your parsed C++ AST, every field name, type, namespace, and annotation in your headers.

In a conventional system (shell scripts, Python plugins, Clang plugins), this code runs with your process’s full permissions. A malicious or compromised rule could read arbitrary files, exfiltrate data, or modify your build outputs.

The LuaU sandbox eliminates this attack surface. A rule, regardless of source, cannot:

• Read files outside the entity JSON it was passed
• Write files (the engine handles all writes)
• Make network calls (without explicit config permission)
• Spawn subprocesses
• Persist state between invocations

The worst a malicious rule can do in the default sandbox is produce incorrect output text, which is visible in the diff viewer and in version control.

Auditability

LuaU rule scripts are small, readable files. A complete rule is typically 30–80 lines. Auditing a third-party rule for safety takes minutes, not hours. The language is deliberately constrained: there is no loadstring, no loadfile, and no runtime code evaluation of any kind.

A rule may require a component, and that is the one thing it can pull in — but it is not a dynamic chain. The complete set of loadable modules is fixed before any script runs: codegen reads each component from your .codegen/shared/ directory itself and hands the sandbox a closed map, so a require is a lookup in that map, never a path and never a fetch. Everything a rule can reach is therefore sitting in your own repository, in your diffs, readable before you run it.

Reproducibility

Rules are pure functions. Given the same input AST, a rule always produces the same output. This means generated files are reproducible: checked into version control, they are stable across machines and CI runs. A diff in a generated file is always caused by a change in the source header or the rule script, never by environmental noise.