zenity(1) for AI agents to ask for sudo

Updated
Created
Reading time
4 min read

Few words about the environment

I have a Thinkpad as my home lab central server that is running inside my local network. Apart from running other, non-graphical stuff there I usually keep an open RustDesk connection to do some maintenance or to modify my nixOS settings.

I like to have a peep what is being done in the background when watching a Netflix series or physically sit in front of it, click the best laptop keyboard (yes) and look at the horrible LCD screen running i3-wm. For the love of the game I guess.

In contrary to my main work machine, on Thinkpad - AI agents run there with full permissions granted. I treat that device as an ephemeral computing environment. There is no stuff that could be broken there nor remote accesses that would ever allow important stuff being modified by not-supervised agent.[1]

Notes & references

  1. More on that on upcoming post about my entire home lab setup

    ↩

The problem and inconvenience

Apart all of early "full access" claims, the agent will not execute sudo commands out of the box.. and during many agentic loop turns (especially when doing mentioned system maintenance) it becomes cumbersome to have

  1. Agent to stop the loop (that sometimes been running for ~1h).
  2. Agent to ask me to run certain stuff by hand, then to paste output to the chat.

For (obviously) I would never type and then save the password to any environment variable, command argument, file or chat. I doubt it could even be productively picked up by the agent's PTY.

The solution

zenity(1) - not only cool name of the utility. It is a stupidly simple and effective GTK-based GUI helper for shell scripts. It has been around with us for ~22 years [2]. We can make advantage of it by creating a sudo-runner wrapper script and AGENTS.md entry and guidelines.. or both!

nixOS wrapper command source

Nix (NixOS) 
sudoGuiAskpass = pkgs.writeShellScript "sudo-gui-askpass" ''
  exec ${pkgs.zenity}/bin/zenity --password \
    --title="''${SUDO_GUI_TITLE:-Sudo authentication}" \
    --text="''${SUDO_GUI_SUBTITLE:-Enter your sudo password}" \
    --width=360
'';

sudoGui = pkgs.writeShellApplication {
  name = "sudo-gui";
  text = ''
    if [ "$#" -eq 0 ]; then
      echo "Usage: sudo-gui COMMAND [ARG ...]" >&2
      exit 2
    fi
    if [ -z "''${DISPLAY:-}''${WAYLAND_DISPLAY:-}" ]; then
      echo "No graphical session; use sudo in a terminal instead." >&2
      exit 1
    fi
    export SUDO_ASKPASS=${sudoGuiAskpass}
    exec /run/wrappers/bin/sudo -A "$@"
  '';
};

Agent's instructions in markdown

You can put that anywhere in your project where you want to use zenity for the same purpose I do. In my case, it is living inside AGENTS.md directly in my nixOS configuration.

Markdown 
# Home Agent Notes

## Sudo from a non-terminal session

Use `sudo-gui COMMAND [ARG ...]` when a graphical session is available but the
agent's command runner has no terminal for `sudo` to prompt in. Set a short,
task-specific title and subtitle for each invocation, for example:

```bash
SUDO_GUI_TITLE="Rebuild NixOS" \
SUDO_GUI_SUBTITLE="Enter your sudo password to activate the new configuration" \
sudo-gui homelab-rebuild test
```

The subtitle becomes Zenity's dialog text. `sudo-gui` uses Zenity through
`sudo -A`; the password is not stored in a file, environment variable, or
command argument. The user enters it in the local dialog, never in chat. Do
not put secrets in the labels.

Use ordinary `sudo` in an interactive terminal. If the dialog is canceled or
there is no graphical session, stop and report that authentication was not
available. Never use this helper to skip approval for a destructive command.

## Other Zenity dialogs

Use `zenity` for graphical dialogs in this desktop session. Always set a
task-specific `--title`. For `--question`, `--info`, and `--progress`, also set
`--text` to explain the action. Zenity has no `--subtitle` option. For
`--text-info`, put the context in the title and piped content. Do not include
secrets in titles or dialog descriptions.

Quote arguments and handle the dialog's exit status: cancellation or closing
must not be treated as consent or a successful input. When piping text into
`--text-info` or updates into `--progress`, label the operation in the title
and text, and preserve the producer's failure status (for Bash, use
`set -o pipefail`). Never pipe a password to `sudo`; use `sudo-gui` for that.
If there is no graphical session, report that the dialog is unavailable.


This way stuff that needs explicit escalation can be prompted via zenity, along with the description and title to quickly have look of what is being done without crawling through the agent's transcript.

Notes & references

  1. If you want to dig a bit into the history - I believe zenity is a rewrite of GNOME 1's gdialog. The project may started earlier though according to the Debian's package description, the archive of releases date back to 2004.

    ↩

Terminal output shows sudo-gui running fsck.vfat on a USB drive, with arrows pointing to the timeout 120s command and the caption “zenity wrapper for running sudo.”
OpenAI's Codex calling the sudo-gui wrapper over zenity

How does it look in practice

A “Sudo authentication” dialog prompts for a password, with Cancel and OK buttons, over a terminal window.
zenity's sudo password prompt as a floating window over a tilling wm

Brain tagszenity · sudo · nixos · homelab · server