Launching today

What's Running MCP

Launching today

Stop AI agents from reporting dead services as live

1 follower

Stop AI agents from reporting dead services as live

1 follower

Every agent session starts blind. It reads a stale doc or an old transcript, decides your dev server is running, and health-checks a process that died three weeks ago. Model memory is a cache with no invalidation. Five read-only tools answer from the OS instead: live agent sessions (pid, uptime, cwd), every TCP LISTEN socket with its owning process, loaded daemons, and system load/disk. No shell, no writes, no network. MIT and free. macOS first; Linux best-effort.

Launch tags:Open Source•Developer Tools•Artificial Intelligence

Launch Team / Built With

Wispr Flow: Dictation That Works EverywhereStop typing. Start speaking. 4x faster.

Promoted

Maker

📌

Hey Product Hunt 👋 I run several coding-agent sessions at once, and the same failure kept happening: a session would tell me a service was live because a doc or an old transcript said so. I'd go check and the process had been dead for weeks. Model memory is a cache with no invalidation — the OS is the only thing that actually knows. So I wrote a shell script that just asks the machine. It got used at the start of every session, so I wrapped it in MCP. Five tools: • whats_running — the whole snapshot in one call, meant for session start • agent_sessions — which agent processes are actually alive, terminal-attached vs detached/orphan, with pid, uptime and working directory • listening_ports — every TCP LISTEN socket and the process that owns it • daemons — launchctl on macOS, systemd --user on Linux • system_stats — load average, uptime, root-disk free Constraints I held myself to: • Read-only by construction. Every call is a fixed binary with fixed flags via execFile — no shell, and nothing the model produces is ever executed. The only model-controlled inputs are a boolean and a substring filter applied in-process. • Never blocking. 10s timeouts; a failing probe degrades to an empty result instead of erroring the snapshot. • It does disclose your machine — process names, pids, working directories, ports. That's the entire point, and also why you shouldn't attach it to a client you don't trust. It says so in the README. MIT and free. No account, no telemetry, no paid tier. macOS is my daily driver so it's strongest there; Linux is best-effort and would really benefit from someone running it in anger. It's a brand-new repo with zero stars, so what I'm actually after is criticism: what's missing, what would you want a sixth tool to answer, and does the read-only argument hold up when you look at the source? github.com/stcmain/whats-running-mcp

Report

3d ago

Forum Threads

p/what-s-running-mcp

•

3d ago

How do you stop an agent from trusting its own stale context?

Something I keep hitting and have not properly solved, so I would rather hear how other people handle it than pretend I have the answer.

I run several coding-agent sessions at the same time. A session will state confidently that a dev server is up, or that a background job is running, because somewhere in its context there is a doc or an older transcript that said so. The process died weeks ago. Nothing in the loop ever contradicts it, so the claim propagates: into the next answer, into a handoff file, occasionally into a commit message.

The shape of it is that model memory behaves like a cache with no invalidation. It is not hallucination exactly. The information was true when it was written. There is just no TTL on it.

What I have tried:

p/what-s-running-mcp

•

3d ago

If you run more than one coding agent at once, what breaks first?

Genuine question, not a survey for anything.

I have been running multiple coding-agent sessions on one machine for a few months. The failure modes turned out to be less dramatic than I expected and more annoying:

Orphaned sessions. A terminal window gets closed, the process does not, and it sits there holding a working directory. I usually find out from load average rather than from noticing.

Two sessions on the same repo. Not the loud git conflict, the quiet one where both are confident the branch is clean.

View all