dsh tui: exit hint suggests dshcli --resume <id> but no such binary exists (command not found)

[tommy2lion]

Describe the bug

On exit, the TUI prints a resume hint that names a binary which does not exist:

Resume this session: dshcli --resume session-abc123

Running dshcli --resume ... fails with dshcli: command not found. The actual CLI entry point is dsh; the working command is dsh --profile tui --resume <session>.

Environment

• dsh 0.1.1-rc.2, dsh-tui-plugin 0.3.0, Windows (Git Bash)

Root cause

• Hint string: lib/tui/i18n.js → 'exit.resumeHint': 'Resume this session: dshcli --resume {id}' (written on exit in lib/index.js:63).
• dshcli is the internal commander command name declared in lib/startup.js (.name('dshcli')), not an installed binary — dsh-tui-plugin declares no bin field in its package.json, and @deepseek-ai/dsh only exposes dsh ("bin": { "dsh": "lib/bin.js" }).

So the hint is not copy-paste executable; a user who follows it literally gets command not found and may believe resume is broken (see the related report about --resume rendering an empty conversation).

Suggested fix

Print the actual launcher invocation, e.g. dsh --profile tui --resume {id} (or resolve it from the real entry point), so the hint is copy-paste executable.

[nokkies]

Your harness-side fact checks out, and it points at where the fix has to happen — which is not this repository.

Verified: the CLI package declares exactly one binary:

"bin": { "dsh": "lib/bin.js" }

So dshcli is not installed by anything the harness ships, and your reading is right that it is only the internal commander program name. A user following that hint literally gets command not found, exactly as you describe.

But dsh-tui-plugin is a third-party plugin, not part of this repository — there is no TUI package in the harness tree at all. The three files your analysis names (lib/tui/i18n.js, lib/startup.js, lib/tui/app.js) all belong to that plugin, so both the hint string and the fix live with its author. Worth re-filing there, because nobody watching this repo can change it.

Two things worth carrying into that report:

1. The correct invocation includes the profile — dsh --profile tui --resume <id> — since the plugin runs under its own profile. A hint that printed only dsh --resume <id> would still not reproduce the user's environment.
2. Your companion report (dsh tui: --resume selects the session but renders an empty conversation until the first message #4750, --resume rendering an empty conversation) is the same package, and the two together are worse than either alone: a user who hits the empty conversation and then tries to re-run the resume command finds the command does not exist either, which reads as "resume is broken" rather than "two separate presentation bugs". Filing them as a pair would make that case.

Nothing here is harness behaviour, so there is no version of this that gets fixed by upgrading dsh.