dsh-TUI 0.19.0: Validation Line at 0.2.2-rc.1, One /update Aligns Three Layers (Nov 6, 2026)

The DSH 0.2.2-rc.1: First Release Candidate Aggregates the 0.2.2 Line (Nov 4, 2026) coverage ended with the harness itself; this is the client side catching up. Per the npm registry (fetched 2026-11-10), dsh-TUI — the fullscreen terminal client — published 0.19.0 at 03:36:50 UTC on November 6, five days after dsh-TUI 0.18.0: Validation Line at rc.5 (Nov 1, 2026), and aimed at the wall that 0.2.2-rc.1 raised for it. The GitHub release page stamps 03:32:50 UTC, four minutes before the registry, and the release record carries no pre-release flag.

The validation line moves to 0.2.2-rc.1

Per the release notes, the shape repeats last month’s fix with bigger consequences: v0.18.0’s precise peer range stopped at 0.2.1-rc.5 — this article confirmed against the registry that the 0.18.0 entry lists no 0.2.2-rc.1 — so a host upgraded to DSH 0.2.2-rc.1 judged the TUI incompatible and skipped it. PR #1886 (by @Lucas2011wastaken, merged 2026-11-06 03:14:08 UTC per the PR API) adds 0.2.2-rc.1 to the validated line and the peer range, and the notes state the older lines stay put: 0.2.1-rc.5 and earlier remain in range, which the 0.19.0 registry entry’s peerDependencies confirm.

The deeper adaptations ride along, per the notes: model selection moves to the upstream session-level Agent.model seam, tool limits fall to each Agent’s scope, and the release adapts the cordis 4.1 lifecycle and fixed-action approvals — with old hosts keeping the previous selection reference and request waterfall. One behavior change lands with that: on DSH 0.2.2 hosts, approval-type questions in the permission questionnaire now offer only the caller-declared options, with no free-text entry; ordinary questionnaires keep free input.

One /update for TUI, engine and launcher

Per the release notes, /update used to swap only the TUI in the profile, leaving the global dsh and the launcher where they were — a combination where the new TUI’s peer range could refuse to install on the current engine. Now the precheck resolves one plan across the three layers and executes it serially as TUI, then engine, then launcher (PRs #1847 and #1849 by @Lucas2011wastaken; #1889 by @AdamPlatin123): the engine step selects only the highest published version inside the target TUI’s peer range — never a downgrade, never an alpha line — and verifies the result with profile module resolution plus dsh --version; the launcher step only moves global installs whose ownership it can prove, leaving multi-member pnpm groups, in-project dependencies and ambiguous aliases untouched; and a TUI already on the latest no longer short-circuits — the engine and launcher still get aligned.

The refusal semantics, per the notes: when the new TUI needs an upgrade while the currently running engine sits outside its peer range, /update refuses first even when the engine could be upgraded automatically — the official load validation judges by the running dsh — and prints the upgrade-the-engine-first command. An engine install that fails verification does not restart, but the upgraded TUI is kept; after a failed engine install only a provably bootable entry may restart, with the skip reasons left on the next mount’s screen and in its warnings. Three environment overrides pin the behavior: DSH_TUI_UPDATE_ENGINE=0 pins the engine, DSH_TUI_UPDATE_LAUNCHER=0 skips the launcher, and DSH_TUI_DSH_PM=npm|pnpm overrides package-manager detection.

Channel failures say so; the other behavior changes

Per the release notes (PR #1794 by @MomentDerek, merged 2026-11-01 04:10:07 UTC per the PR API), a subagent channel that fails as a whole now says so: when the same provider’s settled runs fail at least twice and more than half, a channel-degraded notice appears above the subagent list and suggests switching providers. Only the switchable claude-code and codex channels prompt; the built-in subagent, workflow and teammate rows do not false-positive.

The remaining behavior changes, per the notes: /restart now carries images across the handoff, and inputs the backend dropped are staged as undelivered for the user to decide on resending, instead of being re-sent automatically (PR #1764); completed history rows no longer re-run the typewriter animation, with the trade the notes state outright — bookkeeping without the old 2048-row cap grows linearly with history, on the order of a dozen-plus MB at the tens-of-thousands-of-rows scale, released with the session (PR #1796); the btw input box stays one row, windowing a long draft around the caret and marking the clipped side with an ellipsis (PR #1866); the Linux process name reads dsh-tui in ps -o comm, top and system monitors, with /proc/<pid>/cmdline unchanged (PR #1841); rio and Orca join the CSI >1u extended-key whitelist, making Shift+Enter and modifier combos work, with DSH_TUI_FORCE_EXTENDED_KEYS=1 and DSH_TUI_DISABLE_EXTENDED_KEYS=1 as the forced and disabled escapes — disable wins (PRs #1821 by @Plintash and #1840).

The fixes under those

Per the release notes: the session manager page drops the duplicated, easily truncated per-project paths and unifies every source into a single-line list, and a fast second click on another project no longer reads as word selection — multi-click detection now requires the same onClick ancestor (PR #1755 by @xuzijian2019); returning from a fullscreen interface or /resume no longer re-types history row by row (PR #1796); turns where the session itself closed show session-stopped rather than user-interrupted (PR #1769 by @FlameTN7); and on Linux, old thread ids reused by other processes no longer get idle sessions misjudged as occupied (PR #1770, also by @FlameTN7). On the backend side, /usage and /diff queries show their output after success under the Codex backend, and Enter in the completion menu executes directly instead of demanding a space first (PR #1775). Terminal compatibility rounds out the set: Kitty keypad codepoints 57416–57426 are filled in, and CSI-u non-printing keys no longer insert as text (PRs #1840 and #1841). A new troubleshooting entry documents in-session git failing wholesale on the Orca terminal, with env -u GIT_CONFIG_COUNT as the workaround (PR #1863).

Contract, Node, and the one adapter that stayed

Per the release notes, 0.2.2-rc.1 is the main adaptation line; 0.2.1-rc.5, rc.4, rc.3, rc.2, 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1 and earlier validated lines stay in contract, and versions outside it draw a drift warning. On Node, the notes state DSH 0.2.2 requires Node >=24.9 while this package itself still declares ^22.19 || >=24 — per the notes, running a 0.2.2 host on an older Node is an upstream-unsupported combination, and the 0.19.0 registry entry carries that same engines declaration — so check node -v before upgrading. The notes address the users 0.2.2-rc.1 already locked out: the in-app /update needs the TUI to open, so they point at the npm command directly and state that allow-version exemptions previously granted to v0.18.0 are no longer needed after upgrading; upgrading from v0.18.0 through /update is what aligns the engine to 0.2.2-rc.1 and the launcher along with it. The dst automation CLI’s validated line did not move — still 0.2.1-rc.5, with dst dsh passing official arguments through on a 0.2.2 host. The Windows offline installer follows the contract to 0.2.2-rc.1 and, per the notes, downgrades an installed higher RC back to the validated line; the bundled first-party plugin manifest pins to 0.19.0.

The validation line moves to 0.2.2-rc.1

One /update for TUI, engine and launcher

Channel failures say so; the other behavior changes

The fixes under those

Contract, Node, and the one adapter that stayed

More in this series