MadCop — local-first AI agent desktop workstation (v0.9). Multi-model chat, tool-use, MCP servers, 12 workflow modes, knowledge base, AI design tool, persistent workspace.
MCPpedia last refreshed this data
Config is the same across clients — only the file and path differ.
{
"mcpServers": {
"madcop": {
"args": [
"-y",
"vite"
],
"command": "npx"
}
}
}Are you the author?
Add this badge to your README to show your security score and help users find safe servers.
MadCop is a cross-platform desktop application that brings the power of modern LLMs into a private, agentic workflow. It runs as a single Electron binary on macOS, Windows, and Linux, talks to any OpenAI-compatible API endpoint, and keeps your conversations, files, and knowledge base entirely on your machine. No cloud lock-in, no per-seat fees, no data leaving the device.
Run this in your terminal to verify the server starts. Then let us know if it worked — your result helps other developers.
npx -y 'vite' 2>&1 | head -1 && echo "✓ Server started successfully"
After testing, let us know if it worked:
Five weighted categories — click any category to see the underlying evidence.
launch-editor: NTLMv2 hash disclosure via UNC path handling on Windows
### Summary The `launch-editor` NPM package accesses arbitrary paths including Windows UNC paths. When a UNC path is opened, Windows automatically attempts NTLM authentication to the remote host, causing the user’s NTLMv2 password hash to be leaked to an attacker-controlled SMB server. This can result in credential compromise through offline hash cracking. ### Impact If the following conditions are met, an attacker can get the NTLMv2 password hash on the computer that is using the `launch-edit
vite: `server.fs.deny` bypass on Windows alternate paths
### Summary The contents of files that are specified by [`server.fs.deny`](https://vite.dev/config/server-options#server-fs-deny) can be returned to the browser on Windows. ### Impact Only apps that match the following conditions are affected: - explicitly exposes the Vite dev server to the network (using `--host` or [`server.host` config option](https://vitejs.dev/config/server-options.html#server-host)) - the sensitive file exists in the allowed directories specified by [`server.fs.allow`]
launch-editor vulnerable to command injection via the crafted request on Windows
### Summary Due to the insufficient sanitization of the `file` argument in the `launchEditor`, an attacker can execute arbitrary commands on Windows by supplying a filename that contains special characters. ### Impact If the following conditions are met, an attacker can execute arbitrary commands on the computer that is using the `launch-editor`: - An attacker can place a file with the malicious filename - An attacker can call the `launchEditor` method with the `file` argument controlled - The
Vite Vulnerable to Path Traversal in Optimized Deps `.map` Handling
### Summary Any files ending with `.map` even out side the project can be returned to the browser. ### Impact Only apps that match the following conditions are affected: - explicitly exposes the Vite dev server to the network (using `--host` or [`server.host` config option](https://vitejs.dev/config/server-options.html#server-host)) - have a sensitive content in files ending with `.map` and the path is predictable ### Details In Vite v7.3.1, the dev server’s handling of `.map` requests for
Vite: `server.fs.deny` bypassed with queries
### Summary The contents of files that are specified by [`server.fs.deny`](https://vite.dev/config/server-options#server-fs-deny) can be returned to the browser. ### Impact Only apps that match the following conditions are affected: - explicitly exposes the Vite dev server to the network (using `--host` or [`server.host` config option](https://vitejs.dev/config/server-options.html#server-host)) - the sensitive file exists in the allowed directories specified by [`server.fs.allow`](https://vi
Be the first to review
Have you used this server?
Share your experience — it helps other developers decide.
Sign in to write a review.
Others in developer-tools / ai-ml
XcodeBuildMCP provides tools for Xcode project management, simulator management, and app utilities.
Manage Supabase projects — databases, auth, storage, and edge functions
A Model Context Protocol (MCP) server and CLI that provides tools for agent use when working on iOS and macOS projects.
Context7 Platform -- Up-to-date code documentation for LLMs and AI code editors
MCP Security Weekly
Get CVE alerts and security updates for Madcop and similar servers.
Start a conversation
Ask a question, share a tip, or report an issue.
Sign in to join the discussion.
A local-first AI agent desktop workstation.
MadCop is a cross-platform desktop application that brings the power of modern LLMs into a private, agentic workflow. It runs as a single Electron binary on macOS, Windows, and Linux, talks to any OpenAI-compatible API endpoint, and keeps your conversations, files, and knowledge base entirely on your machine. No cloud lock-in, no per-seat fees, no data leaving the device.
This document explains the why behind the major design decisions — written for product managers and reviewers who want to understand how the system is put together, not just a list of features.
| Clarify & choose Interactive question chips · User avatar · Task monitor panel |
![]() |
| Structured report output Markdown tables · Key takeaways · Assistant avatar |
![]() |
| Plan-driven execution Step-by-step planning progress · Live task tracking |
![]() |
The dominant LLM desktop clients (ChatGPT, Claude.ai, Gemini) are excellent chat surfaces but they assume a specific shape of interaction: one human, one model, one conversation at a time, with vendor-managed tools and memory. That works for "answer this question" but it does not work for "I need to (a) search the web, (b) read a local file, (c) summarise the result, (d) save a Markdown report to disk" — which is a normal afternoon for a product manager, analyst, or engineer.
MadCop is built around three observations:
git history, screenshots, contracts — the substance of real work sits on the user's disk. A client that can only attach a single file per message (or pays per-token for cloud RAG) punishes the people who already have the answer.So the design goal is: a thin local shell that lets the user pick their own model, hand it their own files, and let the system orchestrate the rest. Everything else is in service of that.
┌─────────────────────────────────────────────────────────┐
│ Electron Shell │
│ ┌────────────────────┐ ┌────────────────────────┐ │
│ │ Vue 3 + Pinia + │ │ Python Backend │ │
│ │ Tailwind v4 UI │ │ (FastAPI + Uvicorn) │ │
│ │ (Renderer Process)│←→│ │ │
│ └────────────────────┘ │ ┌──────────────────┐ │ │
│ │ │ LLM Client │ │ │
│ ┌────────────────────┐ │ │ (OpenAI Compat) │ │ │
│ │ Workspace Picker │ │ └──────────────────┘ │ │
│ │ Sidebar / Tabs │ │ ┌──────────────────┐ │ │
│ │ Chat / Composer │ │ │ Tool Registry │ │ │
│ └────────────────────┘ │ │ + MCP Bridge │ │ │
│ │ └──────────────────┘ │ │
│ │ ┌──────────────────┐ │ │
│ │ │ Workflow Engine │ │ │
│
... [View full README on GitHub](https://github.com/linmy666/madcop#readme)