Fix "settings are unavailable in this browser" in DeepSeek Harness

"settings are unavailable in this browser" is DeepSeek Harness's fallback message when the settings mirror fails to load — most often on the Settings → Models page, which needs both the provider directory and the settings mirror. Fix it by confirming the dsh web host is running, then refreshing the page; if that fails, restart the host and reconnect.

Where the error happens: the Models-page load chain

This is not a standalone error but the fallback for "settings mirror has no initial response." In the DeepSeek Harness source, the Models page builds one snapshot from three pieces: the configurable-provider directory (llm.providers), the settings namespaces (the shared settings mirror), and the referenced credentials (source).

1. Opening Settings → Models requests the provider directory and the settings mirror from the host.
2. If the mirror returns an error, the page shows the mirror's own error first; when the mirror gives no initial response at all, the page falls back to settings are unavailable in this browser (mirrored.error ?? 'settings are unavailable in this browser' in source, source).
3. The title often reads "failed to load provider directory" or appears while configuring models — it is the same thing: the Models page did not get its settings data.

So before suspecting your config, suspect the page↔host settings channel.

Debugging flow: work top to bottom

The settings mirror is served by the host process, so prioritize restoring the page↔host channel. Work through these 5 steps:

1. Confirm dsh web is running: the host (dsh web process) holds the settings data. Check that the process is alive in the terminal — did you restart the host recently while the page stayed on its old state?
2. Refresh the browser page: the simplest step. Mirror loading is one request; a refresh re-fetches it:
   • Press F5 / the refresh button;
   • If that is not enough, force-refresh: Cmd+Shift+R on macOS, Ctrl+Shift+R on Windows, to bypass the cache.
3. Restart the host, then reconnect: when the mirror channel is stuck, a refresh is useless and restarting the host works best:
   bash

   # 1. Press Ctrl+C in the terminal that started dsh web
   # 2. Start it again (use npx when not globally installed)
   npx @deepseek-ai/dsh web
   

   Wait for dsh web: http://127.0.0.1:3080, then refresh the page in the browser.
4. Remote/SSH browsers: rebuild the connection: a remote browser's settings scope is memory-mode — it only lives in the current process, never writes durably to the host, and does not recover after reconnection (source). Check the connection to the host (SSH forwarding, remote port), reconnect, then refresh.
5. Find the real error: the fallback copy hides the underlying cause. Open the browser dev tools (F12) → Network panel, refresh, and look at what the settings request actually returned (500 / 404 / timeout). Report the concrete error to the official repo or debug by it.

Common misconceptions while debugging

A settings error does not mean the config was wiped — everything on disk is still there. Three points:

1. Saved config is unaffected: API keys live in $DSH_HOME/.credentials.yaml and model config in $DSH_HOME/settings.yaml — both on disk. The page simply failed to read them, not delete them.
2. Do not edit settings.yaml first: restore the service channel first; the config is very likely fine.
3. Restarting does not lose settings: $DSH_HOME data is independent of the program itself; restarting the host, or even reinstalling DSH, does not touch saved model config (source).

The official mechanics of the settings mirror and scope

Knowing two official mechanics makes debugging more targeted — settings data comes from the host, and loading has an explicit state machine. In the source, the settings scope has five states: loading / unavailable / ready / saving / error. When it is unavailable, the Models page is not the only victim — the welcome banner shows "welcome acknowledgement settings are unavailable" too (source). So "settings unavailable" is a channel-wide problem, not just a Models-page one.

1. Model changes take effect immediately: the official docs state that model config applies on the next request, no server restart needed (source) — once the page recovers, refresh to see the new config instead of restarting.
2. Keys are write-only: after saving, the page receives only a redacted descriptor and never the literal secret; keys live in $DSH_HOME/.credentials.yaml, while settings keep only a credential reference (source). This is also why you should not hunt for the secret inside settings.yaml when debugging — it is not stored there.
3. Credentials resolve in a fixed order: inherited environment → $DSH_HOME/.credentials.yaml → the invoking directory's .env → $DSH_HOME/.env. When MISSING_CREDENTIAL shows up, fill the gap in that order (source).

Notes

1. "settings are unavailable in this browser" is a fallback — look for the real error in the Network panel first.
2. Refresh the page before restarting the host; the other order just adds a startup wait.
3. Remote browsers (SSH forwarding, etc.) do not persist settings; refresh the page after every reconnect.
4. If you suspect the port, confirm the host is listening with lsof -i :3080 (macOS/Linux) or netstat -ano | findstr :3080 (Windows).
5. Once the page recovers and models load normally, model-related DSH plugins (token usage, etc.) can help — pick them from the model category in DSH Plugin Hub.

dsh-plugin-hub · Plugin Center

Source: ui-settings-models store.ts (source), welcome-store.ts (source), Web UI guide (official docs)