Giving Claude Code Hands on My Dev Environment

devenvMCPAIDeveloper ExperienceProcess Management

I debug with Claude Code as a partner. It reads logs, forms a hypothesis, suggests a fix. But for a long time there was an awkward seam in that loop: I was the one running the commands. Claude would say "check the worker's stderr," I'd paste the output back, Claude would read it. A human relay between an AI and a process manager that both, in principle, speak structured data.

devenv 2.x closes that seam. It ships a built-in Model Context Protocol server — devenv mcp — and wiring it into Claude Code turns the assistant from an advisor into something that can actually reach into the running environment.

What MCP Is, Briefly

The Model Context Protocol is an open standard for letting an AI assistant call tools and read resources from an external program. The transport is JSON-RPC, usually over stdio: the client (Claude Code) launches the server as a child process and talks to it over stdin/stdout. No network, no daemon, no ports.

Why would a dev-environment tool ship one? Because the Nix ecosystem is enormous and language models hallucinate option names with great confidence (services.postgresql vs services.postgres, every time). An MCP server backed by your actual project gives the assistant ground truth instead of guesses: the real options, your concrete config, live package search — and, it turns out, live control over your processes.

Wiring It Up

One command registers it:

claude mcp add --scope project devenv -- devenv mcp

Two details worth savoring. The -- is the POSIX "end of options" marker: everything after it is the server's launch command (devenv mcp), untouched by claude mcp add's own parser. And --scope project writes a .mcp.json into the repo rather than your personal config:

{
  "mcpServers": {
    "devenv": {
      "type": "stdio",
      "command": "devenv",
      "args": ["mcp"],
      "env": {}
    }
  }
}

Commit that file and every teammate — and every Claude Code session opened in the directory — gets the server offered automatically. The environment's introspection tooling becomes part of the repo, versioned alongside the code it describes.

The Eight Tools, in Two Classes

Once connected, the server exposes eight tools that split cleanly into two jobs:

Knowledge — answering questions about the environment:

  • search_options — search the real configuration options (give it a concrete term like listen_addresses, not a word salad)
  • search_packages — live nixpkgs search; I asked for pgcli and got version 4.4.0 back, ready to drop into packages

Operations — acting on the running environment:

  • list_processes, get_process_status, get_process_logs
  • start_process, stop_process, restart_process

That second class is the interesting one. The assistant can now do the thing I used to relay by hand: "the worker is in gave_up, here's its stderr, restarting it." No copy-paste, no human in the middle of the feedback loop.

Three Doors, One House

The thing that made this click for me: the MCP tools are not a separate system. list_processes is devenv processes list. restart_process is devenv processes restart. The TUI's Ctrl-R is the same action again. All three — TUI, CLI, MCP — are doors into the same process manager, talking over the same .devenv/run/processes/native.sock.

That framing is also how you reason about failures. When the socket dies — say, after quitting the TUI without stopping the processes — all three doors lose access at once, even though the processes themselves keep running as orphans. The MCP server isn't magic; it's one more client of a manager that can itself go missing.

An Honest Limit

Tools are only as good as the data behind them. During one session get_process_status cheerfully reported a worker as gave_up while the process was, in fact, alive and well — the manager's bookkeeping had gone stale after a manual restart. The assistant believed the tool; the tool was wrong.

So the same rule that governs human debugging governs the AI kind: the dashboard is a claim, not a proof. An MCP server that can pull logs and restart processes is a genuine multiplier on a debugging loop — it removes the slowest link, the human relay. But it doesn't remove the need to verify. It just makes verification fast enough that there's no excuse to skip it.

Next: a bug where every tool in the box — including these — pointed the wrong way, and catching it meant comparing what two of them said.

References

← All Articles