description: "The browser GUI for dsh: interactive chat, model and settings management, and session history, for users running the dsh web surface."
English | 中文
Run dsh --profile web and the interface opens in your default browser, ready for interactive chat with the agent. You get the conversation view, model and settings management, and session history, backed by the same model access, tools, and safety defaults as every other surface. The command prints a tokenized startup URL; the browser exchanges that token for a signed session cookie and redirects to the clean root URL. You can change the port, suppress the browser handoff, and allow extra hosts from the command line; binding all network interfaces is intentionally not supported. Choose it for interactive work in the browser; dsh-headless is the one-shot command-line sibling.
Start the GUI, open your browser, and start talking to the agent. The flags fine-tune the invocation.
dsh --profile web
dsh --profile web --no-open --port 8080
After startup you see a dsh web: line whose root URL carries a fresh process token. Unless --no-open or an SSH session suppresses it, the default browser opens that URL, receives a signed cookie, and redirects to the clean root page. You know it worked when the page loads and you can chat with the agent. Two failures to expect: if the frontend is not built, startup stops with a build hint (pnpm run build in a checkout); if the browser cannot be opened, a credential-free diagnostic prints to stderr while the server keeps running — open the printed startup URL yourself.
Most users never set these; the command-line flags feed the four settings below — --host, --port, and --trusted-host come from the invocation, and --no-open turns the browser handoff off for that invocation:
| Field | Default | Meaning |
|---|---|---|
openBrowser |
true |
Open the default browser after startup; SSH launches suppress it |
printUrl |
true |
Print the dsh web: URL line at startup |
surfaceContext |
true |
Give the agent GUI-orientation context and expose DSH_WEB_URL to its shell commands |
trustedHosts |
[] |
Extra hosts allowed to reach the GUI from the network |
The generated configuration catalog is the exhaustive source for every accepted field and its JSDoc.
By default the GUI accepts connections from this machine only. A deployment that binds all network interfaces also allows browsers from the LAN, and the printed URL then includes a LAN address; --trusted-host adds extra hosts in either case. Host and Origin checks control reachability, while the token exchange authenticates every Host API method and WebSocket stream. The LAN addresses are sampled once at startup, so a network change later is not picked up — restart the GUI to re-advertise.
When you launch dsh --profile web over SSH, the URL line still prints but the browser is not opened for you: the SSH client or editor owns the local forwarding address. Open the forwarded URL on your machine yourself; the printed URL names the remote host's loopback endpoint.
Each browser session composes its own agent from the shipped presets (the standard preset by default), instead of sharing one process-wide tool set. You can change the default preset or add your own presets under $DSH_HOME/.agent-presets.
Read these pages when you want to go deeper into the shared core, the browser reload pipeline, or the built frontend.
When surfaceContext is true, the harness:source section identifies the on-disk Harness implementation without claiming it is the working directory, and the app:web-surface global section (first-party order −800) orients the model to the GUI: the canonical local URL, the "this page" referent, the update contract (the reload receiver is always on; no-refresh reloads additionally need the pnpm run dev:web watcher), and the instruction not to start replacement servers. DSH_WEB_URL additionally appears in the managed bash environment with its description, resolved per invocation from the live server. When it is false, neither section nor the variable is registered.
One source line and one prompt paragraph per session plus two managed-environment variable lines; constant per process.
The prompt section sits near the system prompt's head and is stable for the life of the process (the port is a boot fact), so it does not invalidate the cache across turns.
These limits tell you what to expect in unusual setups — a source checkout, SSH sessions, or strict networks. They are current package constraints, not a general browser comparison or a task backlog.
pnpm run build first; startup stops with a build hint when the dist is missing, and there is no source-serving fallback.BROWSER overrides only come from the environment — a discovered .env cannot set BROWSER; only an inherited value can choose the executable for the automatic handoff.--host 0.0.0.0 is rejected at startup for safety; use the default loopback host.