\write18 shell-escape permission boundary across restricted and unrestricted engine modes

The \write18 primitive lets a LaTeX document request an external program, but the engine—not the LaTeX kernel—decides whether that request is ignored, rejected, or executed. In a project that relies on an external tool such as repstopdf or makeindex, the same source may compile on a developer workstation yet fail in continuous integration because the engine is invoked with a different shell-escape mode. Modern engines expose three settings: no shell escape, restricted shell escape with a small allow-list, and unrestricted shell escape. The restricted list is compiled into the engine build and texmf.cnf, so a reviewer cannot infer permitted commands from the document alone.

The uncertainty deepens with LuaTeX, where \directlua combined with os.execute or io.popen can reach the operating system even when \write18 is blocked. Editors and build tools such as latexmk or arara pass their own flags, so interactive and automated builds may observe different permission boundaries. Because the allow-list and diagnostic wording change between TeX Live releases and engine builds, a configuration that works on one version cannot be assumed portable.

Which specific engine flags and texmf.cnf entries must be inspected to determine the exact set of commands allowed under restricted mode for a given TeX Live release, and how can a build configuration verify that the LuaTeX \directlua path is gated by the same policy rather than bypassing it?