T3 Code for NixOS

Nix flake packaging the official Linux builds of T3 Code from the GitHub releases of pingdotgg/t3code, for x86_64-linux and aarch64-linux:

• t3code: the desktop app, from the .deb.
• t3code-web: the standalone t3 server with its web interface, from the t3-<version>-linux-<arch>.tar.gz archive (the same build npx t3 runs).

Usage

Try it without installing:

nix run .
nix run .#t3code-web -- serve

In a NixOS flake configuration:

inputs.t3code = {
  url = "git+ssh://git@git.thomasave.be/thomasave/nix-t3-code.git";
  inputs.nixpkgs.follows = "nixpkgs";
};

# In a module:
nixpkgs.overlays = [inputs.t3code.overlays.default];
environment.systemPackages = [pkgs.t3code pkgs.t3code-web];

Options

pkgs.t3code.override { ... } accepts:

• passwordStore (default "gnome-libsecret"): Chromium keyring backend. Use "kwallet6" on Plasma, or null to let Chromium decide.

Updating

The built-in updater would install a downloaded .deb and is disabled through T3CODE_DISABLE_AUTO_UPDATE. Run ./update.sh to point sources.json at the newest stable GitHub release for both packages, then rebuild. Nightly and preview releases are ignored.

t3 update and t3 uninstall manage copies of t3 that the CLI downloads itself, outside of Nix, so updates also go through ./update.sh for this package. For a background server, a systemd unit that runs t3 serve is the Nix way of doing what t3 service sets up.

Packaging notes

• The app is Electron. It starts its backend server with the same binary and ships small native helpers in resources/ (screen capture for Hyprland and KDE, a libsecret helper and a resource monitor), which are patched with autoPatchelf.
• There is no setuid chrome-sandbox; Chromium uses the user namespace sandbox, which NixOS allows by default. The AppArmor profile is dropped.
• The napi-rs native module loaders look for /usr/bin/ldd to tell glibc from musl, and otherwise fall back to process.report.getReport(). patch-asar.py points them at the store's ldd inside app.asar, and the build fails if the string disappears.
• Prebuilt native modules for musl and for other architectures are removed.
• The coding agents themselves (Claude Code, Codex, ...) are not bundled and are looked up on PATH.
• t3 is a Node single executable application, so its JavaScript lives in a blob inside the ELF file. The package is not stripped, which would remove it, and is only patched with autoPatchelf. It finds the web client and its native modules next to the real executable, so bin/t3 is a symlink.