dsh tui: --resume selects the session but renders an empty conversation until the first message

[tommy2lion]

Describe the bug

Booting the TUI with --resume <session> selects the persisted session but renders an empty conversation — visually indistinguishable from a brand-new session. The old transcript only appears after the user sends a message (or manually re-selects the session from the sessions list).

Environment

• dsh 0.1.1-rc.2 (@deepseek-ai/dsh)
• dsh-tui-plugin 0.3.0
• Windows 11 + Git Bash (MINGW64)

To reproduce

1. dsh --profile tui → have a conversation → exit (note the session id in the exit hint).
2. dsh --profile tui --resume <session-id>.
3. The session appears selected (e.g. in the sidebar), but the conversation area is empty — looks like a fresh session.
4. Send a message: only now does the old transcript get folded in above the new message.

Expected: booting with --resume should display the persisted conversation immediately.

Root cause analysis (from reading lib/tui/app.js in dsh-tui-plugin@0.3.0)

The boot path in refreshSessions() only selects the session:

// lib/tui/app.js:585-588
if (this.current === undefined && this.startup.resume !== undefined) {
    this.ensureCurrent(this.startup.resume);
}
this.repaint();

ensureCurrent() (line 535) merely sets this.current and resets scroll — it does not attach an agent or fold the transcript. The two other paths that open a session both eagerly attach the agent:

• newSessionWithAgent() (line 1029): await this.currentAgent();
• selectSession(id) (line 1042): await this.currentAgent();

currentAgent() (line 596) is what actually resumes the agent (agents.resume(...)) and folds the full persisted history via attachResumedSession() (lines 615-628). Because the --resume boot path never calls it, state.transcript stays empty until the first send() (line 819) or a manual selectSession.

Data is intact

This is purely a rendering/attach-timing bug, not data loss. The persisted session.jsonl.zstd for the affected session decodes to a complete artifact (valid header + 314 event records, 9 turns, clean turn/end), and resuming the same session via the sessions list works correctly.

Suggested fix

In the boot path, after ensureCurrent(this.startup.resume), await this.currentAgent() (mirroring selectSession), so the transcript renders on first paint.

[nokkies]

This is a dsh-tui-plugin bug rather than a harness one — worth knowing before you wait on a dsh release for it.

There is no TUI package anywhere in this repository; dsh-tui-plugin is third-party, and the boot path you traced (lib/tui/app.js refreshSessions()) belongs to it. So the fix is the plugin author's, and re-filing there is the only route that reaches someone who can make it.

Your analysis reads correctly to me from the outside: selecting a session and rendering its transcript are separate steps, and the boot path does the first without the second, so the conversation stays empty until something else triggers a render. That the transcript appears after the first message — rather than never — is consistent with that, since the send path is what folds the history in.

One thing worth adding when you re-file: your companion report (#4751, the exit hint naming a dshcli binary that does not exist) compounds this one. A user who sees the empty conversation and re-runs the printed resume command hits command not found, and the natural conclusion is that resume is broken outright rather than that two presentation bugs stacked. The pair is a stronger report than either half.

I verified the harness side of #4751 while looking: the CLI ships exactly "bin": { "dsh": "lib/bin.js" }, so dshcli is indeed not installed by anything this repo publishes.

[Jstn-1g]

Implemented in the owning plugin and opened for maintainer review:

• PR: fix: render resumed session transcript on TUI startup JimLuan/dsh-tui-plugin#1
• Exact head: Jstn-1g/dsh-tui-plugin@e065cac

The patch eagerly hydrates the session selected by startup --resume. It also single-flights per-session opening: a regression deliberately delays resume, submits the first message concurrently, and verifies exactly one resume plus successful message delivery.

Verification on the plugin's real Harness bundle composition: 399/399 tests passed (including 188 app tests), TypeScript build passed, and git diff --check passed.