Files and Folders

Everything TuxBlox installs lives in one folder: ~/.tuxblox. The only exceptions are the desktop entry and icon files, which have to go in standard XDG locations for your desktop to find them.

Nothing is installed system wide, and nothing needs root.

The TuxBlox folder

~/.tuxblox/
├── TuxBloxLauncher        the launcher you use
├── TuxBloxInstaller       kept around for updates and uninstalling
├── TuxBloxBootstrapper    downloads and updates Roblox itself
├── studio-mcp             the Studio MCP helper
├── settings.json          your settings and FastFlags
├── versions.json          which Roblox builds are installed
├── launcher.lock          stops two launchers running at once
├── COPYRIGHT.txt          notices for everything bundled
├── LICENSE                the GPLv3 text
├── compat/                the compatibility layer
├── libtuxblox/            libraries the launcher's interface needs
├── logs/                  session logs
├── runtime/               the virtual drive
├── RobloxPlayer/          Roblox's own downloaded installer
└── RobloxStudio/          the same, for Studio

settings.json

Everything from the Settings tab, plus your FastFlags.

{
  "channel": "stable",
  "auto_update": false,
  "env_vars": "",
  "gpu": "",
  "haptics": true,
  "webview_gpu": true,
  "norollback": false,
  "send_crash_reports": true,
  "fast_flags": {
    "player": [],
    "studio": []
  }
}

norollback has no switch in the launcher and is off unless you put it there. With it on, TuxBlox stays on the version it has when the channel publishes an older one, instead of following the channel back. It is for a copy you built yourself, which is ahead of anything published.

You can edit it by hand. TuxBlox rewrites the file whenever you change something in the launcher, so do not have both going at once.

If the file is missing or damaged, TuxBlox falls back to defaults rather than refusing to start. A broken settings file costs you your settings, never your install.

versions.json

Bookkeeping for the Versions tab: which Roblox builds are installed, which one is active, and when each arrived.

TuxBlox does not trust this file on its own. It checks the virtual drive and corrects the file against what is actually there, so deleting it is harmless.

compat/

The compatibility layer.

This folder is replaced wholesale by updates. Anything you put in it goes away.

libtuxblox/

Libraries the launcher's interface needs, so the launcher looks and behaves the same regardless of what your distribution ships.

It has to stay next to TuxBloxLauncher. Moving one without the other breaks the launcher.

logs/

One file per Roblox session, named after the app, the start time in UTC, and the process id:

Studio-20260912T143107Z-8814.log

Roblox's own logs from the same session are appended to the end of the file, so one log has both halves of the story. See Logs and Diagnostics.

Old logs are never deleted automatically. Clear them out yourself if the folder gets large.

The virtual drive

~/.tuxblox/runtime/ is the virtual drive, the Windows shaped world Roblox lives in.

runtime/
├── pfx/
│   ├── drive_c/        the C: drive
│   ├── dosdevices/     drive letter mappings
│   ├── system.reg      the registry
│   ├── user.reg
│   └── userdef.reg
├── version             which TuxBlox built this drive
├── config_info         what it was built with
└── tracked_files       which files TuxBlox owns, as opposed to Roblox

Roblox itself installs into pfx/drive_c/, in a per user folder, with one directory per installed build.

tracked_files is how an update can replace TuxBlox's own files without touching anything Roblox or you put in the drive.

Warning

Do not share your virtual drive, and do not put it in a bug report. It can contain your Roblox session cookies, which is the same as handing over your account. Send the log file instead.

There is no Z: drive

On most Wine setups, Z: maps your entire Linux filesystem into the Windows world. TuxBlox removes it, because a Z: drive is one of the most reliable ways to detect that a program is running under Wine, and Roblox lives entirely under C: anyway.

The practical effect: a Windows program run inside the drive cannot see your home folder. When you double click a .rbxl file, TuxBlox bridges that one file in rather than exposing everything.

Colours

TuxBlox matches the drive to your desktop's light or dark setting the first time it sets the drive up, and then leaves the colours alone. Anything you change yourself under Control Panel\Colors in the drive's registry stays changed, and is never written over on a later launch.

The other side of that is that switching your desktop between light and dark afterwards does not follow through to the drive. Wiping the drive and letting it rebuild picks up your current setting again.

Classic message boxes

The small dialogs Windows programs put up inside the virtual drive are drawn to match a modern desktop: roomy margins, a right aligned row of rounded buttons, and the button you would press with Enter outlined in your desktop's accent colour. The colours come from your own theme, so they follow it in light and dark.

If you would rather have the plain, older looking dialog, set a value in the drive's registry:

HKEY_CURRENT_USER\Software\TuxBlox\MessageBox
    Classic = "1"

Anything else, or no value at all, gives the modern one. The change applies to the next dialog that opens, with nothing to restart.

The one TuxBlox draws itself is the message Roblox puts up when it stops unexpectedly. That one keeps the modern look whatever this setting says, and it follows your colours and font the same way.

The text in those dialogs uses your desktop's own font, at your desktop's size. TuxBlox reads it at every launch, so changing your font settings is enough -- there is nothing to set here. If it cannot work out what you use, it leaves the drive's own font alone.

Resetting it

Wipe prefix in Settings deletes the whole thing. The next launch rebuilds it and reinstalls Roblox, which takes about as long as your first launch did.

Your settings and FastFlags live outside the drive and survive.

Outside the TuxBlox folder

That is the complete list. Uninstalling removes all of it, apart from the scratch folder, which your computer clears out on its own.

Scratch files

Windows programs write their working files into AppData\Local\Temp inside the drive, and nothing in Windows ever clears that out. TuxBlox points it at a folder of its own under your computer's temporary directory instead, one per drive, so your computer empties it on the same schedule as everything else there.

The folder is named after your user, and TuxBlox refuses to use one it does not own, so two accounts on the same computer cannot write through each other's. If your computer has no temporary directory at all, the drive keeps its own folder and nothing changes.

Backing things up

Everything else can be downloaded again. There is no point backing up compat/ or an installed Roblox build.