desktop-commander-overview — Claude Code skill: computer access
Tells the agent what the Desktop Commander MCP can do: persistent sessions, long-running processes, files outside the workspace, Excel and PDF, SSH.
npx skills add cline/skills --skill desktop-commander-overview -a claude-codeWhat desktop-commander-overview does
The skill does no work by itself. It maps what the Desktop Commander MCP exposes and how the tools compose into workflows; the detailed schemas for parameters and return shapes stay inside the MCP.
Covered here: persistent shell and REPL sessions that carry environment variables, working directory and an activated venv across many turns. Long-running processes get a handle you can tail, interact with or terminate. Then filesystem reach past the IDE workspace, surgical edit_block replacements with an expected_replacements count, first-class .xlsx, .docx and .pdf handling, ripgrep-backed search over folder trees, and a long-lived SSH session to a remote box.
One thing to watch: separate start_process calls open separate sessions and do not share shell state, so persistence lives inside a single session only. Before deploys, restarts or migrations the skill advises summarizing the action and confirming with the user. A wrong old_string or a wrong replacement count can still corrupt a file, so read the changed content before calling the edit done.
What it helps with
- keep a dev server up while the agent edits routes
- update cells in an
.xlsxwithout rebuilding the file - find every call site of a function across a monorepo
- SSH into production and stream the app log
- work through files in
Downloadsoutside the workspace
Example prompts for the agent
- Start
npm run devin the background and tail its output while I edit the route - Open
q3.xlsx, sheet Revenue, and update range C12:C24 - SSH into the prod host and show me the last 50 lines of the log
How to install desktop-commander-overview
1Skills CLI (Vercel)
npx skills add cline/skills --skill desktop-commander-overview -a claude-code2Manually: put the files in place
~/.claude/skills/desktop-commander-overview/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/desktop-commander-overview/
1Skills CLI (Vercel)
npx skills add cline/skills --skill desktop-commander-overview -a codex2Manually: put the files in place
.agents/skills/desktop-commander-overview/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add cline/skills --skill desktop-commander-overview -a cursor2Manually: put the files in place
.cursor/skills/desktop-commander-overview/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install cline/skills desktop-commander-overview2Manually: put the files in place
.github/skills/desktop-commander-overview/SKILL.md1Skills CLI (Vercel)
npx skills add cline/skills --skill desktop-commander-overview -a gemini-cli2Platform CLI
gemini skills install https://github.com/cline/skills --path skills/desktop-commander-overviewManually: put the files in place
.devin/skills/desktop-commander-overview/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add cline/skills --skill desktop-commander-overview -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
Step by step, with commands for each platform: How to install skills in Claude Code: five ways
Questions about desktop-commander-overview
How do I install desktop-commander-overview in Claude?
Run npx skills add cline/skills --skill desktop-commander-overview -a claude-code. The skill file lands at ~/.claude/skills/desktop-commander-overview/SKILL.md.
What does desktop-commander-overview do?
It documents what the Desktop Commander MCP enables: persistent shells and REPLs, background processes, filesystem access beyond the workspace, Excel, DOCX and PDF edits, ripgrep search, and SSH.
Does shell state carry over between start_process calls?
No. Each start_process call opens its own session, so environment variables and working directory do not move between them — state persists only within one session.
Source text
SKILL.md · Apache-2.0
---
name: desktop-commander-overview
description: Use for Desktop Commander MCP capabilities — persistent shells and REPLs, long-running processes, filesystem beyond the workspace, structured files (.xlsx, .docx, .pdf, images) and large local data files such as CSVs, ripgrep search at scale, SSH, or cross-turn state.
version: 0.1.0
audience: agent
---
# Desktop Commander MCP
Desktop Commander gives the agent reach across the user's actual computer — files, folders, terminals, processes, structured documents, and remote machines reachable over SSH. The tools' detailed schemas (parameters, return shapes, format-specific behavior) live in the MCP itself; this skill explains what they enable and how they compose into common workflows.
## What this MCP gives the agent
**Persistent shell sessions.** Desktop Commander keeps a started process or session alive across tool calls. Inside a single long-lived shell, REPL, or SSH session, state carries forward — environment variables, working directory, activated virtualenvs, open connections, REPL variables — so the agent can `cd`, activate a venv, then send commands or code into that same session many turns later without re-setup. (Note: separate `start_process` calls open separate sessions and do **not** share shell state with each other; persistence is inside one session, not across them.)
**Long-running processes.** Start a dev server, watcher, build, training run, or test suite in the background and keep working. The MCP returns a process handle the agent can tail, interact with, or terminate across many turns. Long-running commands don't need to block the workflow waiting for a foreground command to exit.
**Filesystem reach beyond the IDE workspace.** Read, write, move, list, and inspect files anywhere the user has granted scope — Downloads, Documents, project folders outside the IDE, or any other granted folders. Useful for organize-and-clean tasks, batch document work, and any "look at the file my coworker just sent me" request that doesn't fit inside the IDE sandbox.
**Surgical edits to existing files.** The `edit_block` tool does exact-string find-and-replace with built-in safety: ambiguous matches fail loudly instead of silently overwriting the wrong thing, and an `expected_replacements` count prevents partial-match disasters. Lower data-loss risk than rewriting whole files based on the slice you happened to read — though a wrong `old_string` or wrong `expected_replacements` can still corrupt content, so review the changed content before considering the edit done.
**Binary and structured files handled directly by the MCP.** Excel, DOCX, and PDF are first-class — read and modified through format-specific mechanisms rather than text-only approximations: Excel via cell-range JSON, DOCX via raw-XML edits, PDF via page-level operations on a new output file. The result is the real file in its original format, not a regenerated approximation. Images and PDFs return as viewable content for the agent.
**Search at scale.** Streaming, ripgrep-backed search across whole projects or folder trees. The agent picks between filename search and in-file content search, pages through results progressively without flooding context, and runs multiple concurrent searches when the query is ambiguous.
**Remote machines via SSH.** A long-lived SSH session inside a persistent shell turns the agent into a real ops tool: connect once, then tail logs, run diagnostics, deploy, or debug across many turns without reconnecting each step.
**Process management.** List, inspect, tail, and kill accessible processes (subject to OS permissions). Useful for cleaning up stale dev servers from previous sessions and for diagnosing CPU / memory issues.
## Example workflows
Each example names the actual tool sequence. Calls below are written in pseudocode shorthand (`tool_name("arg", flag=value)`); the real tools take object-shaped arguments. Tool descriptions and full parameter sets live in the MCP itself.
### "Debug this production issue"
Before running production-impacting SSH commands, explain the intended action and get user confirmation when the risk is non-trivial.
`start_process("ssh [email protected]", timeout_ms=...)` opens a long-lived SSH session and returns a PID. `interact_with_process(pid, "tail -f /var/log/app.log\n")` starts streaming logs. Subsequent turns: `read_process_output(pid, offset=-50)` to see the last 50 lines as they arrive, `interact_with_process(pid, "...")` to run diagnostic commands in the same session. `force_terminate(pid)` to close the session when done — for sessions opened by `start_process`, `force_terminate` is the correct cleanup tool; `kill_process` is for arbitrary OS PIDs found via `list_processes`.
### "Deploy this to staging"
Before deploys, restarts, migrations, or other environment-changing commands, summarize the action and confirm with the user unless they already explicitly asked for that exact operation.
`start_process` for the deploy command (could be a script, an SSH-piped command, or `kubectl`/`gh` etc.). `read_process_output` to track output and surface errors. If the deploy needs an interactive confirmation, `interact_with_process(pid, "yes\n")`. The session stays alive while the agent watches for completion or rollback.
### "Run the dev server and iterate on the API"
`start_process("npm run dev", timeout_ms=...)` keeps the server up. The agent then loops: `edit_block` on the route file, `read_process_output(pid, offset=-30)` to see the server's reload, `start_process("curl -s http://localhost:3000/api/...")` for a one-shot test, repeat. The dev server never has to restart between code changes.
### "Refactor across this monorepo"
`start_search(pattern="oldFunctionName", path=repo_root, searchType="content")` scopes every call site. `get_more_search_results(sessionId)` pages through. `read_multiple_files(paths=[...])` confirms ambiguous hits in context. `edit_block(file_path, old_string, new_string)` per site, with `expected_replacements` set when the same substring legitimately appears multiple times in one file. Verify by re-running `start_search` on the old name and paging the results with `get_more_search_results(sessionId)` until the run completes — only then can you confirm zero remaining hits.
### "Update the Q3 numbers in this spreadsheet and tweak the summary in the report"
`read_file(path="/.../q3.xlsx", sheet="Revenue", range="A1:F50")` returns the existing numbers as a JSON 2D array. `edit_block(file_path="/.../q3.xlsx", range="Revenue!C12:C24", content=[[12345], ...])` updates the cells in place. For the report, DOCX editing is a two-read flow: first `read_file(path="/.../report.docx")` (offset 0) returns the document's outline (headings + paragraph text) so you can locate the summary section. Then `read_file(path="/.../report.docx", offset=N, length=...)` with **`N > 0`** returns the raw underlying XML around that section — a non-zero offset is what flips the read into XML mode. Copy an XML fragment from that output as `old_string` and call `edit_block(file_path, old_string, new_string)` with the rewritten XML. The user gets back real `.xlsx` and `.docx` files, not regenerated approximations.
### "Generate the Q3 report as a PDF"
Compose markdown content (header, table, charts via embedded HTML), then call `write_pdf` to render it to a new PDF file. The MCP's `write_pdf` tool description specifies the exact parameters and filename rules — follow that.
### "Insert a cover page into this PDF"
`write_pdf` also supports modifying existing PDFs via an operations array (insert / delete pages). Use it for existing-PDF edits that produce a new PDF — adding a cover page, removing a section, merging in content from another file. See the `write_pdf` tool description for the operation shapes and parameter rules.
### "Analyze this 200MB CSV"
`start_process("python3 -i", timeout_ms=...)` opens a Python REPL and returns a PID. `interact_with_process(pid, "import pandas as pd; df = pd.read_csv('/abs/path.csv')")` loads it once. Every subsequent question — `df.describe()`, `df.groupby('col').size()`, plot a chart — runs in the same already-loaded REPL. Libraries don't re-import, the dataframe doesn't re-load. The MCP itself recommends this workflow for any local data-file analysis.
### "Run a quick Node script"
`start_process("node:local", timeout_ms=...)` opens a stateless Node execution mode on the MCP server itself — ES imports supported. `start_process` opens the runner; each piece of JS is sent via `interact_with_process(pid, "<your JS here>")` and runs independently (no shared state between calls). Good for one-shot transformations where keeping a long-lived REPL alive isn't worth it. Don't try to put code into the `start_process` command argument — only the runner type (`node:local`) goes there.
### "Explain this codebase"
`list_directory(path=repo_root, depth=3)` for shape. `start_search(pattern="export ", path=repo_root, searchType="content")` to find the public surface. `read_multiple_files(paths=[entrypoints])` for the actual code. The agent can keep narrowing without re-asking the user where to look.
### "Organize my Downloads folder"
Resolve the path to absolute first (e.g., `/Users/<user>/Downloads`, not `~/Downloads`). Then `list_directory(path="/Users/<user>/Downloads", depth=1)` to see what's there. `start_search(pattern="*.pdf", path="/Users/<user>/Downloads", searchType="files")` and similar for other types. `create_directory` for new folders. `move_file` per item. Preview the move plan before executing destructive ops.
### "Onboard me — what was happening last session?"
`get_recent_tool_calls(maxResults=200)` returns recent activity with arguments and outputs. `list_sessions` shows still-running terminal sessions. `list_searches` shows in-flight searches. `list_processes` shows what's still alive. Together they reconstruct the work without asking the user to recap.
### "Why isn't the REPL responding?"
`list_sessions` — if `Blocked: true`, the REPL is waiting for input rather than hung. `read_process_output(pid, offset=-100)` to see what it last printed (often a prompt). `interact_with_process(pid, "<the input it's waiting for>\n")` unblocks it.
## Core tool inventory
Grouped index of the tools an agent reaches for most often. Not exhaustive — the MCP exposes additional config / diagnostics / feedback tools beyond this list. Detailed parameters and return shapes for every tool are in the MCP's own tool descriptions.
- **Process / shell:** `start_process`, `interact_with_process`, `read_process_output`, `list_processes`, `list_sessions`, `kill_process`, `force_terminate`
- **Files (read/write):** `read_file`, `read_multiple_files`, `write_file`, `edit_block`, `write_pdf`
- **Filesystem:** `list_directory`, `get_file_info`, `move_file`, `create_directory`
- **Search:** `start_search`, `get_more_search_results`, `list_searches`, `stop_search`
- **Diagnostics / config:** `get_recent_tool_calls`, `get_config`
## Conventions
**Prefer absolute paths.** Relative paths may fail depending on the working directory, and tilde paths (`~/...`) may not expand in all contexts. Absolute paths are the most reliable; pass them whenever you can.
**Allowed-directory scope.** File operations only work inside the user's configured `allowedDirectories`. Expect `[DENIED]` markers in `list_directory` output and rejections from `read_file` / `write_file` when the path is out of scope. Surface the rejected path to the user — don't retry.
**When running on macOS:** default shell is zsh. Use `python3` not `python`. Some GNU tools have prefixed names (`gsed` for GNU sed). `brew` is the typical package manager. `open` opens files / apps from the terminal, `mdfind` is the fastest path to exact-filename search via Spotlight. Detect the host platform via `get_config` (or by inspecting `process.platform` / `uname` from a shell) before assuming any of the above — Windows and Linux hosts behave differently.
**Pagination.** Long outputs (file reads, process output, search results) all support `offset` and `length`. Negative offsets read from the end (tail mode). Use these instead of dumping huge results into context.
© cline · Apache-2.0 · cline/skills