When your Lua code hits a breakpoint or the next step target, the debugger pauses. The dialog raises and activates with the paused line highlighted in the editor and the Variables, Watch, and Stack Trace panels repopulated; the rest of Wireshark is disabled and covered by a translucent vignette with a "Lua debugger paused" banner until you resume. Continue, Step, or closing the debugger return control to Lua so it can run the next line (or return from the current function).
Live capture is incompatible with this pause model — packets keep arriving from the capture device and would have to be dissected while a previous Lua call is still on the stack. The debugger is therefore forcibly suppressed for the duration of any live capture; see Section 14.2.1, “Live-capture suppression”.
A live capture keeps pulling packets off the interface and dissecting them for as long as the capture runs. Dissection routinely calls into Lua — every packet passes through any registered dissector, postdissector, or tap. Pausing Lua at a breakpoint while packets are still arriving would stall the capture pipeline on code that cannot make progress, or would try to call your Lua code again while its previous invocation is still frozen at the breakpoint.
To avoid that, the debugger auto-disables itself for the duration of any live capture:
If you need to step through a dissector on live traffic, stop the capture, re-enable the debugger if needed, and reload a saved capture file instead — offline dissection is fully compatible with pausing.
Applying preferences can redissect packets while the Preferences dialog is still open and modal. A pause there would leave neither the dialog nor the debugger usable, so the debugger is suppressed the same way as during a live capture from the moment the Preferences dialog opens until it closes. The debugger is restored before the redissection that OK starts, so breakpoints fire there as usual. The redissection that Apply starts runs while the dialog is still open and does not stop at breakpoints.