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

Direct answer

Inspect the engine command-line flags and the shell-escape allow-list in the active texmf.cnf. Restricted mode is selected by flags such as --enable-write18 (or --shell-restricted in newer builds); unrestricted mode uses --shell-escape; and --no-shell-escape disables \write18 entirely. The permit list lives in a texmf.cnf variable—usually shell_escape_commands, though some releases expose it as shell_escape—and is compiled from the engine build plus local configuration. Do not assume that restricting \write18 also confines LuaTeX’s \directlua path; that boundary is governed by separate engine internals and must be verified independently.

Engine flags and texmf.cnf entries to inspect

First, capture the exact engine invocation used in CI. Build tools such as latexmk and arara can inject or override flags, so the developer workstation command may differ from the automated one. Run the build in verbose mode or inspect the CI log to see the final arguments passed to pdflatex, lualatex, or xelatex.

Next, locate the active configuration:

kpsewhich texmf.cnf

Open that file and search for the shell-escape policy entries. You are looking for a comma-separated allow-list of executables. Because variable names and defaults shift between TeX Live releases and OS packages, treat the exact key as version-dependent rather than portable.

Verifying the LuaTeX \directlua boundary

LuaTeX exposes the operating system through the Lua os and io libraries. A document can call os.execute or io.popen inside \directlua. Whether these calls are blocked, restricted, or allowed depends on the engine’s sandboxing configuration, which is not necessarily the same switch that controls \write18. Some builds harden the Lua VM independently; others leave it open even when \write18 is in restricted mode.

Practical verification steps

1. Identify the CI engine flags from the build log or by running latexmk -verbose (or the equivalent for your build tool).
2. Locate the configuration with kpsewhich texmf.cnf and inspect the allow-list entry (for example, grep -i shell_escape $(kpsewhich texmf.cnf)).
3. Compile a minimal test under the exact CI flags using only harmless commands:

\write18{echo write18_probe}
\directlua{os.execute("echo lua_probe")}

Observe whether each probe produces a side effect, a log message, or an error. If the \directlua probe executes while \write18 is blocked, the Lua path is bypassing the \write18 policy.

Missing diagnostic detail

The exact TeX Live release and LuaTeX version used in CI. The allow-list variable name, default command set, and Lua sandboxing behavior have changed across releases, so the specific texmf.cnf key to audit and the expected \directlua behavior depend on that version.