Summary
NAPS2 creates its worker IPC socket inside $TMPDIR. On macOS, unix domain socket paths are
limited to 104 bytes, so when $TMPDIR is long the worker cannot start and the scan silently
returns 0 pages. Anything launching NAPS2 from macOS Shortcuts hits this, because Shortcuts
sets TMPDIR to a per-helper subdirectory.
Failure is silent from the user's perspective: NAPS2 prints "0 page(s) scanned" and exits 0.
The underlying exception only appears on stderr.
Environment
Same as Issue 1 (NAPS2 8.3.2, macOS 26.5.2, Apple Silicon).
Steps to reproduce
- Create a Shortcut in the macOS Shortcuts app with a "Run Shell Script" action calling
NAPS2 console -a -p "Some Profile".
- Assign a keyboard shortcut and run it with a document in the feeder.
Or reproduce directly:
export TMPDIR=/var/folders/nd/cf4pd31x6816khp2xf97kxxm0000gn/T/com.apple.shortcuts.mac-helper/
NAPS2 console -a -p "Some Profile" -v
Actual
Beginning scan...
Starting scan 1 of 1...
ArgumentOutOfRange_PathLengthInvalid, /var/folders/nd/cf4pd31x6816khp2xf97kxxm0000gn/T/com.apple.shortcuts.mac-helper//CoreFxPipe_NAPS2.Worker.5928, 104 Arg_ParamName_Name, path
ArgumentOutOfRange_ActualValue, /var/folders/nd/cf4pd31x6816khp2xf97kxxm0000gn/T/com.apple.shortcuts.mac-helper//CoreFxPipe_NAPS2.Worker.5928
0 page(s) scanned.
Exit code is 0. The same command with the default TMPDIR scans normally.
Note the doubled slash in the socket path (.../mac-helper//CoreFxPipe_...), which suggests a
trailing separator is not being normalized when the pipe path is composed.
Expected
Either the worker socket is placed somewhere path-length-safe regardless of $TMPDIR, or the
failure is reported as an error with a non-zero exit code instead of "0 page(s) scanned".
Background
This is the .NET named-pipe-on-unix path limit: see
dotnet/runtime#79503 — PipeStream composes
$TMPDIR/CoreFxPipe_<name> and the total must fit in sockaddr_un.sun_path (104 bytes on
macOS). The default macOS TMPDIR (~49 chars) leaves room; Shortcuts' helper subdirectory
does not.
Workaround
Set a short TMPDIR before invoking NAPS2:
Summary
NAPS2 creates its worker IPC socket inside
$TMPDIR. On macOS, unix domain socket paths arelimited to 104 bytes, so when
$TMPDIRis long the worker cannot start and the scan silentlyreturns 0 pages. Anything launching NAPS2 from macOS Shortcuts hits this, because Shortcuts
sets
TMPDIRto a per-helper subdirectory.Failure is silent from the user's perspective: NAPS2 prints "0 page(s) scanned" and exits 0.
The underlying exception only appears on stderr.
Environment
Same as Issue 1 (NAPS2 8.3.2, macOS 26.5.2, Apple Silicon).
Steps to reproduce
NAPS2 console -a -p "Some Profile".Or reproduce directly:
Actual
Exit code is 0. The same command with the default
TMPDIRscans normally.Note the doubled slash in the socket path (
.../mac-helper//CoreFxPipe_...), which suggests atrailing separator is not being normalized when the pipe path is composed.
Expected
Either the worker socket is placed somewhere path-length-safe regardless of
$TMPDIR, or thefailure is reported as an error with a non-zero exit code instead of "0 page(s) scanned".
Background
This is the .NET named-pipe-on-unix path limit: see
dotnet/runtime#79503 —
PipeStreamcomposes$TMPDIR/CoreFxPipe_<name>and the total must fit insockaddr_un.sun_path(104 bytes onmacOS). The default macOS
TMPDIR(~49 chars) leaves room; Shortcuts' helper subdirectorydoes not.
Workaround
Set a short
TMPDIRbefore invoking NAPS2:export TMPDIR=/tmp/