DevSpace: a self-hosted MCP server that lets ChatGPT edit your local code

What problem DevSpace actually solves

Coding agents are most useful when they can see the real repository: the file that imports the function, the failing test, the lockfile that pins an old dependency. Hosted chat products do not have that. You either paste files into the chat window or upload a copy of the project, and both approaches drift from the working tree the moment you edit anything locally.

DevSpace takes the other route. It is a self-hosted MCP server that runs on your machine and exposes selected local folders to a connected client. The README describes it as giving ChatGPT "a secure connection to your own machine", and the mental model it asks you to hold is explicit: remote access to selected local folders, not a sandbox. 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.

The intended user is someone who already has a ChatGPT or Claude subscription, works on a machine with Node, Git and a Bash-compatible shell, and would rather keep source code local than hand it to a hosted agent. It is not aimed at teams wanting a shared remote development environment, and the name invites confusion with Kubernetes tools of the same name, which the FAQ below addresses.

How the MCP endpoint and workspace model fit together

The architecture is a single local HTTP server with a tunnel in front of it. The default local endpoint is http://127.0.0.1:7676/mcp, and the README tells most users to connect through a public HTTPS tunnel instead. The server binds to HOST=127.0.0.1 and PORT=7676 by default in .env.example, so the public surface is whatever your tunnel exposes.

Protocol handling is deliberately invisible. The README says the same /mcp endpoint serves the 2026-07-28 per-request protocol and automatically supports older 2025-era clients through stateless compatibility handling, and that there is no protocol mode to configure. That is a good decision: protocol negotiation is exactly the kind of setting users get wrong.

Inside a session, the client opens an approved project folder as a workspace. From there it can read, write and edit files, search code, inspect directories, run shell commands for tests, builds, git and package scripts, and use isolated Git worktrees for parallel sessions. It also reads project instructions from AGENTS.md and CLAUDE.md, and discovers local agent skills from configured skill folders. The repository layout matches this: src/, schema/, skills/, examples/agents/ and a test/ directory sit alongside a pnpm workspace, and the package exposes two binaries, devspace and devspace-agentd.

Authorization is an Owner password approval page shown when the client connects. The password is printed by devspace init and stored in ~/.devspace/auth.json. There is an OAuth layer behind it, with tunables such as DEVSPACE_OAUTH_ACCESS_TOKEN_TTL_SECONDS and DEVSPACE_OAUTH_ALLOWED_REDIRECT_HOSTS listed in .env.example, and DEVSPACE_OAUTH_OWNER_TOKEN for non-interactive deployments. The README does not document a rollback or revocation flow for a compromised token beyond changing that value, which is worth knowing before you expose the endpoint.

Installing DevSpace and connecting ChatGPT

Node is the first constraint. The README states DevSpace requires Node >=22.19 <27, and package.json repeats that range under engines. Install the CLI globally:

npm install -g @waishnav/devspace

If you would rather not install globally, the README gives a one-shot alternative:

npx @waishnav/devspace init

Either way you then run devspace init, which asks where you will use DevSpace (ChatGPT, Coding Agents, or both) and which agents it may use as subagents. If you pick 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. The README is specific about the format here: use the public origin without /mcp during setup, for example https://your-tunnel-host.example.com. You add /mcp later, in the MCP client configuration.

Before connecting anything, check the environment:

devspace doctor

The README presents this as the way to inspect your local setup, and the platform table explains why it matters: Linux and macOS are supported with Node, npm, Git and Bash; Windows is supported through Git Bash, WSL, MSYS2 or Cygwin Bash; PowerShell or cmd.exe alone is listed as not supported yet.

With the tunnel running, start the server and connect the client:

devspace serve

The README's five-step flow is: start your tunnel, run devspace serve, connect the MCP client to your public /mcp URL, approve the connection with the Owner password, then ask ChatGPT to open a project inside one of your allowed roots. Expect an approval page in the browser at that point; the password is the one printed by devspace init and stored in ~/.devspace/auth.json.

Configuration keys you will actually touch

The .env.example file is the clearest picture of the operational surface. DEVSPACE_ALLOWED_ROOTS takes a comma-separated list of folders, and it is the single most important setting: it is the boundary between your machine and the connected client. DEVSPACE_PUBLIC_BASE_URL is described as deriving the inbound Host allowlist from the URL, and the example comments suggest setting it per run for temporary tunnels. There is also an escape hatch, DEVSPACE_ALLOWED_HOSTS, where the example warns that * disables Host header allowlist protection.

Tool exposure and UI are separate knobs. DEVSPACE_TOOL_MODE accepts full in the example, and DEVSPACE_WIDGETS accepts off, changes or full, defaulting to changes, which the comment says creates one aggregate review widget via review_changes instead of per-tool iframes. Logging is granular enough to be useful: DEVSPACE_LOG_LEVEL, DEVSPACE_LOG_FORMAT, DEVSPACE_LOG_REQUESTS, DEVSPACE_LOG_ASSETS, DEVSPACE_LOG_TOOL_CALLS and DEVSPACE_LOG_SHELL_COMMANDS. Note that shell command logging is off in the example while tool call logging is on, which is a sensible default for privacy but means you will not see command text in logs unless you turn it on.

Skills are enabled by default, with DEVSPACE_SKILLS=0 to hide them, and DEVSPACE_SKILL_PATHS takes a list such as /home/waishnav/.codex/skills,/home/waishnav/.claude/skills. Native file download is opt-in through DEVSPACE_ARTIFACTS=1, with DEVSPACE_ARTIFACT_MAX_FILE_BYTES=104857600 as the cap, and the comment states files stream to a model-selected relative path inside an already-open workspace without overwriting existing files. State and worktrees can be relocated with DEVSPACE_STATE_DIR and DEVSPACE_WORKTREE_ROOT.

Where DevSpace is the wrong tool

The biggest limitation is the trust model, and the README does not hide it. Shell execution inside an opened workspace means the approval step is the only gate; once a client is connected and a workspace is open, the boundary is the allowed root, not the tool. If you allow a folder containing credentials, cloud config or SSH keys, nothing described in the README stops the agent from reading them. DevSpace is not a sandbox, and treating it as one because it is described as "secure" would be a misreading.

Windows is a second concrete limit. The platform table lists PowerShell or cmd.exe only as not supported yet, so a Windows machine without Git Bash or WSL cannot run it. That rules out a lot of corporate laptops where installing WSL is a managed decision.

Version status matters too. package.json reports version 1.0.8 while the recent releases are v1.1.0-beta.1, v1.1.0-beta.2 and v1.1.0-beta.3, published between 2026-09-07 and 2026-09-11. The 1.1 line is beta software, and the README does not describe a rollback path if a beta breaks your setup. The last push to the repository was on 2026-09-14, so development is current, but current development and production stability are different claims.

Finally, the name collision is a practical problem. Searching for "devspace" surfaces Kubernetes development tools, not this project, and the README gives no homepage, so the repository is the canonical entry point.

DevSpace compared with container-based dev environments

The natural alternative is a containerized development environment, the kind built around a devcontainer.json and a remote container runtime. The difference in approach is fundamental. A devcontainer moves your toolchain into a container and points an editor at it, so the environment is reproducible and disposable. DevSpace does the opposite: it leaves your toolchain exactly where it is and gives a remote model access to it through an MCP endpoint.

That trade-off cuts both ways. DevSpace needs no Dockerfile, no image rebuild and no container runtime, and it works on the project you already have checked out. What it cannot give you is isolation. A devcontainer limits what a process can see by construction; DevSpace limits it by configuration, specifically DEVSPACE_ALLOWED_ROOTS, and by the Owner password approval. If your reason for wanting a remote agent is that you do not trust the agent with your host, a container-based setup addresses that concern and DevSpace does not.

If your reason is that you want the agent to see the real repository without uploading it, DevSpace addresses that directly and a container adds a layer of setup you may not need. The two are not mutually exclusive either, since a devcontainer is just a folder, and nothing in the README prevents you from allowing the workspace root of one.

Licence, upgrades and what maintenance costs you

DevSpace is MIT licensed, stated in package.json and linked from the README badge. MIT is permissive: you can use it commercially, modify it and redistribute it, provided the copyright notice and permission notice are preserved. That is a description of the licence text, not legal advice for your situation, and the repository's LICENSE file is the authority.

The upgrade story is ordinary npm. Because the package is published as @waishnav/devspace with a bin entry for devspace, upgrading means installing a newer version and re-running devspace init if the setup questions change. The repository uses pnpm internally with [email protected] declared in packageManager, but that only matters if you build from source; consumers installing from npm do not need pnpm.

Two maintenance costs are worth budgeting for. The Node range >=22.19 <27 is enforced, so a Node major upgrade outside that window will require a DevSpace release before you can move. And because the 1.1 line is in beta, pinning to a known-good version is the safer default for anything you rely on daily. The README does not document a migration guide between minor versions, so check the release notes before moving.

Editorial conclusion

Adopt DevSpace if you already pay for ChatGPT or Claude and want an agent to work inside repositories on your own machine without uploading them to a third party, and you are comfortable running a tunnel and approving each connection with the Owner password in ~/.devspace/auth.json. Do not adopt it if you need PowerShell-only Windows support, a stable non-beta release, or a server that is safe to expose without thinking about which roots you allow. Before trusting it, run devspace doctor, set DEVSPACE_ALLOWED_ROOTS to the narrowest set of folders you can live with, and read the Configuration Reference to confirm what DEVSPACE_TOOL_MODE and DEVSPACE_WIDGETS change.

Frequently asked questions

Official sources

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