Skip to content

Releases: atlas5301/dsh-remote-sessions

v0.8.11 — bridge web carries pnpm/node on its PATH

Choose a tag to compare

@atlas5301 atlas5301 released this 06 Oct 05:07

Installing a plugin through the remote web failed with spawn pnpm ENOENT: pnpm is installed on the remote (~/.npm-global/bin), but the SSH-launched web process inherits a PATH without the npm global bin dir. The bridge launcher now derives the npm global bin dir from the CLI path and sets PATH=<global-bin>:<node-bin>:$PATH explicitly.

Gate: 242 backend + 11 runtime tests.

Install: dsh plugin --profile web add dsh-remote-sessions — npm: https://www.npmjs.com/package/dsh-remote-sessions

v0.8.10 — symlinked remote roots adopt canonical-cwd sessions

Choose a tag to compare

@atlas5301 atlas5301 released this 05 Oct 22:49

Operator case: the mapped remote root (/home/ubuntu/mygo) is a symlink into backup storage (pub_storage/home/relocated/mygo). Sessions created through the remote web recorded the canonical working directory, never matching the operator-visible spelling — invisible locally.

The backend now resolves each mapping's remote root to its canonical (realpath) form over SSH at startup and adoption accepts both spellings as the same directory. Such sessions adopt into the mapped workspace automatically.

Gate: 241 backend + 11 runtime tests.

Install: dsh plugin --profile web add dsh-remote-sessions — npm: https://www.npmjs.com/package/dsh-remote-sessions

v0.8.9 — membership rebinds retry until verified

Choose a tag to compare

@atlas5301 atlas5301 released this 05 Oct 22:15

Root cause of 'mygo has 3 sessions, only 2 visible': the one-shot workspace-membership rebind could lose a race against the registry's own membership pruning during the busy first list after a restart — a failed session stayed invisible until the next app restart.

The rebind now verifies the session reached the workspace's visible membership (the getter the UI reads) and retries on every list until verified (bounded at 10 attempts for permanently unbindable anchors).

Gate: 239 backend + 11 runtime tests. Live-verified with the operator's real state: all 3 mygo sessions in the membership getter.

Install: dsh plugin --profile web add dsh-remote-sessions — npm: https://www.npmjs.com/package/dsh-remote-sessions

v0.8.8 — bridge launch gated on patch content; remote sessions recovered

Choose a tag to compare

@atlas5301 atlas5301 released this 05 Oct 22:06

Root cause of 'remote sessions not retained': the first bridge boot ran with a clobbered template patch ([]) — the web UI served its OWN session store, and every session created through it was stranded there. All 8 stranded sessions were recovered into the resident's shared store.

  • The bridge launch is now gated on the patch content: the resident session-store pin must be present in the written profile patch; a clobbered patch is repaired once, otherwise the open fails closed.
  • The /remote-sessions/web/open route composes the bridge with the same synced model environment as models/sync — the model list reaches the bridge through the app path.

Gate: 238 backend + 11 runtime tests. Live-verified: fresh boot writes the 18-row patch, verifies the pin, and the bridge lists all 19 sessions including the recovered ones.

Install: dsh plugin --profile web add dsh-remote-sessions — npm: https://www.npmjs.com/package/dsh-remote-sessions

v0.8.7 — workspace membership survives local restarts

Choose a tag to compare

@atlas5301 atlas5301 released this 05 Oct 05:47

Remote-bound sessions keep no local journal, and the native workspace registry rebuilds its membership index from the local store at startup — so after every local restart the workspace lists appeared empty even though the sessions existed on the remote (confirmed in the real registry's own diagnostics: 'session header is missing').

Two traps fixed along the way:

  • attachSession only registers the session path for NEW members — re-attaching an existing member is a silent no-op. The fix runs a detach+attach cycle.
  • Running the re-registration during plugin apply deadlocks on the storage-domain write chain inside the boot transaction. The rebind is deferred to the first list call after boot.

Gate: 236 backend + 11 runtime tests; live-verified with the operator's real bindings and workspace registry: mygo lists all three sessions, dist-optimm lists all four, after one list round.

Install: dsh plugin --profile web add dsh-remote-sessions — or from npm: https://www.npmjs.com/package/dsh-remote-sessions

v0.8.6 — instance adoption actually writes; confirmed-absent sessions unbind

Choose a tag to compare

@atlas5301 atlas5301 released this 05 Oct 05:47

Fixed a self-inflicted bug: after a resident restart, every session went permanently offline in the local list. Instance adoption routed its write through the binding store's immutable set(), whose conflict check forbids instance-id changes — every adoption failed with REMOTE_BINDING_CONFLICT.

  • Adoption now writes through the low-level row write (pinned fields still verified); a runtime-identity or authority change still fails closed.
  • The remote store is authoritative for the session list: a bound session confirmed absent from an unfiltered remote list (failed-create orphans, remote deletions) is unbound instead of lingering as an offline ghost; in-flight creations are protected.

Gate: 235 backend + 11 runtime tests; live-verified with the operator's real binding table against the restarted resident.

v0.8.5 — the remote web button opens a session-sharing bridge

Choose a tag to compare

@atlas5301 atlas5301 released this 05 Oct 05:40

The settings-tab Web button now boots a machine-scoped bridge profile (rs-web-<machine>) on the remote host: the shipped web UI composed over the resident's session store, attachments and credentials, carrying the synced model catalog. Sessions, models and credentials are the same on both sides — a session created in the bridge web UI appears in the local workspace (through list adoption), and every locally-created session appears in the bridge.

A legacy standalone dsh web is never mistaken for the bridge: ownership is verified per profile and port, and the stale-kill pattern cannot self-match its own SSH session. Gate: 233 backend + 11 runtime tests. Live-verified on a remote host: the bridge lists all resident sessions; a bridge-created session is visible to the resident; synced models serve in the bridge.

v0.8.4 — surface rejected remote model selections

Choose a tag to compare

@atlas5301 atlas5301 released this 05 Oct 05:40

A rejected remote model selection (e.g. an unsupported reasoning effort) now propagates the resident's error and is surfaced through the native session-error channel — third-party composer seats that swallow rejections can no longer hide the failure. READMEs document host-specific providers (loopback baseURLs cannot serve remotely) and the never-silent selection contract.

Live-verified on a remote host: picking a model on a remote session installs it in the remote journal (model/selection) and the next request serves with it. Gate: 230 backend + 11 runtime tests.

v0.8.3 — first npm release

Choose a tag to compare

@atlas5301 atlas5301 released this 04 Oct 02:36

Published to npm: dsh-remote-sessions@0.8.3 (MIT).

Install: dsh plugin --profile web add dsh-remote-sessions — then restart the runtime and open Settings → Remote Sessions.

Verified against DSH 0.2.0-rc.2 with a live remote host (provisioning, model/credential sync, session proxy, file tree, terminals, upgrade and restart flows). Release gate: 229 backend + 11 installed-runtime tests, including a 20-test operator-behaviour regression suite.

See the README (English | 中文) for configuration and boundaries.