After DSH Added Browser Tokens, I Tested 7 Remote Access Approaches

Someone recently asked me a fair question: if DeepSeek Harness already has a native interface, why would anyone need KeySync?

If DSH only runs on the computer in front of you, the answer is simple: use native DSH. There is no reason to add a remote layer for a problem you do not have.

KeySync is for a different situation. DSH is running on a home computer, a work machine, or a headless Linux server, and you want to continue using the complete DSH interface from a phone or another computer.

That used to sound like a port-forwarding problem. With the new DSH browser-token flow, however, making port 3080 reachable is no longer enough.

Rather than compare feature lists subjectively, I defined one acceptance set for a regular user and evaluated seven remote-access approaches against it: SSH, Tailscale plus a gateway, reverse-proxy plugins, dedicated mobile projects, a P2P-oriented DSH transport, and KeySync.

The result is clear for this target: KeySync currently offers the most complete combination of low setup effort, the full native DSH UI, no public inbound port, end-to-end confidentiality, and tested support for the new DSH browser-auth flow.

It does not win every possible category. It wins the combination that matters to a regular user who wants to open a remote DSH safely and get back to work.

Define the user before defining “best”

This comparison targets someone who:

• may run DSH on a Linux server with no graphical desktop;
• wants to continue a task from a phone or another computer;
• does not want to configure SSH tunnels, VPNs, frp, DNS, certificates, or reverse proxies;
• wants the complete DSH Web UI, not a partial reimplementation;
• will not expose an agent control plane that can read files and execute tools directly to the public Internet.

I turned those needs into nine checks:

1. Networking knowledge: no need to understand port forwarding, NAT, VPN policy, reverse proxies, or certificates.
2. Headless Linux: the host can run without a desktop environment.
3. Access device: a normal browser is sufficient on a phone or computer.
4. UI fidelity: the remote interface is the complete native DSH Web UI.
5. Public exposure: the host opens no public inbound DSH or proxy port.
6. Content confidentiality: a relay or cloud service cannot decrypt DSH pages, prompts, responses, cookies, or files.
7. Authentication integrity: the solution preserves DSH's own token/cookie boundary instead of replacing it with an outer login page.
8. Current compatibility evidence: the project has a version statement, implementation path, or real test for the 0.1.2-alpha line.
9. Ongoing operations: certificates, reconnection, device revocation, launch URLs, and version changes are handled by the product.

Direct P2P is intentionally not a hard requirement. P2P is a route, not a security outcome. A regular user ultimately cares whether the connection is dependable, whether the relay can read the content, and how much infrastructure must be maintained.

The new browser token raises the compatibility bar

As of September 1, 2026, the npm latest tag for @deepseek-ai/dsh is 0.1.1-rc.2, while the alpha tag is 0.1.2-alpha.3. The browser-auth change discussed here belongs to the 0.1.2-alpha line.

According to the official DSH connection documentation, the new flow works roughly like this:

1. DSH creates a random launch token on startup.
2. dsh web prints a loopback URL containing ?token=....
3. The browser may exchange that token only at the root path for a signed cookie.
4. Every later Host RPC and WebSocket stream requires a valid browser session.
5. The cookie is bound to the normalized hostname and port and uses HttpOnly and SameSite=Strict.
6. Host, Origin, and Sec-Fetch-Site checks remain, but they do not replace identity authentication.

This is a sensible security improvement. DSH Web can start agents, read and write workspaces, and invoke tools. It is a code-execution control plane, not a read-only dashboard.

It also means a remote solution must now complete three layers: network reachability, remote-user authorization, and DSH's own browser session. Solving only the first layer is no longer sufficient.

Round one: can a regular user actually operate it?

Approach	No networking expertise	Headless Linux	Normal browser	Complete native UI	No public inbound port
SSH local forwarding	No	Yes	Yes	Yes	Partial: an SSH entry point is usually required
Tailscale + DSH-aware gateway	Partial	Yes	Partial: access devices normally join the tailnet	Depends on the gateway	Yes
Reverse-proxy / frp plugins	No	Yes	Yes	Yes	Depends on deployment
DSH Remote	Partial	Yes	WebUI or Android	Partial: dedicated control UI	Yes with LAN/Tailscale
DSH Mobile Suite	Partial	Yes	Web/mobile client	Partial: mobile-oriented experience	Yes
ds-harness-remote	Partial	Yes	No: paired client required	Strong on Desktop; dedicated Android UI	Yes
KeySync	Yes	Yes	Yes	Yes	Yes

SSH remains reliable, but the user must know how to reach the server, establish and keep an ssh -L tunnel alive, and obtain the launch-token URL produced by DSH.

Tailscale is an excellent encrypted network, but it does not automatically turn a remote 127.0.0.1:3080 listener into a DSH-compatible browser endpoint. A gateway must still bridge loopback and correctly handle DSH authentication.

Dedicated mobile projects make a different tradeoff. They reimplement approvals, questions, files, notifications, or session views for a phone. That can be better for rapid mobile intervention, but it is not the same outcome as opening the complete native DSH interface in any browser.

The KeySync path is closer to ordinary software:

1. Install and sign in to KeySync on the machine running DSH.
2. Sign in with the same account from another computer or a phone browser.
3. Select the online device and choose Open remotely.
4. Continue in the complete DSH Web UI.

The user does not need to know which port DSH uses or configure a public IP, router, VPN, frp server, DNS record, or TLS certificate. A Linux CLI build covers servers without a graphical desktop, while the access device needs only a browser.

Round two: does security and current compatibility hold up?

Approach	End-to-end network confidentiality	Preserves DSH auth boundary	0.1.2-alpha evidence	Certificate/reconnect/version maintenance
SSH local forwarding	Yes	Yes in principle	Yes in principle	User-managed tunnel and launch URL
Tailscale + gateway	Yes at the network layer	Depends on gateway	Depends on gateway	User maintains network and gateway
Reverse-proxy / frp plugins	Depends where TLS terminates	Current inspected versions do not	No public evidence in inspected versions	User maintains proxy, certificate, and plugin
DSH Remote	Depends on LAN/Tailscale setup	Uses its own gateway model	No explicit alpha statement found	Plugin and client maintenance required
DSH Mobile Suite	Application-layer E2EE	Uses a plugin path	Public baseline is 0.1.0-rc.6	Companion, relay, and client required
ds-harness-remote	Noise IK E2EE	Uses DSH Remote/API transport	Explicit alpha.1-alpha.2 support	Plugin, paired client, and matching transport generation
KeySync	Browser-to-device TLS	KeySync and DSH sessions coexist	Alpha.2 acceptance completed	Client-managed

SSH and Tailscale are secure foundations, not zero-configuration DSH products

OpenSSH -L forwards a local listener through an encrypted SSH channel to a host and port on the remote side. For one developer who already maintains SSH keys and server access, it is hard to beat.

Tailscale uses WireGuard end-to-end encryption. Even when traffic uses a DERP relay, the relay sees encrypted WireGuard traffic. Grants and ACLs add strong device and organization policy.

Neither one completes the DSH application layer. With Tailscale in particular, DSH remains bound to loopback. A gateway still has to handle the launch token, cookies, Host, Origin, WebSocket traffic, and future DSH changes.

Their weakness here is not cryptography. It is the technical and operational work required to finish the user's actual task.

Generic proxy plugins expose the new compatibility gap

I inspected the current implementations of two public proxy plugins.

dsh-plugin-remote@0.5.12 includes scrypt credentials, an HttpOnly session cookie, allowlists, and HTTP/WebSocket proxying. Its current proxy path, however, removes browser cookies before upstream forwarding and rewrites Host/Origin. It does not read the DSH launch-token URL.

@xiaosenho/dsh-plugin-remote-access@0.1.4 offers LAN and frpc modes. Its outer access token becomes an HttpOnly, SameSite=Strict cookie, but its proxy implementation also deletes upstream cookies and has no alpha launch-token bootstrap path.

The precise conclusion is limited to those versions: they provide no public evidence for the 0.1.2-alpha browser-auth flow, and their current proxy logic cannot complete it. They may remain useful on rc.2 and can be updated in the future. The important lesson is that an outer login page and a successful HTTP 200 do not prove that DSH RPC and WebSocket sessions work.

Dedicated clients are strong, but optimize a different outcome

DSH Remote provides Android/WebUI access, device keys, approvals, questions, files, and offline history. It behaves more like a purpose-built mobile agent console. That can be valuable, but it is not a transparent copy of the full DSH Web UI. Its public README does not currently make an explicit 0.1.2-alpha compatibility claim.

DSH Mobile Suite uses an outbound Companion-to-Relay connection and documents an application-layer E2EE design. Its security documentation also identifies a real browser boundary: JavaScript served by the relay-hosted web application is still a trusted endpoint, so E2EE cannot protect against a malicious deployment replacing that code. Its plugin compatibility statement currently says it was tested with @deepseek-ai/dsh@0.1.0-rc.6.

ds-harness-remote@0.4.2 is the most technically distinctive direct competitor in this set. It integrates with DSH communication transports rather than proxying the browser page. It documents legacy ApiProxy support for rc.2 and Typert Remote Gateway support for alpha.1 through alpha.2. Its Noise IK data path negotiates LAN, P2P, TURN, and WebSocket Relay routes.

That is attractive when direct-connect preference or a dedicated Android experience is the priority. The tradeoff is that the host and access side need paired components, and both Desktop ends must use the same DSH transport generation. It solves “connect a dedicated client to remote DSH.” KeySync solves “open the complete DSH in any normal browser.”

Why KeySync passes the complete acceptance set

KeySync is not merely another reverse proxy in front of a public port. It separates user authorization, encrypted transport, and DSH authentication into distinct boundaries.

1. User and device authorization

Only an authenticated owner can select an online device. Each remote open operation creates a short-lived, single-use grant scoped to the user and device. After device-side verification, the Gateway creates an HttpOnly, Secure, SameSite=Strict remote session.

Cross-user access, expired grants, replayed grants, and wrong-device claims fail closed. This layer answers: who is allowed to reach this device?

2. End-to-end TLS from browser to device

The DSH host creates a certificate private key and CSR locally. The private key remains on that device. The remote browser's HTTPS connection passes through KeySync Relay, but TLS terminates at the Gateway running on the user's device.

The Relay can route connections, enforce limits, and observe connection metadata. It cannot decrypt DSH HTML, prompts, model responses, cookies, or attachments.

KeySync's release acceptance matrix covers SNI routing, TLS byte passthrough, slow-stream isolation, flow limits, reconnects, and authenticated same-device process takeover.

This is relay-assisted end-to-end TLS, not direct network P2P. The topology includes Relay, while the plaintext endpoints remain the browser and the user's device.

For a regular user, that is a practical tradeoff. Direct P2P may lower latency and relay cost, but NAT, firewalls, and network changes often require TURN or relay fallback. KeySync chooses a consistently reachable relay path while TLS passthrough preserves the property that the relay cannot read the content.

3. DSH's launch token is preserved, not bypassed

For 0.1.2-alpha.2, KeySync captures the loopback launch-token URL from DSH startup output, validates its host and port, and redacts the token from logs.

On the first authenticated browser request to the root path, the device Gateway forwards the request to the DSH token URL. DSH performs its normal exchange and creates its authority-bound cookie. Later HTTP and WebSocket requests keep the DSH cookie. The KeySync remote-session cookie is stripped before upstream forwarding, and the DSH launch token is not replayed after the DSH session exists.

The two authentication layers therefore have separate jobs:

• KeySync decides who may connect to the device.
• DSH decides whether this browser owns a valid DSH session.

This is more work than placing one password page in front of a proxy, but it preserves the security boundary DSH intentionally added.

4. The product manages more than a tunnel

Users maintain an entire workflow, not just a TCP port. KeySync brings these pieces into one entry point:

• install or detect DSH on Windows, macOS, and Linux;
• configure a model service and start DSH;
• capture the correct access URL produced by the installed DSH version;
• show device, DSH, and tunnel status;
• manage device identity, certificates, routes, and reconnects;
• open remote DSH from another KeySync Client or any phone browser;
• preserve the complete DSH page, streaming responses, WebSocket traffic, and attachments.

SSH, Tailscale, frp, and reverse proxies can each be part of a working system. KeySync's advantage is that a regular user does not have to assemble and maintain that system.

Conclusion

There is no reason to add a remote layer when DSH is used only on the local machine.

For a developer who already operates SSH and needs occasional access to one server, ssh -L remains an excellent answer.

For an organization that already runs Tailscale or Cloudflare Zero Trust and has people maintaining identity, policy, and gateways, extending that infrastructure may be the right choice.

For direct-P2P-first networking, dedicated Android interaction, or mobile approval workflows, ds-harness-remote, DSH Remote, and DSH Mobile Suite deserve serious evaluation, with close attention to the DSH versions they support.

But consider this requirement set:

• DSH runs on a home computer, work machine, or headless Linux server.
• The user is not a network engineer.
• The host exposes no public inbound port.
• Phones and other computers use only a normal browser.
• The remote interface is the complete native DSH UI.
• Relay cannot decrypt the content.
• DSH's new browser-token boundary remains intact.
• The user does not maintain tunnels, certificates, and version adapters.

For that user, KeySync is currently the most complete and practical option in this comparison.

It does not replace DSH with a new interface. It keeps native DSH safe, complete, and usable after you leave the host computer.

Try it and inspect the sources

• Download KeySync
• KeySync product page
• DeepSeek Harness repository
• DSH browser authentication and request trust

Remote access answers “where can I open DSH?” If you also want Codex or Claude Code as DSH conversation backends, we maintain two optional, separate plugins:

• Codex DSH plugin: GitHub / npm
• Claude Code DSH plugin: GitHub / npm

The plugins add conversation backends to DSH. KeySync handles installation, configuration, device management, and remote access. They are independent layers, and neither plugin is required when you do not need that backend.

---

Research date: September 1, 2026. DSH remains in Developer Preview, so versions and compatibility can change quickly. Third-party conclusions are limited to the linked versions, commits, and public materials. KeySync security and compatibility claims are based on the current implementation and release acceptance tests, not an independent third-party security audit.