[CLI] headless / TUI can't use agent presets (persona) — mount() is coupled to the web frontend

[zhao-gd]

Summary

The non-web surfaces (headless profile, and community TUI plugins that compose over dsh-base) cannot use agent presets — an agent always comes up as the default "coding agent" persona, even when dsh-agent-presets is mounted and settings.yaml sets agent-presets.default.

This blocks a Codex/Claude-Code-style CLI experience: tools load, but the persona (the agent's identity / system-prompt) does not.

Environment

• dsh 0.1.0-rc.6 (all @deepseek-ai/dsh-* packages at 0.1.0-rc.6)
• Reproduced with both the built-in headless profile and the community @dsh-tui/dsh-tui (0.1.2), each patched to insert @deepseek-ai/dsh-agent-presets with config.default set.

Repro

1. Create a headless (or TUI) profile that inserts @deepseek-ai/dsh-agent-presets (with a valid config.default) plus an MCP client.
2. Run one task: dsh --profile "who are you"

Observed: the reply is the deployment's default "coding agent" persona. The preset's persona (defined in an agent.cordis.yml under .agent-presets) is never applied.

Root cause (from reading the source)

• Per dsh-agent-presets README, ctx.agentPresets.mount(agentCtx, id) is the one supported call site, meant to run in the agent factory's setup(agentCtx) hook.
• Grepping every .js under @deepseek-ai/dsh-* finds no call to agentPresets.mount() / recompose() outside the agent-presets package itself — i.e. no core-layer component performs the mount.
• The mount only happens through the web conversation frontend (dsh-client-ui-conversation), which is why the web UI gets personas but headless and dsh-tui do not. dsh-headless run() calls agents.create(...) with a setup hook that only installs the model selection — it never mounts a preset.

So persona support is coupled to the web frontend instead of living in the core agent-composition path.

Expected

Agent-preset mounting should be a core-layer concern, so any surface (web / headless / TUI / third-party frontends) gets the same persona behavior. Concretely:

1. Move the preset mount into the core agent factory (or provide a core hook), so headless and TUI can compose an agent from a preset; and/or
2. Add a launcher flag (e.g. --preset ) so: dsh --profile headless --preset stock "task" works.

Related (minor, community TUI)

The community @dsh-tui/dsh-tui also does not integrate dsh-workspace, so sessions it creates show up in the web UI under "ungrouped" rather than under their workspace. This is a separate gap, but it compounds the "CLI is not first-class" impression. Mentioning it here for context; it can be tracked separately.

Suggestion

A core-layer agentPresets mount + a --preset flag would unblock the whole CLI ecosystem (headless, dsh-tui, and future terminal clients) without each frontend re-implementing preset composition.

[fan56]

From the TUI side this works today: dsh-tui-pi ships its own preset switching that does not go through the web-coupled mount path — presets are discovered from the agent markdown files on disk (filesystem walk, no ctx.get coupling, so it runs fine on the TUI fiber). Tab cycles the active preset live (footer shows dsh(<name>)), /preset opens a picker, /preset <name> switches directly, /agents manages the markdown files themselves.

npm i @aiwayds/dsh-tui-pi
dsh plugin add @aiwayds/dsh-tui-pi --profile <name>

Scope note: this is a full TUI plugin, not a fix for the upstream mount() coupling — headless and other community TUIs composing over dsh-base still hit the gap you traced, and that part remains upstream territory.