DevSpace
A self-hosted MCP server that gives ChatGPT a secure, password-approved connection to code on your own machine.
- Source repo
- Waishnav/devspace
- Stars
- ★ 5.3k
- Last updated
- 9d ago
- License
- MIT
- Primary language
- TypeScript
- FA score
- 50/100 · Major gaps
At a glance
- How it runs
- Works with
- Portable with changesChatGPTClaude Code · Claude.ai · OpenAI API (Partial support)
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A solo developer who wants ChatGPT to edit their real repository and run its tests instead of pasting files into a chat.
- Not a fit if
- Teams on Windows PowerShell or cmd.exe only who won't install Git Bash or WSL
- Users who don't want to run and manage a public tunnel plus password approval
- Teams that won't let a cloud model run shell commands in local projects
- Source review
- 50/100 · Major gaps
What does this agent do, and when should you use it?
DevSpace is a self-hosted MCP server shipped as the npm CLI @waishnav/devspace that lets ChatGPT, Claude, or another MCP client work directly against real project folders on your machine. You run devspace init and devspace serve locally, expose the /mcp endpoint through a tunnel you control (Cloudflare Tunnel, ngrok, Pinggy, Tailscale Funnel, or any reverse proxy), and approve each connection with an Owner password only you hold. Once connected, the client opens an allowed root as a workspace, then reads, writes and edits files, searches code, runs shell commands for tests, builds, git and package scripts, and uses isolated Git worktrees for parallel sessions. A single /mcp endpoint serves the 2026-07-28 per-request protocol and transparently supports older 2025-era clients, so there is no protocol mode to pick. It is MIT-licensed and needs Node >=22.19 <27, npm, Git and a Bash-compatible shell; Windows requires Git Bash, WSL, MSYS2 or Cygwin Bash.
You install the CLI (npm install -g @waishnav/devspace) and run devspace init, which asks where you will use it (ChatGPT, Coding Agents, or both), which local agents may be used as subagents, and — for ChatGPT setups — which project folders may be opened plus your public HTTPS base URL from a tunnel. devspace serve starts the local MCP endpoint, by default http://127.0.0.1:7676/mcp. On connection, DevSpace opens an Owner password approval page; the password is printed by init and stored in ~/.devspace/auth.json. The connected client can then open a project inside an allowed root as a workspace and call tools to read, write and edit files, search code and inspect directories, run shell commands (tests, builds, git, package scripts), use isolated Git worktrees for parallel sessions, follow AGENTS.md and CLAUDE.md project instructions, discover local agent skills from skill folders, and render tool cards with optional change summaries in ChatGPT Apps-compatible hosts. devspace doctor inspects the local environment.
- A solo developer who wants ChatGPT to edit their real repository and run its tests instead of pasting files into a chat.
- A team that already has Claude or another MCP client and wants one self-hosted endpoint exposing the projects on a shared dev machine.
- Trying several implementation approaches in parallel on the same repo by giving each session its own isolated Git worktree.
- A maintainer of a repo with AGENTS.md or CLAUDE.md conventions who wants connected agents to follow those project instructions automatically.
- A laptop or remote developer who temporarily exposes a local dev environment to a ChatGPT session through their own tunnel and shuts it down afterwards.
How do you install or deploy this agent?
Confirm Node is >=22.19 and <27, and that npm, Git and a Bash-compatible shell are available (Git Bash or WSL on Windows). Then install the CLI globally and initialize:
devspace initOr run it without a global install:
npx @waishnav/devspace initSetup asks where you will use DevSpace (ChatGPT, Coding Agents, or both) and which agents it may use as subagents; a ChatGPT setup also asks which project folders may be opened and for your public HTTPS base URL without /mcp, for example https://your-tunnel-host.example.com. Verify the local setup afterwards:
devspace doctorHow do you use this agent?
Start your tunnel (Cloudflare Tunnel, ngrok, Pinggy, Tailscale Funnel, or another reverse proxy), then start the server:
devspace servePoint your MCP client at the public endpoint, including /mcp:
https://your-tunnel-host.example.com/mcpFor a direct local connection use the default endpoint:
http://127.0.0.1:7676/mcpThe first client connection opens an Owner password approval page; enter the password printed by devspace init (also stored in ~/.devspace/auth.json), then ask the client to open a project inside one of your allowed roots. For a Coding Agents-only setup, init prints a skills command and the Skills CLI handles installation instead.
What are this agent's strengths and limitations?
- Self-hosted by design: code stays on your machine, reached only through your own tunnel and an Owner password approval step.
- One /mcp endpoint serves the 2026-07-28 per-request protocol and older 2025-era clients with automatic stateless compatibility, no mode switch.
- Tool surface covers a full coding loop: read/write/edit files, code search, shell execution, and isolated Git worktrees for parallel sessions.
- Honors in-repo AGENTS.md and CLAUDE.md instructions and discovers local agent skills, fitting existing repository conventions.
- MIT-licensed, with devspace doctor for environment checks and devspace serve as a single start command.
- You must provision and maintain a public HTTPS tunnel and the Owner password, so setup is multi-step rather than one-click.
- Windows environments limited to PowerShell or cmd.exe are not supported yet; Git Bash or WSL is required.
- Runtime window is narrow: Node >=22.19 <27 plus Git and a Bash-compatible shell.
- A connected client gets shell execution inside the opened workspace, so safety depends on the roots you allow and your trust decision.
- Subagent delegation and ChatGPT Apps tool cards depend on the specific host, so switching clients needs re-verification.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| DevSpace This agent | 50 · Major gaps | CLIFree + model costs | ★ 5.3k | 9d ago | TypeScript | ChatGPT |
| wcgw Local Coding Terminal | 45 · Major gaps | MCP serverFree + model costs | ★ 678 | 1mo ago | Python | Claude.ai |
| Aster | 77 · Good | CLIFree + model costs | ★ 131 | 3d ago | Rust | OpenAI API |
| Remembra Relay | 72 · Some gaps | Agent plugin / skillFreemium | ★ 16 | 10d ago | Python | Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
The security model documents a filesystem allowlist, Owner-password OAuth approval, Host header allowlisting, shell boundaries, and fail-closed artifact download handling, giving real support for least_privilege and user_confirmation (2). However the shell tool can run arbitrary local commands by design, worktrees are explicitly not a security boundary, and external_effects lack confirmation/recovery for destructive actions (1). The dependency surface is large with multiple native/third-party SDKs, only a few transitive deps pinned via overrides, and no vulnerability audit evidence, so dependency_security is 1. rollback only covers worktrees and config migration backup, not file edits or command side effects (1). source_attribution is only a self-described author with no verified publisher (1).
README, configuration, and security docs are broadly consistent on endpoint, port, config keys, and env migration (2). But dependencies use many floating ^ ranges and include native modules (better-sqlite3, koffi, node-pty), raising cross-platform availability risk, so dependency_availability is 1. failure_messages are only mentioned for config migration; overall error handling is not systematically described (1).
Targets ChatGPT/Claude MCP clients and coding agents with clear scenarios (2). capability_boundaries clearly list tool sets, codex/claude modes, and lack of PowerShell support (2). trigger_precision relies on natural language and MCP tool calls with no precise trigger rules (1). environment_fit provides a Linux/macOS/Windows support matrix and a doctor command (2).
Documentation is well-structured with setup/configuration/security/gotchas sections (2). Install steps are complete with Node version and pinned pnpm (2). naming_stability is weakened by the v1.0→v1.1 mass removal of env vars and config restructuring (1). examples_and_faq has config examples but no FAQ (1). known_limitations clearly lists platform limits and security boundaries (2). LICENSE is full MIT (3). versioning_changelog has a release workflow and migration notes but no standalone CHANGELOG (1). maintenance_responsibility is a single unverified individual maintainer (1).
output_usability offers tool cards, change summaries, and a clear workflow (2). marginal_value of connecting local coding to ChatGPT is real (2). cost_benefit requires self-hosted tunnel, password management, and trusting the client, a high operational cost (1).
claim_traceability: most security claims point to docs but lack code-level references (1). cross_source_corroboration: README and docs corroborate each other but no independent third-party verification (1). fact_inference_separation: docs distinguish design intent from limits, but some security claims (e.g. descriptor-relative operations) cannot be verified from the provided files (1).
- The shell tool can run arbitrary local commands by design; worktrees are not a security boundary, so treat any connected client as a trusted coding partner.
- The dependency surface is large with native modules and floating version ranges; cross-platform install and supply-chain risk require independent audit.
- Publisher identity is unverified; maintenance responsibility and update path rest on a single author.
- The v1.0→v1.1 release removed many env vars, requiring manual config migration on upgrade.
- Some security claims (e.g. descriptor-relative file operations) cannot be verified from the provided files and need code-level review.