v0.5.18

DevSpace Ultra v0.5.18 — restore existing Classic conversations

This release fixes the remaining devspace_instance_binding_required regression after v0.5.17. An existing ChatGPT Classic conversation with a previously proved provider binding can use ordinary tools after reconnect because the server rechecks that authenticated binding against the exact live local Classic page on every request. A current exact invocation remains valid too.

New conversations still use one exact-page bootstrap. When a progress report returns a pending claim, the Agent follows its devspace_progress_bind next action once. No user-side pairing is required. Unbound identities, missing or duplicate local pages, different OAuth resources, and another computer's Connector remain rejected.

Live acceptance on a local ChatGPT Classic runtime confirmed that devspace_progress_report and devspace_plan_status returned success in the same turn after the repair. Focused provider-binding and server-instance isolation tests cover wrong resources and absent local proof.

v0.5.17

DevSpace Ultra v0.5.17 — same-turn capability recovery

This hotfix removes the visible devspace_instance_binding_required regression introduced by v0.5.14-v0.5.16. After one successful exact-page devspace_progress_report, ordinary read, write, edit, command and capability tools may run repeatedly during the same ChatGPT turn without asking the user to bind the page again.

The recovery is not a durable session fallback. Every call must match the original MCP session and exact request trace, remain inside the bounded lease, and re-verify the globally unique local Classic page plus opaque progress claim. Another computer, Connector App, conversation, request trace or ambiguous page cannot reuse it.

The complete verify:ultra suite and the focused multi-server isolation, progress narration and server-instance gates pass. Existing Main windows and conversations do not need to be recreated.

v0.5.16

DevSpace Ultra v0.5.16 — token-bound Connector App origin discovery

This release completes the generic multi-computer isolation introduced in v0.5.14 while remaining compatible with ChatGPT sessions that cached older tool metadata.

The local progress relay resource now contains a random, in-memory, per-Core origin-probe URL. When ChatGPT renders that resource, its sandbox sends one credential-free CORS request back to the same DevSpace public origin. The server accepts the origin only when both the unguessable probe token and the strict OpenAI asdk_app_*.web-sandbox.oaiusercontent.com origin validate, then persists it under this installation's serverInstanceId + public resource origin boundary.

This lets the overlay identify and reclaim only this Connector's stale progress/Goal relay frames even when an old ChatGPT tool schema still mounts the relay on ordinary reports. A different DevSpace server or computer does not possess the probe token and cannot register its App identity, donate authority or have its frames counted toward this installation's cleanup limits.

The release includes all v0.5.15 updater fixes, v0.5.14 exact local invocation enforcement, v0.5.13 live-safe package migration and bounded per-conversation progress retention.

v0.5.15

DevSpace Ultra v0.5.15 — updater stage output contract

This maintenance release includes the complete v0.5.14 multi-computer MCP isolation and v0.5.13 live-safe update convergence.

The transactional updater now captures stdout/stderr from the staged better-sqlite3 rebuild and in-memory native smoke test instead of allowing successful native-command text to enter the PowerShell function output pipeline. Invoke-StagePackage therefore always returns exactly one package object with Prefix, Root and Manifest, and the production update path no longer fails after a successful native rebuild with a missing Root or Prefix property.

The fix was accepted by a real 0.5.12 → 0.5.14 side-by-side update on Windows: the canonical package, native binding, Gateway/Core, public HTTPS, Caddy and all existing Main process IDs remained valid.

v0.5.14

DevSpace Ultra v0.5.14 — multi-computer MCP instance isolation

One cloud ChatGPT Classic account can connect several DevSpace MCP servers, with each server exposing a different computer through its own DDNS or stable tunnel. This release makes that a first-class, fail-closed public product contract.

Every installation now persists a unique serverInstanceId. Legacy configurations receive a deterministic fallback derived from the exact public /mcp resource until setup persists an independent random identity. OAuth continues to require the exact configured resource audience.

For ChatGPT Connector traffic, every non-bootstrap tool call must carry a current exact invocation observed on a local ChatGPT Classic Runtime page for that server instance. A same-named connection on another computer, stale provider binding, reused cloud account session, matching conversation ID or matching tool name is not enough. Unbound or wrong-computer calls return devspace_instance_binding_required; only the local one-time progress/Goal/Plan bootstrap is allowed, and it cannot complete unless this computer's CDP observer sees the Connector App under the exact local page.

Hidden relay cleanup is scoped by the complete persisted instance boundary: serverInstanceId + public resource origin + proved ChatGPT App sandbox origin. If one claim appears through two Connector App origins, resolution fails closed. A separate connection such as the configured local DevSpace Connector can therefore coexist on the same ChatGPT account without donating authority, satisfying local claims, sharing Goal/progress state, or losing its iframe resources.

This release includes the v0.5.13 live-safe updater, side-by-side legacy migration, native SQLite stage validation, stable runtime working directories, per-conversation progress retention, bounded relay cleanup and exact stuck-turn recovery tools.

v0.5.13

DevSpace Ultra v0.5.13 — live-safe Classic retention and updater convergence

This release completes the bounded relay-retention repair with a production-proven Windows migration path that keeps existing ChatGPT Classic conversations open.

Long-running Classic Main windows could inherit the installed npm package directory as their process working directory. Windows then refuses to rename that package until every renderer closes. The updater now preserves a legacy scoped root in place as a rollback source, installs the canonical devspace-ultra package side-by-side, migrates tasks and shims, and leaves already-open Main processes untouched. Future ChatGPT Classic Main and Worker launches use a stable LocalAppData working directory instead of the package tree.

The update handover now also:

• uses totalNonStreamActiveRequests as the authoritative active-work fence, ignoring the updater's own status probe and replayable SSE;
• disables runtime/watchdog triggers during swap and restores their prior enabled/running state;
• snapshots and stops the exact DevSpace process tree, including Caddy and descendant helpers;
• rebuilds better-sqlite3 in the staged package and opens a real in-memory database before promotion;
• regenerates Stable Gateway and watchdog tasks from the canonical package after a legacy migration;
• keeps rollback state, auth, conversations and runtime profiles unchanged.

Progress retention is now bounded per conversation: up to 48 Agent-authored messages for each conversation, with a 256-message global ceiling. A busy Main can no longer evict every other Main's useful narration history. The visible card remains one card per conversation, while hidden progress relays stay capped at eight and Goal relays at four.

Relay cleanup and claim authority are also Connector-isolated. The exact one-time claim records this installation's ChatGPT App sandbox origin and persists only that bounded origin set. Cleanup touches only frames carrying one of those locally proved origins. Another Connector or another computer—including a separately named the configured local DevSpace Connector connection—cannot satisfy a local claim, contribute ownership, or lose its frames just because it uses the same generic resource title. If one claim ever appears through two App origins, ownership fails closed.

Production acceptance preserves existing local ChatGPT Classic runtime processes, confirms public HTTPS health, runs the canonical package on Gateway/Core, and verifies relay bounds through read-only CDP inspection without navigation or synthetic turns.

v0.5.12

DevSpace Ultra v0.5.12 — transactional updater busy-state hotfix

This hotfix includes the complete v0.5.11 bounded Classic Main relay-retention repair and fixes one deployment blocker found during production rollout.

The Windows transactional updater queries the authenticated Stable Gateway status endpoint before replacing a live package. That status request is itself admitted by the Gateway before its snapshot is generated, so the old updater always observed at least one active HTTP request—its own probe—and incorrectly reported active-work even when totalNonStreamActiveRequests was zero.

The updater now subtracts exactly that one control request from the admission count. Every additional in-flight HTTP request and every real non-stream MCP/tool request still defers the update, so active work remains protected without requiring -Force.

All v0.5.11 safeguards remain included: recurring progress reports do not mount relay Apps, one-time progress binding is explicit, progress and Goal relay frames are bounded and retired, crowded-page ownership recovery stays bounded, the visible narration card and durable history remain intact, and loopback proxy trust is scoped safely.

v0.5.11

DevSpace Ultra v0.5.11 — bounded Classic Main relay retention

This release fixes the feedback loop that could make long-running ChatGPT Classic Main conversations accumulate hundreds of hidden MCP App relay frames, consume several gigabytes of private memory, and eventually surface HTTP 413, Internal Server Error, or message-delivery timeouts.

The visible DEVSPACE 進度旁白 card is preserved. Its Agent-authored history remains durable and bounded in the Stable Gateway. The release changes only the short-lived ownership transport behind it:

• ordinary devspace_progress_report calls no longer mount an MCP App iframe;
• an unbound report returns one explicit devspace_progress_bind action, and only that one-time action mounts the hidden claim relay;
• completed or expired progress and Goal relays release listeners and DOM state;
• each page retains at most eight fresh progress relays and four fresh Goal relays, with a 150-second retention window;
• exact-page claim resolution remains bounded but can recover a newly mounted claim even on a page that already contains hundreds of stale frames;
• the local reverse-proxy path trusts loopback only, preventing repeated forwarded-header validation errors without widening remote trust.

Regression coverage includes a 700-iframe page, one-time bind metadata, ordinary report metadata without UI, bounded relay cleanup, Goal/Rescue compatibility, full Ultra verification, and an alternate-port Core canary that leaves the production Gateway and Core online.

Existing oversized conversations are not deleted. After upgrade, the corrected overlay retires stale relay DOM; a single controlled page reload may be used to release renderer targets that the old host already detached internally. If an individual conversation still exceeds the upstream request-body limit, Context Guardian carries its active Goal/Plan/checkpoint into a fresh backend conversation without erasing the old history.

v0.5.10

DevSpace Ultra v0.5.10 — mandatory ChatGPT Classic MCP acceptance

This release makes the product contract explicit: DevSpace Ultra is primarily an OAuth-protected local development environment for ChatGPT Classic on Windows. Codex can execute installation and repair tasks, and optional Codex interoperability remains available, but a working Codex connection is not product acceptance.

The public installation framework now has one non-skippable order:

1. preserve existing state and prove local/public prerequisites;
2. create one ChatGPT Classic MCP connection for the exact stable /mcp URL;
3. complete OAuth, including a protected-tool trigger when authorization is deferred;
4. scan or refresh the authenticated catalogue and verify read, write, edit, apply_patch, exec_command, write_stdin, and devspace_progress_report;
5. enable the connection in a fresh ChatGPT Classic conversation;
6. run a real read plus an explicitly authorized disposable write/edit/command and read-back;
7. reconnect or open another fresh Classic conversation and prove authenticated access persists;
8. report every gate as pass/fail.

When an endpoint already passes external HTTPS/OAuth checks, the Agent must proceed immediately to the ChatGPT Classic connection and OAuth instead of reopening the router, reinstalling Caddy or repeating DNS work. Optional Multi-Main, Goal/Rescue and extra capability setup comes after core MCP acceptance.

Both packaged setup Skills, their OpenAI interface prompts, the capability manifest, README, current setup guides and installer output carry this contract. A dedicated static release gate verifies that none of the required steps or tools disappears in a future edit.

DevSpace checkpoint, handoff and recovery can keep a project moving beyond one conversation's usable context. This is durable continuity, not a literal increase or bypass of OpenAI model context windows, token allowances, account usage or rate limits.

The workflow follows current official OpenAI developer guidance for a public /mcp endpoint, Developer mode connection, OAuth, discovered tools/metadata and end-to-end tool testing:

• https://developers.openai.com/plugins/deploy/connect-chatgpt
• https://developers.openai.com/plugins/build/auth
• https://developers.openai.com/plugins/build/app-quickstart

v0.5.9

DevSpace Ultra v0.5.9 — Windows install and direct-ingress repair

This release repairs the installation path that could leave an incomplete global Git junction or a missing better-sqlite3 native binding. Windows and the macOS/Linux core-only installer now select the exact tagged GitHub Release archive, verify its SHA-256 digest, check the installed package and CLI, rebuild the native module after --ignore-scripts, and load-test it before setup.

DuckDNS setup uses the maintained LAN-bound Caddy ingress path. It derives the WAN address from the router rather than a VPN-sensitive internet-IP service, and sends that address explicitly to DuckDNS. UPnP TCP 80/443 mappings require explicit consent and never replace unrelated mappings. UPnP can create those mappings from the local network without logging into the router's administration page when the router supports and permits it; it is not a password bypass or a guarantee on every router. A router that does not support UPnP can use confirmed manual forwarding plus its public WAN IPv4. Only UPnP fault code 714 means a mapping is absent; a generic HTTP 500 is an error, not a deletion signal. The SOAP request now uses a PowerShell 5.1/7-compatible Content-Type and explicit UTF-8 body.

The setup fixes empty-config StrictMode failure, WinGet Caddy discovery, and a Gateway task/config-directory mismatch. It preserves an existing operator-managed custom Caddy route block. Existing standalone DuckDNS/Caddy tasks require explicit one-time migration consent; setup backs up task definitions and the Caddyfile, adopts the existing Caddy path, verifies the maintained route, then disables the old tasks.

Canonical startup now respects an external ownership receipt for a ChatGPT Classic runtime. A present receipt reserves that runtime from DevSpace startup—even if malformed—so the same package is never launched simultaneously by independent controllers or on conflicting debug ports. The external tool remains separate from DevSpace Core.

Local Gateway/Core health is reported as local readiness only. Production acceptance still requires independent external HTTPS and OAuth checks, then a ChatGPT Connector initialize, tools/list, and an explicitly authorized write-capable call in a disposable workspace. The installer does not claim those external checks succeeded on behalf of the user.

Current installation docs no longer advertise the old upstream npx @waishnav/devspace route, port 7676, direct Git URL global npm install, or execution of a moving main script. Historical changelog and design specifications remain available as history.