Plugin-registered commands execute but render nothing on the launcher screen

[yul761]

Posting here since Issues are disabled on this repo. I'm not sure whether this is intended behaviour for plugin commands or a gap worth fixing — details and a minimal reproduction below.

Summary

On the launcher screen (the "Into the Unknown" / 探索未至之境 new-session screen),
a command registered by a plugin executes but produces no visible output, and
the view does not advance into a session. The same command, in the same process,
renders normally once a session exists.

Built-in commands (/goal etc.) do not have this problem on the same screen:
they render and switch into the session view.

The failure is silent — the input clears, so the command was accepted and ran
(server-side side effects do happen), but the screen shows nothing at all. From a
user's point of view the plugin is simply broken.

Reproduction

A 13-line plugin is enough. It registers one command that returns one line of
text: no UI slot, no service, no network, no storage.

index.js

export const name = 'dsh-probe-repro';
export const inject = ['commands'];

export function apply(ctx) {
  ctx.commands.register({
    name: 'probe',
    description: 'Minimal probe: returns one line of text',
    handler: () => ({ kind: 'success', text: 'probe ok — if you can read this, rendering worked' }),
  });
}

package.json

{
  "name": "dsh-probe-repro",
  "version": "0.0.1",
  "type": "module",
  "main": "index.js",
  "dsh": { "bundle": { "patch": "probe.cordis.yml" } },
  "peerDependencies": {
    "@deepseek-ai/cordis": "^4.0.1",
    "@deepseek-ai/dsh-commands": "0.1.0-rc.6"
  }
}

probe.cordis.yml

- insert:
    - id: probe-repro
      name: dsh-probe-repro

Steps

dsh plugin --profile probe-test add -w "$PWD"     # $PWD = the plugin dir above

Then add "@deepseek-ai/dsh-web-app" to bundles in
~/.dsh/profiles/probe-test/package.json — dsh plugin add creates the profile
with @deepseek-ai/dsh-base and the plugin only, so without this there is no web
UI and nothing binds the port. (Possibly a separate bug; noting it because the
repro needs it.)

dsh --profile probe-test --port 8911

1. Open http://127.0.0.1:8911/ — you land on the launcher screen.
2. Type /probe, press Enter.
   → The input clears. Nothing renders. The view stays on the launcher screen.
3. Open any existing conversation from the sidebar (or send any message to start one).
4. Type /probe, press Enter.
   → probe · probe ok — if you can read this, rendering worked

Expected

Step 2 behaves like step 4 — and like a built-in command does on that screen:
the output renders, and the view moves into a session.

Actual

The handler runs, its CommandResult is discarded, and the view does not change.

What we ruled out

• Not plugin-specific content. The repro above touches no slot and no
  service; it is one command returning one string.
• Not a client-slot conflict. Commands with no registered UI slot at all
  behave identically.
• Not the registration shape. The descriptor matches what built-in commands
  use.
• Not the command failing. The input clears and side effects land; only the
  rendering and the view transition are missing.

Impact

Every dsh plugin that ships a command hits this on a user's very first
interaction, which is exactly when they have the least context to diagnose it.
Because the failure is silent rather than an error, the natural conclusion is
that the plugin is broken, and clicking "New session" returns the user to the
same screen.

Plugin authors cannot work around it in-product: on that screen the only slots
that render are conversation.hero.workspace and conversation.hero.agentPreset,
both kind: 'single' — registering into either replaces the host's own workspace
picker rather than adding beside it. conversation.composer.dock /
conversation.input.dock are kind: 'list' but do not render on the launcher
screen (the shipped stats line that lives in the dock is absent there). The only
channel left is the command's own description string, shown in the command
autocomplete — which is where we ended up putting a warning.

Environment

• dsh 0.1.0-rc.6
• macOS (Darwin 25.5.0), Node v26.3.0
• Reproduced 2026-08-22 in a dedicated profile containing only
  @deepseek-ai/dsh-base, @deepseek-ai/dsh-web-app, and the probe plugin above.

---

Is this the intended behaviour for plugin-registered commands on the launcher screen? If it is, is there a supported way for a plugin to render something on that screen that I've missed? If it isn't, I'm happy to add anything else that would help — the reproduction above is a self-contained 13-line plugin.

[Jstn-1g]

Thanks for the excellent minimal reproduction. I traced this against current master (b150a551), and the result is not discarded: CommandUiRuntime intentionally relies on the durable command/run / command/done pair instead of echoing the returned text directly (execution path).

The blank-screen behavior happens one layer later. Session.composerPhase explicitly excludes a generic command Chat node from “visible conversation content” (phase predicate); while the phase remains blank, the session view returns null (render gate). There is even a regression test pinning generic command rows as blank while a non-command node activates the conversation (test).

/goal behaves differently because ui-goal supplies an additional client-side command-input Conversation Definition and keyed renderer; that non-command node activates Chat, after which the generic result row is visible (registration, definition).

So this appears intentional at the generic-command layer, but the reproduction identifies a real extensibility gap: a server-only plugin using ctx.commands.register() has no way to opt into visible first-interaction output. A plugin can ship a browser half modeled on ui-goal, but that is substantially more machinery than a normal command and is not an additive launcher slot.

An explicit presentation/activation opt-in for command descriptors would preserve control commands that deliberately stay on the hero while giving third-party commands a supported first-interaction path. An additive hero list slot would address the broader launcher-extension case too.