dsh-lan-access
A DeepSeek Harness web plugin that adds a LAN access toggle to the DSH Settings shell (Settings → General). It replaces the manual cordis.patch.yml webserver override:
> Tested with DeepSeek Harness v0.1.1-rc.1 — this plugin is verified runnable against that harness version.
- On — the web GUI binds
0.0.0.0, so other machines on the same network
can open it at http://<LAN-IP>:3080. The /api trust fence is updated live, so the browser on a LAN machine works fully (chat, tools, workspace).
- Off — the GUI binds
127.0.0.1again (loopback only — the safe default).
Screenshots
The DSH web GUI opened from another machine on the same network (http://192.168.0.101:3080):
The LAN access toggle in Settings → General, showing the address other devices can open:
How it works
| Half | File | Role |
|---|---|---|
| Host | src/index.ts | Registers the persisted lan-access settings namespace, the fenced /lan-access JSON route (GET state / POST set), the bind controller, and the lanAccess bind-host service. The webserver row's composed host expression reads that service, so every webserver (re)start — boot, toggle, or a post-boot user-patch re-apply — converges to the persisted setting; the controller only restarts the row when the bind actually differs. |
| Client | src/client/ | Registers the General-settings row (settings.general.item, order 15) with a native checkbox switch, the LAN URLs (primary first, all live NIC addresses shown, copy button), zh/en copy, and restart-tolerant polling. |
The route fence accepts loopback or the deployment's trusted authorities, read live from the connection row's resolved config — the same boundary the /api gateway uses. Cross-site requests are refused.
Install from GitHub
The built artifacts (lib/) are committed, so installation needs no build step and no modification of the DeepSeek Harness checkout:
# From GitHub (replace <owner>/<repo>)
dsh plugin --profile web add git+https://github.com/<owner>/<repo>.git
# ...or clone and install the local checkout (link: keeps your rebuilds live)
git clone https://github.com/<owner>/<repo>.git
dsh plugin --profile web add link:/path/to/dsh-lan-access
# Restart the GUI
dsh webThe install appends dsh-lan-access to dsh.profile.bundles; its dsh.bundle.patch inserts the host row and overrides the webserver row's host with the lanAccess service expression. The client half is picked up by the client-modules scanner automatically. No harness change is required for the core feature — the toggle, the LAN bind, and the live /api trust fence all ship inside the plugin.
> Local development — rebuild with pnpm build (or npm run build) > after changing src/, then reinstall/restart. The repo's node_modules > mirrors the DSH profile's package farm (TypeScript/tsdown come from the > harness checkout).
> Migrating from a manual patch — remove any webserver host: 0.0.0.0 > override from the profile's cordis.patch.yml (and the bundle patch layers) > so the plugin is the single owner of the bind host.
Use
1. Open the GUI, go to Settings (sidebar footer) → General. 2. Flip 局域网访问 / LAN access. - Enabling shows the ONE address other devices can open — the IPv4 of the interface that owns the default route (http://192.168.x.x:3080) — with a copy button. - The web server restarts to rebind; the row waits for it and re-reads the state (a network error mid-restart is not reported as failure). - The plugin also installs a crypto.randomUUID polyfill on plain-HTTP LAN origins (that Web API only exists in secure contexts, and the DSH API client mints every RPC id with it — without the polyfill a remote browser fails with "crypto.randomUUID is not a function"). 3. The choice is persisted in ~/.dsh/settings.yaml:
``yaml lan-access: enabled: true ``
Remote Settings pages and workspace — no harness change needed
Everything the plugin serves works from a LAN browser with zero modification of the DSH checkout:
- **The /api gateway pins the configuration plane (
settings.*,
credentials.*) to loopback.** The plugin mirrors those domains on its own fenced route (/lan-access/rpc) — same exposure boundary (model providers + web/product namespaces), redacted values, revision-fenced writes, same error codes — and the browser bundle routes the shared api.settings.* / api.credentials.* calls through it. The Models page provider directory, the Plugins configuration cards, and the Language/Appearance rows therefore work remotely.
- **The client
settingsScopedegrades to memory mode on non-loopback
origins** (surfaces render empty). The browser bundle widens connection.isLoopback to "loopback OR served LAN authority" at runtime. The client entry is inject-less and marked dsh.client.immediately, so its bundle is prefetched and its apply runs in the first boot wave — before any settings surface bundle finishes fetching — guaranteeing the patch is in place before the Plugins cards, Models page, and preference rows bind their scopes. (Without that ordering, a surface that binds early sees the unpatched isLoopback and its scope stays memory-mode: the plugin configuration cards render nothing.)
crypto.randomUUIDdoes not exist on plain-HTTP LAN origins. The
bundle installs a getRandomValues-based polyfill (same CSPRNG).
Remaining loopback-only (hardcoded in the harness, not patchable from a plugin): host.pickDirectory / host.openPath (native dialogs and host file opens) and llm.discoverModels (the Models page "discover" button). The workspace's own add/browse flow does not need them, and chat file opens route into the sidebar editor.
Debug aids
The host exposes GET /lan-access/diag (fenced like the other routes) with the latest browser boot reports: slot-registration counts, whether the connection patch is active, and a settingsScope probe bound to the shell namespace (status ready proves the host-mode + proxy path works end to end). During the first minute after boot the browser also posts a 2-second poll of the Plugins cards' own injected snapshots (available flags), the slot ledger view, and the declared spec — the exact data that separates "cards gone", "cards abdicated", and "cards present but rendering null" when a Settings page misbehaves on a remote machine.
Optional: dsh-better-sidebar compatibility patch
dsh-better-sidebar's trust fence matched the connection row by the wrong name and read the raw !!js config, so its panels (explorer / editor / terminal / git) only ever accepted loopback. The repo ships the fix as a profile-level pnpm patch (no harness change):
./scripts/install-patches.sh webThis copies patches/dsh-better-sidebar.patch into the profile's patches/ directory, registers it under patchedDependencies in pnpm-workspace.yaml, and runs pnpm install.
Security notes
- Default is off (loopback). The DSH launcher itself refuses
--host 0.0.0.0 for the same reason: binding all interfaces exposes the agent's tools to the network. Only enable it on a trusted network.
- The toggle is only reachable through the fenced route, and disabling from a
remote machine cuts that machine off (expected — re-enable locally).
- The bind survives plugin reloads and patch re-applies; a full process
restart re-applies the persisted value at boot.
Development
pnpm build # tsdown: lib/index.js (host) + lib/client.js (browser bundle)
pnpm typecheck # tsc --noEmitThe client bundle is a __ModuleLoader__.load closure-factory artifact (same format as the DSH monorepo's tsdown client preset); only the frozen platform-module table words stay external. After changing client code, rebuild and restart dsh web (the client-modules package metadata cache expires only on restart).