Direct-file execution

On the other hand,
Runners.

Runners power nox run path/to/file. They are intentionally separate from project Riders: a Runner decides how one source file is launched, while a Rider decides how a declared target is built.

Dispatch

Paths, targets, and projects mean different things.

nox run .                        # first runnable project target
nox run hello                    # named project target
nox run examples/python/Test.py  # Runner for one source file
nox run examples/c/Test.c -- one two

An existing directory runs the project, an existing file resolves through the Runner registry, and any other value is treated as a target name. Everything after -- is forwarded to the child process unchanged.

Modes

Runtime, compile, or explain.

Runtime.fsx, .py, .js, .jsx, .mjs, .rb

dotnet fsi, Python, Node.js, or Ruby · Passes the source and forwarded arguments to the runtime.

Compile.c, .cc, .cpp, .cxx, .hs, .lhs, .d

C/C++, GHC, or a D compiler · Compiles into a temporary executable, runs it, then removes the artifact.

Registered, not implemented.rs, .go, .java, .cs, .swift, .zig, .ts, .tsx, .kt, .kts

The language toolchain · Reports an unsupported direct-file execution mode. Build targets may still use their Rider.

Arguments

Child status stays visible.

Runners locate tools through PATH. Runtime and compiled programs receive the forwarded arguments. A nonzero child exit status is returned by Nox; a signal termination becomes exit code 1. Temporary compile artifacts are removed after the run, including when the child finishes.

Direct-file support is deliberately narrower than project-target support. For example, Rust, Go, Java, C#, Swift, Zig, TypeScript, and Kotlin are registered so Nox can give a useful dependency or unsupported-mode message, but their file Runner is not implemented yet. Declare a target and use its Rider to build those languages.

Use a Rider for project builds →Read the run command →