Skip to content

DevSpace 1.1

Choose a tag to compare

@github-actions github-actions released this 30 Oct 13:44
a2c0ada

DevSpace 1.1 turns DevSpace from a way to give ChatGPT and Claude access to your computer into a layer that also lets any of your coding agents hand work to the others. It's also much easier to install.

Install in one command

curl -fsSL https://devspace.run/install | sh                          # macOS, Linux, WSL
powershell -c "irm https://devspace.run/install.ps1 | iex"            # Windows

The installer uses a compatible Node on your PATH or downloads Node 24 LTS just for DevSpace, installs without sudo, puts devspace on your PATH, and starts setup. Rerun it any time to update. Nothing is compiled during install anymore: state now uses Node's built-in SQLite, and terminal sessions use prebuilt binaries on every platform. npm install -g @waishnav/devspace still works if you manage Node yourself.

Subagents for every coding agent

devspace agents runs Codex, Claude Code, OpenCode, Pi, Cursor, Copilot, Grok, or any ACP agent as a subagent, from ChatGPT, Claude, another coding agent, or your own shell. No server is needed for the CLI.

  • Profiles turn your "which model for which job" choices into named roles (planner, reviewer, …) in .devspace/agents/ or ~/.devspace/agents/.
  • devspace agents models <provider> lists the exact model names each agent accepts, so you never have to guess IDs like composer-2.5[fast=true].
  • Worktree isolation (--worktree) lets agents edit in parallel without touching your checkout.
  • continue, wait, stop, and events follow up with the same agent, wait on several agents at once, cancel a turn, or stream what it's doing.
  • Read-only runs are enforced for every agent that supports it. Claude can no longer reach writes through nested agents, and Pi works alongside extensions that override its built-in tools.
  • Per-provider settings (command, env, model, effort) live in config.jsonc. Settings in a provider's env, such as Claude's CLAUDE_CODE_ENTRYPOINT, now reach the agent.
  • Clear errors. Agents are named in errors, and failures carry the agent's own reason, for example Grok's "expired credentials". Tokens and Authorization values in that output are redacted.

Better in ChatGPT and Claude

  • Each host gets the tools its model knows. ChatGPT gets Codex-style tools, while Claude and other hosts get Claude-style tools, picked automatically. Override with tools.mode.
  • Activity history. Browse what happened in each workspace at /web.
  • Fewer cards. Cards appear only for opening a workspace and the end-of-turn change review.
  • Sturdier connections. Support for MCP protocol 2026-07-28, better reconnects, an opt-in OAuth refresh grace period, and a loopback trust-proxy mode for tunnels.

Experimental

  • Dynamic workflows (DEVSPACE_EXPERIMENTAL_WORKFLOWS=1) are JavaScript scripts that coordinate a fleet of agents: plan with a critic, implement → review → fix until approved, QA gates, bake-offs, and more. They're resumable and inspectable. The workflows skill now ships its full script reference and ready-made patterns, so ChatGPT and coding agents can write workflows themselves.
  • Code mode (DEVSPACE_EXPERIMENTAL_CODE_MODE=1) lets MCP hosts compose DevSpace tools with JavaScript.

Upgrading from 1.0

  • Node >=22.19 <27 is required. The installer handles this for you.
  • Config moves to ~/.devspace/config.jsonc automatically on first start. Your old file is kept as config.json.v1.0.bak.
  • Environment variables are no longer read for durable settings (DEVSPACE_ALLOWED_ROOTS, DEVSPACE_PUBLIC_BASE_URL, DEVSPACE_TOOL_MODE, …). Move them into config.jsonc using the migration table.
  • Restart devspace serve, then reconnect DevSpace in ChatGPT or start a new chat so the host picks up the new tool list.

Known limitations

  • Dynamic workflows and code mode are experimental, and their scripting API may change.
  • Read-only Claude runs block a fixed list of writing and agent-starting tools. A future release will switch to an allowlist so new Claude Code tools are covered automatically.
  • Sandboxed Pi runs (read_only and allowed) disable your Pi extensions, so models or tools that come only from an extension aren't available there. full_access runs keep them.

Full documentation: devspace.run/docs

Thanks to everyone who contributed to this release: @acari-git, @JunkaiWang-TheoPhy, @kkkzbh, @kotovasia5120, @linfeline, @luo-xingyu, @Rokurolize, @rome-xi, @signal-forge-lab, @stevetalkai, @wcf778, and @yulin0629.

Full changelog: v1.0.8...v1.1.0