dsh cli vs desktop vs web: what each can do

dsh cli, web, and desktop are not three products but three entries to one system. The CLI runs commands, web provides the interface, and desktop adds system integration; mixing them up usually causes "which profile did the plugin go into."

Capability matrix

Start with the table, then read each column.

The CLI is strongest for commands and automation, the web for interface and remote access, and desktop for system integration. The CLI starts services, installs plugins, and runs scripts but has no full UI (source). The web opens in a browser and suits remote servers and multiple devices but depends on a running backend. Desktop packages the same core with windows, tray, and file dialogs, not a separate ecosystem.

CLI: commands and automation

The CLI is the entry to the entries: without it, neither web nor desktop starts.

1. Start the service: dsh web prints a local address.
2. Manage plugins: dsh plugin --profile web list/add/remove.
3. Inspect configuration: dsh --dump-config.
4. Automate: scripts and CI call commands and read exit codes.
5. Confirm the version: dsh --version.

Its boundary is "invisible," and that makes it the best diagnostic entry. It performs actions without session lists or visual panels; when the UI fails, return to the CLI to confirm service state. Logs, versions, and the config tree are all visible in the terminal.

Web: browser and remote

Web is the main daily interface for sessions, plugin market, files, and settings.

1. The CLI or desktop starts the service; a browser opens the address.
2. Browse sessions, search, archive, and use the plugin market.
3. Remote scenarios use SSH or a reverse proxy.
4. Multiple devices sharing one service need concurrency care.
5. Browser compatibility and cache issues: switch browsers first.

Its boundary is "depends on the service," and that makes it the best remote option. If the service is down, the port is closed, or authentication fails, the page will not open; check the service before the browser. A server service plus a local browser is the most common Linux and cloud setup.

Desktop: windows and integration

Desktop wraps the same capabilities in a client and adds system integration.

1. Install from a package and start without manually launching a service.
2. Get windows, tray, notifications, and file dialogs.
3. Use the built-in plugin market and settings.
4. Update through the app, not the CLI.
5. Uninstall through the system, then clean data.

Its boundary is the platform. releases focus on macOS and Windows; Linux has no official desktop package and should use CLI plus browser. Desktop is not "more features"; the core is the same, and the difference is integration. Do not install two copies for one feature.

Session sharing

Sharing depends on the data directory, not the client.

1. Same machine and same DSH_HOME: sessions are shared.
2. Different machines: independent; sync or migrate.
3. Different data directories: look like two environments.
4. Simultaneous writes to one session: locks and version conflicts.
5. Migrate by stopping the service and copying.

"Desktop cannot see web sessions" usually means a different data directory. Confirm DSH_HOME first. Do not write one session from two clients; use separate sessions for parallel work.

Where plugins are managed

Plugins install into a profile, not a client.

1. Desktop and web often use different profiles: install separately.
2. The CLI takes --profile: a wrong target hides the plugin.
3. The same profile shares installed plugins across clients.
4. The market is an interface; installation writes to the profile.
5. When "installed but not working," confirm the profile first.

"Which client" matters less than "which profile." The client is an operation entry; the profile decides scope. Record profile and plugin list when switching clients or machines.

Choosing

Choose by where you work, whether you need a GUI, and whether you are remote.

CLI plus web is the base combination. Desktop is an experience enhancement, not a requirement; remote scenarios are lighter with CLI and web. Do not force one entry for consistency; each has a boundary.

Next steps

Recognize the entry, the profile, and the data directory. For CLI commands, read What dsh cli is. For web versus desktop, read How to choose between web and desktop. For remote access, read How to configure remote access.

Sources: dsh CLI README, DeepSeek Harness docs, deepseek-harness repository