WSLWindowsT3 CodeAugust 9, 2026

Running T3 Code on Windows with WSL

T3 Code has a native Windows build. I don't use it. If you do most of your work inside WSL, like I do, the Windows build fights you. Point it at a project in your WSL filesystem and Git breaks.

So I went the other way. I installed the Linux build inside WSL and let WSLg render it as a window on my Windows desktop. Inside WSL the Linux build sees a native Linux environment. Git and everything else just work.

Why not the Windows build?

The Windows build expects Windows tooling. When your project lives in WSL, the Windows app can't cleanly use WSL's Git, SSH keys, or shell config. Git operations fail or misbehave, because it's a Windows process talking to a Linux filesystem through a translation layer.

The Linux build inside WSL has none of that. It's a native Linux process using native WSL Git, keys, and shell. Whatever works in your terminal works in the editor.

The tradeoff is that you need a way to show a Linux GUI on your Windows desktop. That's exactly what WSLg is for.

What WSLg gives you

WSL2 ships with a built-in way to run GUI Linux apps. It's called WSLg. It bundles an X server, a Wayland compositor, and PulseAudio, so any Linux app that opens a window renders directly on your Windows desktop. You install nothing extra. It's part of WSL on recent Windows 10 builds and Windows 11.

The catch: the window is a Linux window. It renders on your Windows screen, but it's styled and behaves like a Linux app, because that's what it is. You can't fix that by tweaking WSL. It's cosmetic.

The setup

My stack:

  • Distro: Debian 12 (bookworm). Ubuntu should work the same. Nothing here is Debian-specific.
  • Install: I downloaded the Linux .deb from the T3 Code GitHub releases and installed it inside WSL.

Install it like any .deb:

sudo apt update
# let apt pull in dependencies:
sudo apt install ./T3-Code-*.deb

Missing dependencies

This bit me first. A bare Debian install doesn't have everything a Chromium-based app needs. The .deb pulled in most of it. If the app won't launch or throws library errors, install the common Electron/Chromium deps:

sudo apt install libgtk-3-0 libnss3 libatk-bridge2.0-0 libxkbcommon0 libasound2 libgbm1 libdrm2

Then launch it. On WSLg you don't set DISPLAY yourself. WSLg exports it, usually as :0, along with its Wayland socket.

The icon problem

A desktop app with no menu icon is a pain, and getting the icon to show up in Windows was one of the more annoying parts.

Step 1: get the icon file out

The app bundles a PNG icon. I extracted it to ~/t3code.png so the shortcut has a stable path to point at:

# extract the icon from the AppImage, or copy it out of the installed package
# e.g. into your home directory

Step 2: write a .desktop file

WSLg picks up apps from ~/.local/share/applications. That's how things appear in your Start menu. Mine looks like:

[Desktop Entry]
Name=T3 Code
Exec=/home/richie/T3-Code-0.0.25-x86_64.AppImage --no-sandbox
Icon=/home/richie/t3code.png
Type=Application
Terminal=false
Categories=Development;

The --no-sandbox flag matters. Chromium apps often fail to start under WSLg without it. If the window never appears, add it.

Now it should show up in the Windows Start menu with its icon. If it doesn't, run update-desktop-database ~/.local/share/applications.

The update problem (still unresolved)

This one I haven't solved.

When T3 Code updates, it doesn't touch the existing file. It renames the AppImage and bumps the version in the filename. T3-Code-0.0.25-x86_64.AppImage becomes T3-Code-0.0.32-x86_64.AppImage. But my .desktop file hard-codes the old name:

Exec=/home/richie/T3-Code-0.0.25-x86_64.AppImage --no-sandbox

So after an update the Start menu shortcut still points at 0.0.25, which no longer exists, and it won't open. My workaround is to rename the new AppImage back to the old name after each update:

mv T3-Code-0.0.32-x86_64.AppImage T3-Code-0.0.25-x86_64.AppImage

It works, but it's fragile. A cleaner fix is a stable filename with no version in it. Symlink T3-Code.AppImage to the current release and point the .desktop file at the symlink, so updates only need to relink. I haven't set that up yet. That's the direction I'd go if the updater cooperates.

What still doesn't work

Two issues, both open.

  1. The window looks like a Linux window, not a Windows one. WSLg renders the app through its X server, so it gets a Linux-style title bar and theming. Functionally fine. Visually it never matches native Windows apps.

  2. The clipboard doesn't work in the window. Copy-paste between a Windows app and the WSL shell works fine, and text moves back and forth between Windows windows and the WSL window. But the system clipboard, sharing clipboard contents between a Windows app and the T3 Code window, doesn't. I haven't found a fix.

Summary

The path that works:

  1. Install a WSL distro. Debian 12 here, Ubuntu works too.
  2. Install the Linux .deb from GitHub releases. Add Chromium deps if it won't start.
  3. Use --no-sandbox in the launch command so it opens under WSLg.
  4. Extract the icon, drop a .desktop file in ~/.local/share/applications, and the app appears in the Windows Start menu with its icon.
  5. Expect to rename the AppImage back after each update, because the shortcut hard-codes the versioned filename.

The Windows build exists, but if you live in WSL it gets in your way. Git breaks, and it never quite connects to your project the way you'd hope. Running the Linux build inside WSL means Git and everything else just work. You pay for it with a Linux-looking window and a limited clipboard. For me that trade is worth it. I'm writing this from inside T3 Code, running on WSL, on a Windows machine.