irskep/persistproc

A shared process layer for multi-agent development workflows
---
> Full docs: steveasleep.com/persistproc.
What is persistproc?
Persistproc is an MCP server and command line tool which lets agents and humans see and control long-running processes like web servers. The goal is to reduce the amount of copying and pasting you need to do while coding with AI, make it easier for you to use multiple agents, and be tool-agnostic.
There is no config file. Processes are managed entirely at runtime. This is not a replacement for supervisord.
Example use case: basic web development
Suppose you're working on a todo list app, and it has a dev server you normally start with npm run dev. This server watches your code for changes, typechecks it, lints it, and hot-reloads the page. When there's an error, it prints the error to your terminal.
If you're working with an LLM agent such as Cursor or Claude Code, if you see an error, you might copy/paste it from your terminal to the agent and ask how to fix it. Then the agent might make some changes, and maybe you hit another error, so you copy/paste again, and the agent makes another change…etc.
If the agent could see the changes directly, you wouldn't need to do anything! With persistproc, that's possible. Instead of saying npm run dev, say persistproc npm run dev, and the agent can instantly read its output or even restart it. Otherwise, you can still see its output in your original terminal, and kill it with Ctrl+C, like your normally do.
> [!NOTE]
> **Why not just use Cursor and let the agent open a terminal?**
>
> 1. Not everyone likes using the terminal in Cursor/VSCode. Engineers have many different workflows.
> 2. _Only_ Cursor's agents can see the process, not Claude Code, Gemini CLI, etc.
Example use case: complex web development
Suppose you need to run four processes to get your web app working locally. Maybe an API, frontend server, SCSS builder, and Postgres. Each service emits its own logs.
If you run into an error while testing locally, you can go read all four log files to find out what happened.
But if you started those processes with persistproc, then the agent can read everything at once and possibly give you a quicker diagnosis.
> [!NOTE]
> **What if my processes are started by another system?**
>
> Then your best bet is to write log files to a predictable location and tell the agent where they are,
> rather than trying to use persistproc. Or, you can follow this issue on GitHub.
>
> Currently, persistproc is most useful when you want your agent to be able to _manage_ processes, not
> just see their output.
Available Tools
persistproc exposes a standard Model Context Protocol (MCP) server on http://127.0.0.1:8947. You can use any MCP-compatible client to interact with it programmatically.
The server exposes the following tools:
| Tool | Description |
| --- | --- |
| ctrl | Unified process control: start, stop, or restart processes. |
| list | List all managed processes and their status. Can optionally filter by pid, command, or working directory and provides log paths. |