A better question than “what is running?”
Operating systems already provide excellent process tools. ps lists processes, lsof maps files and ports, systemctl explains services, and Docker or Kubernetes commands describe containers. The annoying part is joining those answers during a failure. A port is occupied by Node, Node belongs to PM2, PM2 was started by systemd, and the working directory points at an old checkout. Finding that chain usually requires several commands plus some inference.
witr packages that investigation into one query. Ask about a process name, PID, listening port, container, or open file. It resolves the target to a process, walks its ancestry, identifies the likely primary source, and adds context such as user, command, start time, working directory, Git branch, sockets, container, and service configuration. --tree shows ancestry and children, --short emits one line, and --json makes the result usable in scripts.
witr does not try to become another CPU graph or log platform. It answers the immediate port-conflict question: what created this process?
The command-line path is the product
The simplest use is also the strongest. witr --port 5432 can connect a listening socket to its PID and then to systemd, a shell, PM2, a container, or another supervisor. Name matching is fuzzy by default, while --exact removes ambiguity. Target flags are repeatable and can be mixed, so one invocation can inspect a service name, several ports, a PID, and a container.
Output behavior is designed for automation. Ordering is deterministic, JSON is available across target types, color can be disabled, and exit codes distinguish clean results, warnings, not found, permission denied, invalid input, and internal errors. This makes witr particularly suitable for coding agents. An agent with shell access can run one JSON command and summarize the causal chain instead of improvising a platform-specific series of ps, netstat, and container calls. An open documentation request proposes making that use more visible and explicitly says an MCP wrapper is unnecessary because the structured CLI already does the job.
The interactive terminal interface broadens the tool without replacing that core. It has process, port, container, and file-lock tabs, sortable live lists, detail panels, automatic refresh, and mouse support. Unix users can signal or renice processes from the interface. Container discovery covers Docker, Podman, nerdctl, Kubernetes through crictl, containerd, Incus, LXC, LXD, Colima, and FreeBSD jails when their command-line tools are available.
Cross-platform support has honest boundaries
Linux gets the deepest inspection because /proc exposes rich process information. macOS uses ps, lsof, sysctl, pgrep, and launchd. Windows talks directly to Win32 process and service APIs rather than depending on PowerShell or WMI. FreeBSD uses tools such as procstat, ps, and lsof. The README's feature matrix is unusually specific about what each path cannot do.
Windows lacks file-lock inspection, TUI process actions, tmux or screen detection, and service schedule detection. Open-file information is a count rather than the Unix-style detail. macOS environment access is partial because System Integrity Protection can hide system process data even under sudo. Windows protected processes have a similar limit, and examining other users or system services requires an Administrator terminal. Linux and FreeBSD may also need elevation for complete results.
This matters because witr uses best-effort attribution. Missing permission is not always a fatal error; it can mean a thinner explanation. The tool surfaces explicit uncertainty and has a permission-denied exit code, but operators still need to notice when evidence is incomplete.
Accuracy is good enough for debugging, not yet for proof
The two most important open bugs touch the central ancestry claim. One says a live process whose parent has exited can be labeled as shell-started even when that source is inaccurate. Another says the ancestry walk protects against loops but does not validate parent start times, so a parent PID recycled during the walk could connect the target to the wrong chain. Both reports concern version 0.3.3 and were receiving maintainer discussion in August.
These are timing and orphaning edge cases, not failures on every ordinary process. They still set the correct trust level. Use witr to reach an answer quickly, then confirm surprising claims with native system evidence before a security, compliance, or disciplinary decision. A causal explanation that looks polished can still be best effort.
witr is also strictly live. An open feature request asks for atop-style recording and replay because short-lived cron jobs or crashing services can disappear before an operator queries them. If the interesting process is gone, witr has no event database from which to reconstruct it. Pair it with journald, audit data, process accounting, or an observability agent when history matters.
Installation and project health are unusually strong
Distribution is a standout. Homebrew, Winget, Conda, npm, MacPorts, FreeBSD ports, community Linux packages, a direct install script, checksummed release downloads, and go install cover almost every reasonable preference. The binary needs no daemon and launches directly into a query or TUI. Community packages can lag the GitHub release, a caveat the README states clearly.
The repository was pushed on August 8, 2026. Release 0.3.3 dates to June 24, but issue discussion and code activity continued through August 8, so the older tag is not a sign of abandonment. GitHub showed seven combined issues and pull requests, while the separate issue search returned four open issues. Recent release work included macOS file-descriptor parsing, LXC detection, and terminal color improvements from new contributors.
Documentation is better than many much larger tools. The README covers installation, every output mode, examples, exit codes, warnings, permissions, containers, and a platform matrix. A browser simulation lets users try the interface without installing anything.
witr is an easy recommendation for developers and administrators who repeatedly ask why a local process exists. It is faster and clearer than manual correlation, and the JSON output gives it value beyond the attractive TUI. Keep native tools and historical telemetry nearby for the cases it cannot observe, and treat its ancestry as a well-researched explanation rather than immutable evidence.