DesktopCommanderMCP: your agent's bash forgets. This one keeps the session open.

Here is a problem nobody writes about. An agent opens a psql shell, runs a query, looks at fourteen rows of results, decides it wants a follow-up query against the same connection. Tool call number two starts. The shell from call number one is gone. The connection is gone. The transaction the agent was in the middle of is gone. The agent reconnects, types its password again, and tries to remember what it was doing.

This is not a Claude Code bug. It is how every agent on the market runs bash. Each tool call spawns a fresh subprocess and tears it down when the call returns. Persistent state across calls is the exception, not the rule.

DesktopCommanderMCP, maintained by @wonderwhy-er, has 6,002 stars on GitHub. It is a kitchen-sink MCP server with twenty-something tools. Most of them duplicate things Claude Code already has. One of them does not, and that one changes the shape of what an agent can do.

What dies between tool calls

If you have not built an agent, this part is easy to miss. When Claude Code, Cursor, Codex, or any other agent runs a bash command, it does roughly this: spawn a child process, hand it your command, capture the output, kill the child. The next call gets a brand new child process with no memory of the last one. Anything that lived in the old process is gone.

The casualties:

• Open database connections (psql, mysql, mongosh, redis-cli)
• SSH sessions to a remote server, including the cost of re-authenticating
• Interactive REPL state (python -i, node, irb, ghci)
• Debuggers mid-session (gdb, lldb, Chrome DevTools attached to a paused breakpoint)
• Any process that prompts for input (a migration tool asking “are you sure?”, a CLI installer, an SSH key passphrase prompt)
• Shell environment variables, working directory, aliases
• Long-running background services started in the call (a dev server, a tail of a log file)

For a vibe coder reading this, here is the analogy. Imagine your terminal restarted every time you pressed Enter. You’d learn to write commands that do everything in one line. You’d give up on anything interactive. That is where most agents live.

The problem in code

A typical agent attempting an interactive psql workflow looks like this:

The agent never gets back to BEGIN. Whatever it was about to do inside that transaction has to be recreated from scratch in a new connection. If the agent was iterating on a complex query against a temp table, the temp table is gone too.

What DesktopCommander does differently

DesktopCommander exposes two tools that, taken together, fix the model: start_process opens an interactive process and returns a session ID; interact_with_process writes input to that process and reads output back. The process keeps running between calls. A third tool, list_sessions, shows what is open. A fourth, force_terminate, kills a runaway.

The agent opens psql once. It runs queries against the same connection. It rolls back the transaction when it is done. The connection is one logical thing the agent is using, not fifteen short-lived reconnections.

What this unlocks that you could not do before

The list of new workflows is longer than it sounds:

• Database iteration. Open psql. Inspect a schema. Run a query. See the result. Run a refined query against the same temp tables. Roll back. The connection budget is one. Time saved compounds across long sessions.
• Remote debugging over SSH. Connect to a staging box. Tail a log. While that runs, open another session, restart a service, and watch the log respond. Most agents cannot do this because the tail dies the moment the call returns.
• REPL-driven exploration. Load a 4 GB dataframe in a Python REPL once. Ask a hundred questions against it without reloading. The first call pays the cost, the next ninety-nine are cheap.
• Driving interactive CLIs. Anything that expects a prompt and an answer. aws configure, gh auth login, npm init, password prompts on a one-off SSH key generation. Subprocess-per-call agents fight these. Persistent sessions just answer the questions.
• Long-running test runners. Start vitest --watch. Edit a file. Read the output of the rerun without restarting the runner.

The honest part

DesktopCommander is a kitchen-sink server. It has tools for terminal commands, file editing, code search, Excel and PDF handling, an in-memory Python and Node interpreter, audit logging, telemetry. If you are on Claude Code, most of those duplicate the built-ins. The bash, edit, and search tools are already in your client. Installing all of DesktopCommander to get a second copy of those tools is a bad trade.

What you actually want, as a Claude Code user, is the persistent process model. The Excel and PDF readers and the in-memory REPL are nice extras for some workflows. The session tools are the whole reason this server has six thousand stars. The maintainer’s pitch frames it as “use host client subscriptions instead of API token costs,” which is fair if you live in Claude Desktop. For a Claude Code user, the more accurate pitch is: this is the MCP that gives your agent a memory longer than one tool call.

Where it is not the right tool

• Pure read-only file work. Claude Code’s native tools are faster and lower-latency than going through any MCP for this.
• Hard sandboxing requirements. DesktopCommander runs against your real filesystem and shell. If you need an isolated environment, run Claude Code in a sandbox or container, not this MCP layered on top of an unconstrained host.
• One-shot scripts. If your workflow is “run this single command and exit,” the persistent-session model is overkill.

Install

Pick your tool. The install command is the same npx entry point everywhere.

Open a psql session and leave it open. Watch the agent stop losing its place.