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 naive 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 way to obfuscate behavior behind dynamic require chains or runtime code evaluation.

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.