Command Line Reference

Every TuxBlox program you can run from a terminal, and what its options do.

Nothing here is required for normal use. This page exists for scripting, for headless machines, and for people who would rather not click.

TuxBloxLauncher

~/.tuxblox/TuxBloxLauncher

Run with no arguments, it opens the launcher window. With an argument, it does one specific thing and exits.

Two more exist but are meant for TuxBlox's own use rather than yours:

--run-exe only accepts RobloxStudioBeta.exe or RobloxPlayerBeta.exe and refuses anything else. It ignores the rest of the path and works out which Roblox to start from the filename, which is why an old shortcut keeps working after Roblox updates.

Examples

# Start Studio from a script
~/.tuxblox/TuxBloxLauncher --launch-studio

# Open a place file
~/.tuxblox/TuxBloxLauncher --open-file ~/Places/MyGame.rbxl

Note

Only one launcher window can be open at a time. The direct launch options above are not affected by that, so you can use them while the window is open.

TuxBloxInstaller

~/.tuxblox/TuxBloxInstaller

Installs TuxBlox into ~/.tuxblox, upgrading an existing install in place if it finds one, then starts the launcher.

Usage: TuxBloxInstaller [options]

  --headless         Report progress on the terminal instead of
                     opening a window. Needs no display.
  --nolaunch         Don't start the launcher once the install
                     finishes.
  --uninstall        Remove TuxBlox from this system instead of
                     installing it.
  --channel <name>   Release channel to install from (default: stable).
  --latest           Install the newest release on the channel
                     instead of this installer's own version.
  --version          Show the build version and exit.
  -h, --help         Show this help and exit.

Unknown options are an error rather than being ignored, so a typo cannot quietly change what the installer does.

Which version gets installed

An installer installs the version it was built for — the one --version prints. You get exactly the TuxBlox that came with the installer you downloaded, no matter how long ago you downloaded it, and keeping up to date stays the launcher's job.

--latest installs the newest release on your channel instead. If the installer's own version is not published on the channel you picked, it says so and points you at --latest rather than quietly installing something else.

Examples

# Install over SSH, with no desktop
./TuxBloxInstaller --headless --nolaunch

# Install the canary channel
./TuxBloxInstaller --channel canary

# Install the newest release instead of this installer's own version
./TuxBloxInstaller --latest

# Remove TuxBlox completely
~/.tuxblox/TuxBloxInstaller --uninstall

The compatibility layer

~/.tuxblox/compat/main

This is the layer itself. The launcher drives it for you, and you will rarely call it directly, but it is a normal program you can run.

Options:
  --help                  Show this help message
  --version               Show TuxBlox version
  --immediate             Run TuxBlox without draining the prefix, must be
                          used with the "run" argument
  --destroy               Destroys the prefix
  --verify-integrity      Check that the executable is signed by Roblox
                          before running it

Arguments:
  run <executable>        Runs the specified executable

Options go before the executable. Anything after it is passed to the program being run, not read by the layer.

--version prints 2.7.0-stable: the version, then the update channel that build came from. Every TuxBlox program answers the same way.

It needs to be told where the virtual drive is, through TUXBLOX_PREFIX:

TUXBLOX_PREFIX=~/.tuxblox/runtime ~/.tuxblox/compat/main --version

run and --immediate

run starts a program and then waits for the virtual drive to empty out, meaning every Windows process inside it has exited. That is what you want for Roblox itself.

run --immediate skips the wait. Use it for anything that should return as soon as its own process ends, such as a helper running alongside Studio. Studio MCP is exactly this case.

--destroy

Deletes the virtual drive. Same effect as Wipe prefix in the launcher's settings, which is the friendlier way to do it.

A trap worth knowing

A Windows executable has to live inside the virtual drive's C: to be runnable. Pointing run at an executable that sits elsewhere on your Linux filesystem fails with exit code 139 and no output at all, which looks exactly like a crash and is not one.

Copy it in first:

cp probe.exe ~/.tuxblox/runtime/pfx/drive_c/
~/.tuxblox/compat/main run "$HOME/.tuxblox/runtime/pfx/drive_c/probe.exe"

The path must be absolute. A relative one fails differently, with wine: failed to open.

Tip

Read the program's output through a pipe, not a file redirect. Redirecting straight to a file gives the Windows program empty output handles and you end up with a zero byte file, which looks like the program printed nothing.

studio-mcp

~/.tuxblox/studio-mcp

Runs Roblox's Studio MCP server through the compatibility layer. Takes --version and --help, and passes anything else it is given to the server.

This is what you point an AI client at. Use the absolute path, since most MCP clients will not expand ~.

Note

This replaced mcp.sh in 2.7.0. Updating removes the old script, so a client still configured with ~/.tuxblox/mcp.sh needs repointing at ~/.tuxblox/studio-mcp.

See Studio MCP.