DevSpace: a self-hosted MCP server that gives ChatGPT a shell in your repo

What DevSpace actually solves for ChatGPT users

The gap DevSpace targets is narrow and practical. ChatGPT can write code in a chat window, but it cannot open the repository sitting on your laptop, run the test suite, or look at the diff it just produced. DevSpace is a self-hosted MCP server that closes that loop: the README describes it as giving ChatGPT "a secure connection to your own machine" so it can read, edit, search, and run code in your real local projects without uploading anything to a third party.

The intended user is a solo developer or a small team that already pays for a ChatGPT plan and wants a Codex-style workflow inside it. The README frames the pitch as "Turn ChatGPT into Codex." The same server also serves coding agents, and setup asks whether you will use it from ChatGPT, from coding agents, or both. That second path is what the devspace claude and devspace claude code searches are about: the MCP endpoint is client-agnostic, so Claude Code and other MCP-speaking tools can connect to the same local workspace.

It is not a hosted service. You run the process, you run the tunnel, and you hold the password. That is the entire value proposition, and also the entire risk.

The mechanism: an MCP endpoint, a tunnel, and an Owner password

Architecturally DevSpace is a Node process that speaks MCP over HTTP. The default local endpoint is http://127.0.0.1:7676/mcp, and the README says the same /mcp endpoint serves the 2026-07-28 per-request protocol while also supporting older 2025-era clients through stateless compatibility handling. There is no protocol mode to configure, which removes a class of setup mistakes.

The data flow is: your MCP client connects over a public HTTPS tunnel, DevSpace checks the inbound Host header against an allowlist derived from DEVSPACE_PUBLIC_BASE_URL, and then opens an approval page. You type the Owner password that devspace init printed. Only after that does the client get to open one of your approved roots as a workspace.

Inside an opened workspace the surface is broad. According to the README, the client can read, write and edit files, search code, inspect directories, run shell commands for tests, builds, git and package scripts, use isolated Git worktrees for parallel sessions, follow AGENTS.md and CLAUDE.md project instructions, and discover local agent skills. Tool cards and optional change summaries render in ChatGPT Apps-compatible hosts.

The honest mental model is in the README itself: "DevSpace is remote access to selected local folders." The allowlist is the boundary. Everything inside an opened workspace, including shell execution, is available to the client.

Installing DevSpace and running a first session

DevSpace requires Node >=22.19 <27, and package.json pins the same range in engines. Install the CLI globally, or skip the global install with npx.

npm install -g @waishnav/devspace

Then run the interactive setup. It asks where you will use DevSpace (ChatGPT, Coding Agents, or both) and which agents it may use as subagents.

devspace init

The equivalent without a global install is:

npx @waishnav/devspace init

If you select ChatGPT, setup also asks which local project folders it may open and for your public HTTPS base URL from Cloudflare Tunnel, ngrok, Pinggy, Tailscale Funnel, or another reverse proxy. Enter the origin without /mcp, for example https://your-tunnel-host.example.com. A Coding Agents-only setup asks neither question.

Start the server when using ChatGPT:

devspace serve

The server listens on 127.0.0.1:7676 by default. Point your MCP client at the public /mcp URL, approve the connection with the Owner password printed by devspace init, and ask the client to open a project inside one of your allowed roots.

If you prefer environment configuration over the wizard, .env.example shows the keys. This is a minimal set:

HOST=127.0.0.1
PORT=7676
DEVSPACE_ALLOWED_ROOTS=/home/waishnav/personal,/home/waishnav/work
DEVSPACE_TOOL_MODE=full
DEVSPACE_WIDGETS=changes

Two defaults are worth noticing. DEVSPACE_TOOL_MODE defaults to changes, not full, and DEVSPACE_WIDGETS defaults to changes, which the example file says creates one aggregate review widget via review_changes instead of per-tool iframes. Before connecting anything, run devspace doctor to inspect your local setup.

Where DevSpace is the wrong tool

The clearest limitation is platform. The support table lists Linux, macOS, and Windows with Git Bash, WSL, MSYS2, or Cygwin Bash as supported. Windows PowerShell or cmd.exe only is marked "Not supported yet," with the note to install Git Bash or use WSL. If your team standardizes on PowerShell, this is not the harness for you today.

The second limitation is the trust model. The README states plainly that the MCP client has powerful local capabilities inside an opened workspace, including shell execution, and that you should treat a connected client like a trusted coding partner with access to your machine. That is not a bug, but it means DevSpace is the wrong choice if you want a sandbox. The allowlist restricts which roots can be opened; it does not restrict what runs inside them.

The third is operational. Because the public URL is the entry point, you need a tunnel and you need to keep the Owner password private. The README notes that it is stored in ~/.devspace/auth.json. There is also a DEVSPACE_ALLOWED_HOSTS escape hatch where the value * disables Host header allowlist protection. The example file calls it an advanced escape hatch for a reason; leaving it wide open trades away the check that ties inbound requests to your expected hostname.

Finally, the README does not document rollback or an undo path for edits made through the workspace. Git worktrees help with parallel sessions, and the changes widget summarizes diffs, but the source is silent on reverting a bad edit beyond whatever your own version control provides.

DevSpace versus Kubernetes dev-loop tools like Tilt and Skaffold

Searches for devspace vs tilt, devspace vs skaffold, and devspace kubernetes point at a different project with the same name: a Kubernetes development tool for building and deploying into a cluster. Waishnav/devspace is not that. It has no Kubernetes manifests, no cluster sync, and no deployment pipeline in the repository as published. Its unit of work is a local folder opened over MCP, not a pod.

If you arrived looking for in-cluster inner-loop tooling, this repository will not help. The real alternative in that space is Tilt or Skaffold, which watch your source and rebuild images into a cluster. DevSpace here does the opposite: it keeps the work on your machine and lets a chat client reach in.

Within its own category, the closest comparison is a plain MCP filesystem server. Those typically expose read and write over a directory tree. DevSpace goes further by adding shell execution, Git worktrees for parallel sessions, AGENTS.md and CLAUDE.md instruction loading, skill discovery, and an approval flow with an Owner password. The trade is that you are running a process with shell access behind a tunnel, which a read-only filesystem server does not require. Choose based on whether the client needs to run your tests. If it only needs to read files, the smaller server is the safer one.

Maintenance, upgrade cost, and the MIT licence

The repository is not archived, and the last push was on 2026-09-14. Recent releases are all pre-release: v1.1.0-beta.1 on 2026-09-07, v1.1.0-beta.2 on 2026-09-10, and v1.1.0-beta.3 on 2026-09-11. Three betas in five days is a fast-moving line, and it is worth noting that the published package.json still reads version 1.0.8, so the stable npm line and the beta line are not the same thing. If you need a fixed target, pin to the stable version rather than tracking the beta tags.

Upgrade cost is mostly configuration drift. The .env.example exposes a wide surface: OAuth token TTLs and scopes, allowed redirect hosts, allowed roots, tool mode, widget mode, log level and format, request and tool-call logging, trust-proxy, state directory, worktree root, artifact download limits, and agent and skill paths. Any of these can change between minor versions, and the README points to a separate Configuration Reference rather than inlining the full list. Read it before bumping.

The licence is MIT, which permits commercial use, modification, and redistribution with the copyright notice preserved. That is permissive, but it says nothing about your obligations to OpenAI or any other model provider. The README includes a note that using DevSpace as an MCP connector is a standard custom App or connector setup and that your account is governed by your usage, not by DevSpace. That is a product statement, not legal advice; if you are deploying this inside a company, the terms you agreed to with your model provider are the ones that matter.

Editorial conclusion

Adopt DevSpace if you already run a tunnel and want ChatGPT or a coding agent to work inside folders you have explicitly listed in DEVSPACE_ALLOWED_ROOTS, and if you are comfortable treating that client as a trusted partner with shell access. Do not adopt it on a Windows machine that only has PowerShell or cmd.exe, since those shells are listed as not supported yet, and do not point it at a host where you would not hand over a terminal. Before connecting anything, run devspace doctor, confirm Node is >=22.19 <27, and decide whether DEVSPACE_TOOL_MODE=full is really what you want, because the default is changes.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. Waishnav/devspace on GitHub