Design a sandboxed Lua execution environment so untrusted player-authored mod scripts can't access the host game process unsafely

Steps

1. Run each mod script in its own Lua state (lua_newstate) rather than sharing a global state with trusted game code, so mods can't pollute or read engine internals.
2. Strip or replace dangerous standard library functions before executing mod code — remove or sandbox io, os.execute, os.remove, dofile/loadfile, and raw require so scripts can't touch the filesystem or spawn processes.
3. Expose only a deliberate, whitelisted API surface (game-specific functions/tables) to the mod environment instead of the full global table, using a custom environment table with an explicit env argument to load (or _ENV in Lua 5.2+).
4. Enforce resource limits with a debug hook (lua_sethook) that counts instructions and aborts long-running or infinite-loop scripts, plus caps on memory allocation via a custom allocator passed to lua_newstate.
5. Run each mod's Lua state on a worker thread/process boundary if you need OS-level isolation in addition to language-level sandboxing, especially for community-distributed mods you haven't reviewed.