witr Answers Why Is This Running, and Coding Agents Just Made That Question Expensive

A single Go binary traces any process, port, container, or file back to whatever started it. It charted on a trending board dominated by agent harnesses, and the reason is not that it uses AI. It's that AI broke the assumption the old tools were built on.

A tool with no model in it, no MCP server, and no agent anywhere in its design charted on a GitHub trending board otherwise filled with agent harnesses this week. It is called witr, it is written in Go, it is Apache-2.0, and it exists to answer exactly one question.

Why is this running?

The README puts the case against the existing tools plainly. ps, top, lsof, ss, systemctl, and docker ps all expose state. They tell you what is running and leave you to work out why by correlating four outputs in your head at 2 a.m. witr makes the causality explicit, which sounds modest until you look at what it prints.

Target      : node

Process     : node (pid 14233)
User        : pm2
Command     : node index.js
Started     : 2 days ago (Mon 2025-02-02 11:42:10 +05:30)

Why It Exists :
  systemd (pid 1) → pm2 (pid 5034) → node (pid 14233)

Source      : pm2

Working Dir : /opt/apps/expense-manager
Git Repo    : expense-manager (main)
Sockets     : 127.0.0.1:5001 (TCP | LISTENING)

That is one screen. No flags, no pipes, no second tool. (Type bare witr with no arguments and you get something else entirely: an interactive TUI dashboard with tabs for processes, ports, containers, and file locks. Worth knowing before you type it the first time and wonder where your output went.)

Why a sysadmin utility is trending on an AI board

Every mainstream coding agent now runs shell commands. It starts dev servers. It spins up containers to test something. It backgrounds a build. It restarts a service it decided was stale. Then the session ends, the transcript scrolls away, and something is still holding port 5432.

Before agents, you mostly knew what you started, because you typed it. Provenance lived in your short-term memory and that was good enough. The old tools were designed for a world where the human at the keyboard was the cause of nearly everything on the machine, and the tools only had to report state because the human already had the story.

That assumption is gone. Provenance is now the scarce thing on a developer machine, and no popular tool was built to hand it to you.

witr is not an AI tool. It went trending because AI created the gap it fills.

The design decision worth copying

The process tree is not the interesting part. Plenty of things print a tree.

The interesting part is that witr commits to an answer.

Look at the output above. There is a field called Source, and the README is explicit that only one primary source is selected. Not a ranked list of maybes. One. It can be a systemd unit with schedule info, a launchd service, an SSH session with the remote IP and terminal, a docker container, pm2, cron, an interactive shell with the tmux or screen session name attached, or a Snap or Flatpak sandbox. Best effort, one answer.

Pair that with the stated output principles: single screen by default, deterministic ordering, narrative-style explanation, and best-effort detection with explicit uncertainty. Then read the success criteria the author wrote for the project: a user can answer the question within seconds, it reduces reliance on multiple tools, output is understandable under stress, and users trust it during incidents.

"Understandable under stress" is the design constraint most diagnostic tooling ignores, and most agent tooling ignores harder. When something is on fire, a tool that returns seven plausible explanations ranked by confidence has handed the ranking problem back to the person who is already overloaded. witr picks one and tells you it is best effort. That is a harder engineering choice and a better one, and it is the thing I would steal for any explanation surface I build, agent-facing or not.

The warnings are shaped the same way. Non-blocking observations, printed only when they apply: running as root, dangerous Linux capabilities on a non-root process, listening on a public interface, restarted more times than a threshold, over 1 GB RSS, running for more than 90 days, deleted binary, and library injection indicators like LD_PRELOAD or DYLD_*. Read that list again with an agent in mind. Three of those are exactly what you would want flagged after an autonomous session touched your machine.

Put this into practice

Install it from whatever you already use. It is packaged unusually widely: Homebrew, apt on Ubuntu 26.04+ and Debian sid, MacPorts, conda-forge, AUR, winget, Chocolatey, Scoop, npm, FreeBSD ports, AOSC, Guix, aqua, uniget, brioche, Nix, and mise, plus prebuilt .deb, .rpm, and .apk packages.

brew install witr

Then run these four things, in this order.

One. Point it at the port you have been fighting with.

witr --port 5432

You will get the ancestry chain and the supervisor in one screen. --short collapses it to a single line if that is all you want.

Two. After your next agent session, ask what is left over.

witr node --tree

The tree view shows ancestry plus up to ten child processes and highlights the target. If your agent spawned a dev server that spawned three workers, this is where you see it.

Three. Sweep the containers.

witr --container redis --verbose

The container lookup searches Docker, Podman, nerdctl, K8s via crictl, Incus, LXC, LXD, and FreeBSD jails, matching on name, image, command, and compose project or service labels. Verbose adds mounts, networks, and compose metadata.

Four. Wire it into a script, because this is where it earns its keep long term. witr returns meaningful exit codes: 0 clean, 1 warnings present, 2 not found, 3 permission denied, 4 invalid or ambiguous input, 5 internal error.

witr nginx --warnings
[ $? -eq 1 ] && echo "check the warnings"

Add --json and you can snapshot process state before and after an agent session and diff the two. That is a five-line shell function, and it gives you something most agent harnesses still do not offer: a record of what the session left behind.

Where it breaks, specifically

The single biggest limitation is the one relevant to why it is trending. witr will not tell you an agent started something. The ancestry chain stops at whatever process actually did the forking. If your coding agent runs commands through a shell, what you see is bash, or in the README's own example, a chain like systemd → SessionLeader → Relay → bash → sh → node. Nowhere in that chain does the word "agent" appear. You still have to know that this particular terminal was the one your agent was driving. The provenance is real, and it stops one layer short of the layer you now care about most.

The platform matrix is genuinely uneven, and the README is honest about it. File locks: not on Windows. Capability warnings: Linux only. Schedule detection: Linux and macOS only. tmux and screen detection: not on Windows. Environment variables: partial on macOS because of System Integrity Protection, partial on Windows because protected processes are inaccessible. Open file handles on Windows are a count only. Process actions like kill and renice are Unix only.

Full detail wants elevated privileges. sudo witr on Linux, macOS, and FreeBSD, Administrator PowerShell on Windows, and even with sudo, SIP will hide some macOS system process details. That is an awkward ask for a binary a lot of people will install with a piped curl, and it is worth installing through a package manager instead for that reason alone.

Container lookups need the runtime CLI on PATH. No docker, podman, nerdctl, crictl, incus, lxc, lxc-ls, or jls binary means no container answer.

And the popularity signal deserves the same skepticism I would give any trending repo, more than usual in this case. GitHub served 18.1k stars, 561 forks, and 549 commits with 2 open issues on one load, while a separate check the same day returned 15.7k stars, 447 forks, and 4 open issues, and the trending board that surfaced it reported a third figure again. Those numbers cannot all be right. Treat every one of them as attention velocity, not as a measurement, and note that the board scores engagement momentum rather than verified star totals. Packaging breadth across seventeen ecosystems is the more meaningful maturity signal here, and community packages lag GitHub releases by design.

The question underneath

Agent harnesses have spent this year getting better at doing things on your machine and have spent almost no effort on telling you what they did. Sandboxes bound the damage. Permission prompts bound the moment. Neither leaves you an answer to "what is this, and which of my sessions is responsible for it."

witr does not solve that. It gets you most of the way and then hands you a shell process where you wanted an agent name. But it draws the shape of the missing thing clearly enough that somebody should build the rest, and the design principle it demonstrates, commit to one answer and label your uncertainty rather than dumping every correlated fact you found, is the part that transfers to whatever you are building.

Install it. Run it against your machine right now, before you read anything else today. I expect you will find at least one thing you did not know was running.

Sources: pranshuparmar/witr on GitHub (README, feature compatibility matrix, output behavior, and success criteria sections); witr README on the main branch; repository figures as served on August 11, 2026.