Sign up
View stargazersSign up

[Bug]: Integrated terminal can't use sudo: the desktop app runs with no_new_privs set, and every terminal inherits it#27880

opened10d agobyRRajvira10

What happens

In the T3 Code integrated terminal (desktop and when opened remotely from the mobile app), any sudo command fails immediately, before asking for a password:

1$ sudo pacman -Sc
2sudo: The "no new privileges" flag is set, which prevents sudo from running as root.
3sudo: If sudo is running in a container, you may need to adjust the container configuration to disable the flag.

So there's no way to do admin work from T3 Code, which matters most when you're remote and T3 is your only way into the machine.

Cause

The T3 Code desktop process itself has NoNewPrivs: 1, and the flag can't be cleared once set, so every terminal and agent it spawns inherits it:

1$ for p in $(pgrep -x t3code); do grep NoNewPrivs /proc/$p/status; done
2NoNewPrivs: 1 (all 5 t3code processes)
3
4parent chain of the main process:
533802 t3code NoNewPrivs=1 /opt/t3code-bin/t3code
61287 systemd NoNewPrivs=0 /usr/lib/systemd/systemd --user

Other Chromium-based apps launched the same way (Brave, Codex desktop) have NoNewPrivs: 0, so it isn't the launcher.

Agent sessions running under app-t3code-agents.slice also have NoNewPrivs: 1, which seems intended for sandboxing agents. My guess is that the desktop app picked the flag up when it was relaunched from inside such a sandboxed context. The current instance started (02:27:18) in the same second a t3code-codex-*.scope agent session ended, and systemd then created app-com.t3tools.T3Code-33802.scope for it. I haven't confirmed the exact relaunch path (update-and-restart vs. something else). If the app sets the flag on purpose, the integrated terminal should run outside it.

Workaround

Starting the command through the user systemd manager, which doesn't have the flag, works and prompts for the password normally:

1systemd-run --user --pty sudo <command>

Expected

The integrated terminal behaves like a normal terminal: sudo prompts for the password. Agent sandboxes can keep no_new_privs, but it shouldn't leak into the app's own process and from there into user terminals.

Environment

  • T3 Code desktop 0.1.4 (t3code-bin 0.1.4-1, AUR), server 0.1.4
  • Arch Linux (Omarchy), kernel 7.2.5, Hyprland 0.56.2, launched via uwsm (systemd-run --user --scope)
  • Reproduced from the desktop terminal and from the Android app's terminal
TTonybynMp46d ago
Synced from GitHub

Another symptom: snap-packaged CLIs can't run either, so T3 reports a snap-installed glab as not installed. snap-confine gets its permissions from file capabilities, and the kernel ignores those under no_new_privs:

1snap-confine is packaged without necessary permissions and cannot continue
2required permitted capability cap_dac_override not found in current capabilities

#15387 fixes the relaunch path. Until it lands, fully quitting and reopening T3 Code clears the flag.

Rraulferrodrigues17h ago
Synced from GitHub

Still reproduces on 0.1.9-nightly.20261109.4443 (.deb, Electron 44.10.1), and it also affects agent shells, not just the integrated terminal.

After an in-app update, the relaunched instance has NoNewPrivs: 1 on the Electron main process, so the server, provider processes and every agent Bash shell inherit it. The instance I'd opened from the app menu earlier in the same boot had NoNewPrivs: 0, and agent sudo worked there.

This breaks the sudo flow T3 recommends to agents (request_secret with delivery: "file", then sudo -S -p '' <cmd> < "$file"). It fails with The "no new privileges" flag is set, so agents can't do any admin work in an updater-relaunched instance.

Agent shells have no TTY, so the --pty workaround above doesn't apply. This works:

1systemd-run --user --quiet --wait --pipe --same-dir sudo -S -p '' <cmd> < "$file"

Until #15387 lands, the agent instructions could check NoNewPrivs in /proc/self/status and suggest this form, or say that quitting and reopening T3 Code clears it.

Per Fable 5.2 high