niri-session starts Wayland session with SHLVL=1 environment variable set

[antoineco]

Description

The niri-session startup script imports the entirety of the login manager's environment into systemd, so that it becomes available to the niri.service unit (and other user services).

It would be a good idea to sanitize the session's environment by excluding a few of these environment variables, similarly to how uwsm does, mainly to avoid issues with subshells spawned by terminal emulators inside Niri.

Demonstration

Here is what the process tree looks like after starting Niri via niri-session, from a greeter like greetd:

# ps axjf
 PPID    PID   PGID   COMMAND
    0      1      1   /run/current-system/systemd/lib/systemd/systemd
    1   5068   5068   /nix/store/an..-greetd-0.10.3/bin/greetd --config /nix/store/dn..-greetd.toml
 5068   5128   5128    \_ /nix/store/an..-greetd-0.10.3/bin/greetd --session-worker 12
 5128   5143   5128        \_ /nix/store/fw..-bash-5.3p3/bin/sh /run/current-system/sw/bin/niri-session -l
 5143   5186   5128            \_ systemctl --user --wait start niri.service
    1   1836   1836   /run/current-system/systemd/lib/systemd/systemd --user --deserialize=10
 1836   1859   1836    \_ (sd-pam)
 1836   5187   5187    \_ /nix/store/69..-niri-25.11/bin/niri --session
 1836   5303   5187    \_ /nix/store/p5..-wezterm-0-unstable-2025-10-14/bin/wezterm-gui
 5303   5315   5315        \_ -zsh
 5315   5459   5459            \_ /nix/store/cs..-sudo-1.9.17p2/bin/sudo -i
 5459   5469   5469                \_ /nix/store/cs..-sudo-1.9.17p2/bin/sudo -i
 5469   5470   5470                    \_ -bash
 5470   5532   5532                        \_ ps axjfww

If we look at the environment of the process /bin/sh /bin/niri-session -l (5143), we see that SHLVL equals 0 (expected and desired):

# grep -a SHLVL= /proc/5143/environ
SHLVL=0

However, somewhere inside the niri-session script, /bin/sh's environment gets exported, which means that variables such as SHLVL, SHELL, TERM or PWD are also exported inside the environment of the Wayland session.

If we look at the environment of the process systemctl --user --wait start niri.service (5186), we see that SHLVL now equals 1 (undesired):

# grep -a SHLVL= /proc/5186/environ
SHLVL=1

Expectedly, the same thing can be observed in the environment of the user's process /bin/niri --session (5187):

# grep -a SHLVL= /proc/5187/environ
SHLVL=1

Workaround

The environment can be sanitized by editing the niri.service user unit, for instance via a drop-in:

systemctl --user edit niri.service

# /home/myuser/.config/systemd/user/niri.service.d/override.conf
[Service]
UnsetEnvironment=SHLVL
UnsetEnvironment=SHELL
UnsetEnvironment=TERM
UnsetEnvironment=PWD

I would suggest to either:

• Add these UnsetEnvironment directives by default inside niri.service.
• Avoid using systemctl --user import-environment without any argument (which is deprecated and prints a warning).
• Call systemctl --user unset-environment SHLVL SHELL TERM PWD after import-environment.

System Information

• niri version: niri 25.11
• Distro: NixOS

[Sempyos]

This is probably better off as a discussion as it is not actively an issue, nor do we know if there will be adverse consequences if we change this

[antoineco]

For most people, probably not. Unfortunately a third-party script I use broke when executed inside a Niri session, because that script is making assumptions on the subshell level. (Data shows that I'm not the only one.)

Essentially, every shell appears as a subshell in Niri, which can be disruptive if not handled properly. Neither Sway nor Hyperland have this issue.

The same happened in Ubuntu long ago due to a regression apparently, and was categorized as a bug: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1707977

[onelocked]

You might want to have a look at UWSM, it properly sets the environment and cleans up stuff. The uwsm in my example starts niri with the --session flag (niri --session) bypassing the niri-session shell script. Hope this helps :)

          programs.uwsm = {
            enable = true;
            waylandCompositors = {
              niri = {
                prettyName = "niri";
                comment = "Niri compositor managed by UWSM";
                binPath = "/run/current-system/sw/bin/niri";
                extraArgs = [ "--session" ];
              };
            };
          };
          services = {
            greetd = {
              enable = true;
              settings = {
                default_session = {
                  command = "${lib.getExe config.programs.uwsm.package} start niri-uwsm.desktop";
                  user = username;
                };
              };
            };
          };

[antoineco]

Yup, as mentioned in my description uwsm does it correctly.
However, one shouldn't need to use uwsm in order to run Niri with a sane environment. The author himself mentioned that Niri's systemd integration was designed to just work (and aside from what I reported this integration was been working great for me so far).

[onelocked]

oh I totally forgot you mentioned uwsm, my bad.

I agree with you on this one. Hope this discussion gets more attention.

However, one shouldn't need to use uwsm in order to run Niri with a sane environment.

[antoineco]

Since NixOS configurations are being shared in that thread, here is what I came up with, as an alternative to the initial workaround (systemd drop-in) I proposed in the description:

1. I created a niri package override with a patch for the niri-session script.

   { niri }: niri.overrideAttrs { patches = [ ./systemd-no-import-env.patch ]; }

   systemd-no-import-env.patch simply ensures that only the PATH variable is exported to systemd from Bash. This is important for Niri's spawn action to work because PATH includes NixOS' bin directories.
   (I also skipped the export to the DBus activation environment, but that's probably optional.)

2. I overlayed Nixpkgs' niri with the above package override:

   (final: prev: {
     niri = final.callPackage ../packages/niri { inherit (prev) niri; };
   })

The environment of the Niri session (Wayland) is now free of the Bash garbage.
This is a little cleaner than a systemd drop-in (inclusive vs. exclusive) and does not lean on a session manager like uwsm, but has the disadvantage of requiring a build from source of Niri upon activation.