still-running

KO | EN

gitlite — search

#python #react #ai #llm #golang #android #nodejs #java #windows #cli #vue #awesome-list #security #ios

(★ 9)

Finds the containers, simulators and dev servers you forgot were running, and stops them. A macOS menu bar app.

still-running Latest Version Download

Download Latest Version (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

<h1 align="center">Still Running</h1>

The containers, simulators, and stray processes you forgot are still running. 
 A small macOS menu bar app that finds them and stops them in one click.

Lives in the menu bar. No Dock icon, no window, no account.

The icon stays monochrome, the way menu bar icons do. It carries the
 size of the waste rather than only its count: a quiet ring when nothing is
 left over, a dotted ring once something is, a flame once it is eating a core
 — and the number beside it becomes a percentage when that is the more useful
 figure.

## Why

A laptop got hot. The cause turned out to be a headless Chrome, started by a
tool, running for eighteen hours on a throwaway profile, burning most of a core
the whole time. Nothing in Activity Monitor said *you forgot about this one* —
it just showed a browser near the top of a list, next to the browser actually
in use.

Activity Monitor answers **what is using CPU right now**. Still Running answers
**which of these did I forget about, and is it safe to stop**.

## What it finds

| | Signal |
| --- | --- |
| **Automation browsers** | `--user-data-dir` outside the normal profile, `--headless`, or a remote-debugging port |
| **Containers** | Docker, OrbStack, Colima, Podman or Rancher, aged by when the current run started |
| **Simulators** | Booted iOS simulators, and Android emulators named after the device |
| **Dev servers** | node, bun, deno, vite, next, webpack, metro, astro, uvicorn, gradle daemons, watchman |
| **Tunnels** | cloudflared, ngrok and friends, with what they're publishing |
| **Orphans** | Reparented to launchd with no controlling terminal — and not a service launchd manages on purpose |
| **Whatever is keeping the Mac awake** | Power assertions that never expire, held by something of yours: a `caffeinate` nobody released, a tab still playing audio |

### Every row explains itself

Click a row and it opens. A profile path is an identifier, not an explanation,
so it says what the thing actually is, shows the command that started it, and
links to where it lives. Where the path or the command names a tool it knows —
Claude Code, Playwright, Puppeteer, Selenium, Cypress, ChromeDriver — it says
which one started the browser, and stays quiet rather than guessing when it
cannot tell.

Something appears only once it also crosses a threshold: older than two hours,
or orphaned, or above 25% CPU sustained for three minutes, or idle for half an
hour while holding more than 500 MB. All of them are adjustable.

Rates come from a rolling five-minute history rather than a single reading, so
a brief spike never puts anything on the list. The header reports how hard
macOS says the machine is being pushed — the reading it acts on when it spins
the fans — and says nothing at all while the machine is comfortable.

A dev server is usually several processes — `npm run dev` launches a framework,
which launches a bundler — so it is reported and stopped as the tree it is,
named after the project it belongs to. One that has done any real work in the
last ten minutes is left alone: that is a server you are using, not one you
forgot.

A tunnel is listed on age alone. Everything else here wastes a core; a tunnel
you forgot is still publishing a port on your machine to the internet.

**What it deliberately won't offer to stop:** editors and IDEs, and desktop
virtual machines. Both can hold work that has not been written to disk, and an
app whose promise is *this is safe to stop* has no business guessing about
that. They show up under Busy, but yours, with no button.

## What it will never do

- **Never deletes anything.** It stops things.
- **Never touches your browser's own tabs.** Only isolated and automation
  profiles are ever offered. A browser on its normal profile is refused at two
  separate layers, and there is a test that proves it on a live machine.
- **Never force quits on its own.** The first click sends SIGTERM. Force quit
  is a separate, explicitly labelled action that appears only if the first one
  was ignored.
- **Never asks for privileges.** No root, no Accessibility, no Full Disk
  Access. It reads the process table, which any process may do.
- **Never sends anything about you.** The one request it makes is to GitHub's
  public releases API, once a day, asking for a version number. Switch off
  **Check for updates** and it never touches the network at all.

Processes it cannot vouch for appear under **Busy, but yours** — visible, but
with no button next to them.

## Getting it wrong

Every stop has a way back, and each kind gets the most honest one available.

A **container or simulator** stops right away and then offers to start it again
for two minutes. That is a real undo: `docker start` and `simctl boot` bring
back exactly what was there.

A **process** cannot be undone. Re-running an argument vector is not the same
program in the same state, and a signal cannot be recalled. So the way back
comes first instead: the click starts a three second countdown that can be
cancelled before anything is sent.

**Stop all** asks before it acts, and lists what will go.

Anything you always keep running can be dismissed for good from the row's
**⋯** menu. It goes on running; it just stops being mentioned.

## Settings

How long something must run before it counts as forgotten, and when to be
reminded. Reminders are one quiet notification when something has been running
far past your threshold, at most once per thing. The test button asks macOS for
permission and reports back exactly what it allows, including whether sound is
switched off for the app — which macOS keeps as a separate switch.

**Start at login** is on, because an app that notices things you left running
for hours is worthless if a restart is the end of it. It is one login item and
the switch turns it off.

**Check for updates** asks GitHub once a day whether a newer release exists.

If one is, the panel says so, and **Update** opens a Terminal window running the
same `git pull` and `./scripts/install.sh` from the Install section — where you
can watch the build and see it fail. Nothing is installed silently, and if the
checkout it was built from has moved, it opens the release page instead of
running an installer from a path that may no longer hold one.

## Install

You build it. Either way below does, on your own machine.

There is no notarised download, because notarising needs a paid Apple developer
account and this is a free thing I wrote for myself. Building it yourself is
better anyway: Gatekeeper never gets an opinion, and you can read every line
that ends up running on your machine.

### With Homebrew

```bash
brew tap selinihtyr/still-running https://github.com/selinihtyr/still-running
brew trust --tap selinihtyr/still-running
brew install still-running
still-running
```

The URL is in there because Homebrew's short form goes looking for a repository
called `homebrew-still-running`, and this formula lives in the app's own
repository instead. You type it once.

`brew trust` is there because Homebrew will not load a formula from a tap that
is not its own until you say so, and it is right not to: a formula is code, and
installing this one runs a compiler over this repository on your machine. If you
would rather read it first, it is [one file](Formula/still-running.rb).

The third line is not ceremony. macOS only lets an app register as a login item
from `/Applications` or `~/Applications`, and a Homebrew formula is sandboxed
out of both — writing there from `post_install` fails with `EPERM`, by design.
So Homebrew installs the command, and the command puts the app where macOS
needs it. Run it again whenever you like; it only replaces the bundle when
Homebrew has a newer one, and it quits the running copy before it does.

| | |
| --- | --- |
| `still-running` | Put the app in place and open it |
| `still-running --where` | Print where the app is |
| `still-running --uninstall` | Remove the app bundle |
| `brew upgrade still-running` | Build the new version, then run `still-running` |

### From the repository

```bash
git clone https://github.com/selinihtyr/still-running
cd still-running && ./scripts/install.sh
```

That builds the app, puts it in `/Applications`, and starts it.

### Either way

Look for the ring in your menu bar — there is no Dock icon and no window.

Requires macOS 14 or newer and a Swift 6 toolchain. The Command Line Tools are
enough to build it; Xcode is only needed to run the tests.

It is developed and used daily on macOS 26. It builds and its tests pass for
macOS 14, but nobody has run it there yet — if something looks wrong on an
older version, [open an issue](../../issues), that is genuinely useful.

To update, `brew upgrade still-running`, or `git pull && ./scripts/install.sh`.
To uninstall, quit it from the panel and delete `/Applications/Still Running.app`
— or `still-running --uninstall`, which does the same thing.

## Working on it

```bash
swift test           # 207 tests, no network, nothing touched
./scripts/bundle.sh  # produces build/Still Running.app without installing it
```

`swift test` needs Xcode rather than only the Command Line Tools: the tests are
written against swift-testing, which ships with Xcode, and without it the build
stops at `no such module 'Testing'`. Building the app itself does not need it.

There is a second suite that drives the real machine — it starts a container
and boots a simulator, stops each through the same code the panel uses, and
puts them back. It is off unless asked for, so a plain `swift test` and CI
leave the system alone:

```bash
STILL_RUNNING_LIVE_TESTS=1 swift test
```

## How it works

`ProcessKit` samples the process table through `sysctl` and `libproc` into a
serialisable `Snapshot`. `DockerClient` adds containers by speaking HTTP over
the Docker unix socket. `SimulatorSource` adds simulators through `simctl`.
`Detectors` turns a snapshot plus rolling history into findings, and `Actions`
stops them behind a safety guard that no other code path can bypass.

Because a snapshot is just data, every rule is tested against recorded fixtures
of real machine states — including the one where the user's own Chrome must not
be flagged while an automation Chrome beside it must be.

**Not everything it finds is something it offers to stop.** A process holding
this Mac awake gets a row with a button when it is a command line tool, because
a `caffeinate` nobody released is exactly a thing to end. An app gets its name
printed and nothing else: quitting a browser because it is playing audio would
be a worse bug than the one the row exists to fix. Anything launchd manages is
named too, and never offered, because launchd starts it again. macOS holding
its own assertions — `sharingd` for Handoff, `powerd` whenever the display is
on — is left out entirely, and so is anything created with a timeout, since a
`caffeinate -t 300` releases itself and was nobody's mistake.

**A percentage is per second of running time.** This laptop had been up for
eleven hours and awake for under seven of them, and nothing burns CPU with the
lid shut. Dividing by the nap turns something pinning three cores into three
percent, and counting the nap as quiet time makes every large process look
abandoned by morning — so rates and the windows they are measured over run on
uptime, which excludes sleep, while an age runs on the wall clock, because you
did start it five hours ago. A rate is also never read from a gap too short to
mean anything: opening the panel takes a sample immediately, and the fraction
of a second since the last one describes an instant rather than a process. On
this machine a busy loop read 98% from a 0.6 second gap and 10% measured
properly, which for a browser's helpers counted together is the difference
between a calm row and a three-figure one.

**It stays out of the way.** A sample costs about 115 ms and runs every five
seconds while the panel is open, once a minute while it is closed. Getting
there took work: reading every process's arguments meant a megabyte-sized
buffer per process, which cost 614 ms per sweep. Arguments cannot change while
a process lives, so they are cached against its start time; container start
times are inspected once; and `simctl`, the most expensive call of all, is only
spawned when a booted device's `launchd_sim` is actually there.

## License

MIT.

## Changelog

[CHANGELOG.md](CHANGELOG.md) — what changed in each version, in the words of
someone using it.

still-running

still-running Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

still-running

still-running Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

Download README