DEV Community: Bobo Yang

New to Linux Operations? Install DeepSeek Harness on a Remote Host Over SSH

Bobo Yang — Thu, 03 Sep 2026 14:10:09 +0000

If you can SSH into a Linux host but do not yet know which commands are safe, a remote agent can help collect evidence on the machine itself. The important part is keeping changes behind a human approval boundary.

Disclosure: I’m affiliated with KeySync, the remote-access product used in this tutorial.

For someone new to operations, the most stressful moment after an alert may not be the red error message. It may be the first few minutes after SSH login.

You know something is wrong, but you do not know whether to inspect disk usage, processes, ports, or logs first. Search results offer dozens of commands, yet it is not obvious which ones only inspect state and which ones delete files, restart services, or modify configuration.

Copying a few log lines into a web chat does not fully solve the problem either. The AI cannot see the host’s actual environment, so it asks for another command and another fragment of output. You return to SSH and run a command you may not completely understand.

This tutorial has one narrow goal: use SSH to install the KeySync CLI and DeepSeek Harness (DSH) on an Ubuntu host. Afterward, you can find that host in KeySync, open its DSH instance remotely, ask the agent to begin with read-only checks, inspect the evidence, and decide whether any change should be made.

This workflow does not make unsafe operations impossible, and it does not replace your organization’s change-management process. It gives a new operator a more structured way to investigate before acting.

What you will have at the end

The workflow is:

Install the KeySync CLI and DeepSeek Harness over SSH.
Find the online Linux device in KeySync.
Select Remote Open to enter the DSH instance running on that host.
Describe the problem in natural language and request inspection only.
Review the commands, evidence, and conclusions.
Keep deletion, restart, upgrade, and configuration changes behind human approval.

KeySync provides the path to the selected machine. DSH performs the investigation inside that machine’s real environment.

Test environment and limits

This walkthrough was tested with:

Ubuntu 22.04.5 on x86-64
A normal SSH user, without root installation
KeySync CLI 0.1.123
Node.js 24.18.0
DeepSeek Harness 0.1.1-rc.2
About 9.7 GiB free on the root filesystem before installation

The test machine had Ubuntu Desktop components installed, but the procedure used no Linux GUI and the SSH session had no desktop environment variables. This demonstrates a CLI-only installation, not a pristine minimal Ubuntu Server image.

Do not copy the procedure unchanged to ARM64, another distribution, or a production server. Validate it in a non-production environment or ask an experienced administrator to review it first.

The commands below use Bash syntax. Run echo "$SHELL" to check your shell. If it is not Bash, ask an administrator how to switch or adapt the commands.

Know what will change before you copy a command

System, Node.js, and disk checks are read-only.
Downloading and extracting KeySync writes only to a temporary directory and the current user’s home directory.
keysync login stores login state for the current user and registers the device.
keysync service install creates a user-level systemd service, not a system service.
keysync dsh install downloads and installs DeepSeek Harness.
keysync dsh remote enable enables the Remote DSH channel for this device.

This tutorial does not ask you to run sudo rm, docker system prune, format a disk, or modify production configuration. If your output differs from the examples, stop instead of trying more commands at random.

Step 1: Perform read-only preflight checks

These commands do not modify the system:

uname -m
. /etc/os-release && printf '%s %s\n' "$NAME" "$VERSION_ID"
node --version
df -h /

They answer four questions: Is the machine x86-64? Which Linux distribution is running? Which Node.js does the current shell use? How much space remains on the root filesystem?

My test host returned:

x86_64
Ubuntu 22.04
v12.22.9
about 9.7 GiB free on /

The first real issue appeared immediately: Node.js 12 could not run the current KeySync CLI. The current Linux CLI requires Node.js 24 or newer on PATH.

The test host already had Node.js 24.18.0 in NVM, so I selected it:

export PATH="$HOME/.nvm/versions/node/v24.18.0/bin:$HOME/.local/bin:$PATH"
node --version
# v24.18.0

That NVM path belongs to this test host; it is not a universal location. If node --version already reports 24 or newer, do not add it. If Node.js is installed elsewhere, use the real path on your host.

If the version is still below 24, stop here. Do not run a blind apt upgrade just to continue the tutorial. Use your organization’s approved Node.js installation method or ask an administrator to install Node.js 24.

Step 2: Download the KeySync CLI

On September 3, 2026, the current Linux x64 release was 0.1.123:

tmp_dir=$(mktemp -d /tmp/keysync-install.XXXXXX)
curl -fsSL \
  'https://keysync.sublang.ai/keysync-updates/cli-linux-x64/keysync-cli-0.1.123-linux-x64.tar.gz' \
  -o "$tmp_dir/keysync.tar.gz"
stat -c '%s bytes' "$tmp_dir/keysync.tar.gz"

The tested file size was:

33124893 bytes

If curl fails or the size differs, do not extract the archive. Read the current public release manifest instead of guessing a download URL:

https://keysync.sublang.ai/keysync-updates/latest.json

Step 3: Verify the archive

SHA-512 is the archive’s digital fingerprint. The calculated value must match the value in the release manifest.

expected='IdEI49Z7d4rtyFwE6XqMCapDBSo9Us2PwAg+ocK2Mkchu4wrVcF/ExaMzFzfEu5OvcOK4Nu3d3xMl6O3knhJpQ=='
actual=$(node -e "const fs=require('fs'),c=require('crypto');const p=process.argv[1];console.log(c.createHash('sha512').update(fs.readFileSync(p)).digest('base64'))" "$tmp_dir/keysync.tar.gz")
test "$actual" = "$expected" && echo 'SHA-512 OK' || echo 'Verification failed; stop the installation'

Continue only after seeing:

SHA-512 OK

If verification fails, do not edit expected to force a match. Confirm that the version, URL, and digest came from the same current manifest entry.

Step 4: Install into your home directory

These commands create files under the current user’s home directory and do not overwrite /usr/bin:

mkdir -p "$HOME/.local/share/keysync/cli" "$HOME/.local/bin"
tar -xzf "$tmp_dir/keysync.tar.gz" -C "$HOME/.local/share/keysync/cli"
ln -s \
  "$HOME/.local/share/keysync/cli/keysync-cli-0.1.123-linux-x64/keysync" \
  "$HOME/.local/bin/keysync"
export PATH="$HOME/.nvm/versions/node/v24.18.0/bin:$HOME/.local/bin:$PATH"
keysync --version

Expected output:

0.1.123

If ln reports that the destination already exists, the machine may already have KeySync installed. Inspect it instead of overwriting it:

ls -l "$HOME/.local/bin/keysync"
keysync --version

Step 5: Log in without writing passwords into shell history

Do not place your real email address and passwords directly in command-line arguments. They may remain in shell history. The CLI can read them from environment variables populated through hidden prompts:

read -rp 'KeySync email: ' KEYSYNC_EMAIL
read -srp 'KeySync login password: ' KEYSYNC_PASSWORD; echo
read -srp 'KeySync Vault password: ' KEYSYNC_VAULT_PASSWORD; echo
export KEYSYNC_EMAIL KEYSYNC_PASSWORD KEYSYNC_VAULT_PASSWORD
keysync login
unset KEYSYNC_EMAIL KEYSYNC_PASSWORD KEYSYNC_VAULT_PASSWORD
keysync status

Run this only in your own private SSH session. If login fails, clear the variables with the unset command before checking the account, password, and network.

Step 6: Run KeySync as a user-level systemd service

keysync service install
keysync service status
systemctl --user is-enabled keysync.service
systemctl --user is-active keysync.service

The tested result was:

enabled
active

No sudo is used here. If someone suggests adding it after an unexpected error, stop and determine why first.

If the installer reports user lingering is disabled, the service may run only while that user has an active login session. It may not be online after a reboot before the user logs in. Do not enable linger or add sudo without approval; ask an administrator to apply the organization’s policy, then test again after logging out or rebooting the test host.

Step 7: Install DeepSeek Harness

keysync dsh install
keysync dsh start
keysync dsh remote enable
keysync dsh status

A clean reinstall took about 118 seconds in this test. A quiet period does not necessarily mean failure, so do not start a second concurrent installation.

The successful state was:

DeepSeek Harness: running
Version: 0.1.1-rc.2
Remote access: connected

On the test host, DSH listened only on 127.0.0.1:3080; port 3080 was not exposed on every network interface.

If you do not plan to use remote access yet, omit keysync dsh remote enable and enable it later.

Step 8: Open the host and send a safe first instruction

On another computer, open KeySync, select the online Linux host, and choose Remote Open next to DeepSeek Harness.

Do not begin with “fix it.” Start with an explicit diagnostic boundary:

Perform read-only checks only. Do not delete or move files, install or upgrade software, modify configuration, terminate processes, or start, stop, or restart services. First explain what you plan to inspect. Then run only the read-only commands required. Finally, list every command executed, the important output, the evidence behind your conclusion, remaining uncertainty, and any next action that requires my approval.

I used a similar instruction to investigate a Node.js version problem. DSH checked Node.js, PATH, and the launcher on the target host, reproduced the syntax error under Node.js 12, and verified that the same CLI worked under Node.js 24.

Natural-language “read-only” instructions are not an operating-system sandbox. Important production systems still need low-privilege accounts, restricted sudo, and explicit approval for deletion, restart, and configuration changes.

Common failure modes

`keysync: command not found`

Make sure the current shell includes the installation directory:

export PATH="$HOME/.nvm/versions/node/v24.18.0/bin:$HOME/.local/bin:$PATH"
keysync --version

`SyntaxError: Unexpected token '.'`

The test host produced this when it was still using Node.js 12:

which node
node --version

Verify the executable actually selected by the shell, not merely that Node.js 24 exists somewhere on the machine.

`Could not resolve host`

Confirm that the URL comes from the current latest.json, then inspect DNS. Do not disable certificate checking or use an untrusted mirror.

`Remote access: disabled`

If you intend to enable remote access:

keysync dsh remote enable
keysync dsh status

The state may briefly show reconnecting before becoming connected.

The installer is quiet for a long time

The tested reinstall took about 118 seconds. First wait and confirm that only one installation process is running. If it exceeds a reasonable time, save the error information and ask a colleague or an AI assistant to help interpret it.

Final verification

Run:

keysync --version
systemctl --user is-active keysync.service
keysync dsh status
ss -ltnp | grep '127.0.0.1:3080'

Then verify all four outcomes:

KeySync returns an explicit version.
The user-level service is active.
DSH is running and Remote is connected.
You can open the real DSH instance from KeySync and complete one read-only investigation.

What you now have is not an AI that should be allowed to change a server freely. It is a diagnostic partner that can remain on the target Linux host and collect evidence continuously.

For a new operator, the goal is not merely to memorize fewer commands. It is to know how to inspect first, when to stop, and which decisions must remain with a human.

Try the workflow

Download KeySync to connect a Linux device and remotely open its DSH instance.
Visit the DeepSeek Harness website for the official introduction, installation instructions, and open-source project.

Version note: tested on September 3, 2026. KeySync and DeepSeek Harness evolve quickly, so read the current public release manifest before installation. This tutorial is for learning and non-production validation; it does not replace your organization’s access-control or change-management procedures.

Stop Copying Linux Logs Into AI—Let the Agent Investigate on the Failing Machine

Bobo Yang — Thu, 03 Sep 2026 09:09:12 +0000

A production release was blocked by a nearly full disk. The useful part of the AI workflow was not a clever command—it was keeping the investigation on the affected host while preserving a human approval boundary.

Disclosure: I’m affiliated with KeySync, the remote-access product used in this incident.

At 4:09 p.m. on August 31, I triggered the production release for version 0.1.115.

Builds started for macOS, Windows, Linux x64, Linux ARM64, and the standalone CLI. Installation, startup, signing, and notarization checks passed one after another.

Thirty-nine minutes later, all five build groups had succeeded.

But the release did not continue.

The final CI gate failed:

The server has only 6.5 GiB free. A safe release requires 17.4 GiB.

Every candidate artifact had passed validation, yet production was blocked by a disk that was almost full.

The most dangerous response was not moving slowly. It was moving too quickly.

Deleting an old-looking directory might recover enough space, or it might remove a live database, a model, or the rollback package we would need ten minutes later. Expanding the disk would be easy, but if a retention job had silently stopped working, more capacity would only postpone the next incident.

I needed three answers:

What was actually consuming the space?
Which data was safe to remove, and which data was still in use?
Was this a one-time capacity problem, or was a process continuously generating garbage?

Two clicks from a failed CI gate to the affected server

I did not start by looking up an IP address or searching for an SSH configuration and key.

The production Linux server was already connected to KeySync. I opened the device list, selected the server, and clicked Remote Open. DeepSeek Harness (DSH), which was installed on that host, opened in the browser.

The same production Linux host, online with DSH installed and available to open remotely.

From the failed CI gate to the correct production server, the only decisions were selecting the device and opening its DSH instance.

KeySync handled the first part of remote diagnosis: getting the agent to the correct machine. DSH handled the second part: continuing the investigation once it was there.

The copy-and-paste version would have taken at least six round trips

In the usual workflow, I would log in, run df, and paste the output into an AI chat.

The AI would ask for du, so I would run that and paste another result. Once Docker and KeySync appeared near the top, the next requests would be container state, mounted volumes, directory details, historical files, and the cleanup scripts.

The investigation would look like this:

run df -> copy output -> wait for an answer
run du -> copy output -> wait for an answer
inspect Docker -> copy output -> wait for an answer
expand large directories -> copy output -> wait for an answer
read cleanup scripts -> copy output -> wait for an answer
run validation -> copy the result again

It looks like the human is investigating. In practice, the human is acting as a remote keyboard for the AI.

Because DSH was running on the target host, it could inspect the disk, directories, processes, containers, and scripts within the permissions I granted.

My first instruction was deliberately not “clean this up.” It was:

Perform a read-only investigation only. Do not delete anything, restart services, or modify configuration. First determine why the disk is full. Separate live data, recoverable duplicates, and backups that must not be removed. Then decide whether the right answer is cleanup or expansion.

I did not prescribe a sequence of commands. I stated the objective and the boundaries. The agent chose each next command from the result of the previous one.

One objective, a continuous investigation

DSH first used df to verify that this was not a false CI alert: the root filesystem was genuinely at 98%.

It then continued narrowing the scope:

df confirms the root filesystem is at 98%
  -> du narrows the problem to KeySync and Docker
  -> container and volume inspection rules out blind Docker cleanup
  -> KeySync directories reveal 77.85 GiB of staged uploads
  -> historical version directories show abnormal retention
  -> the release cleanup script is inspected
  -> real directory names are compared with the matching rule
  -> a one-character mismatch is found

The time saving did not come from typing fewer commands. It came from keeping the investigative context intact. The agent could see the last result and immediately test the next hypothesis.

The first branch: do not prune Docker

This Ubuntu production server had been running for more than a year. It hosted KeySync, databases, object storage, monitoring, internal services, and several containerized applications.

Docker had 37 containers, and every one of them was running. Some test environments had been alive for ten months.

So “Docker is large” was not enough evidence to run docker system prune.

After checking mounts and volumes, DSH found that the largest volumes were still attached to services. There were no stopped containers that could be reclaimed safely. System logs were not the main consumer, and inode exhaustion was not the problem.

The important disk consumers were:

Major consumer	Usage at the time
KeySync upload staging	77.85 GiB
Docker data, images, and containers	57.08 GiB
KeySync public downloads	34.42 GiB
KeySync release and candidate archives	33.96 GiB
KeySync backups	18.50 GiB
Ollama models	16.82 GiB

The disk had a total capacity of 294.9 GiB, with 276.3 GiB used. The system reported 98% usage and only about 6.4 GiB available to a normal process.

The first conclusion was clear: immediate expansion was unnecessary, and active Docker or database data should not be touched. The 77.85 GiB upload-staging directory deserved the next investigation.

A nearly invisible error in the retention rule

If I had pasted only the du output into a chat, the AI could have told me that the directory was large.

But DSH was still on the machine. It could follow the evidence from the large directory to its file structure, and from the file structure to the release script responsible for cleaning it.

Production upload directories were named like this:

client-0.1.113
client-0.1.114
client-0.1.115

The cleanup rule matched this instead:

client-v*

The configuration said to keep only the newest two versions, and the cleanup script completed without an error. But it never matched the real directories.

No alert fired. No red status appeared. Fifteen upload sets accumulated over time.

There was a second problem: the public-download cleanup script scanned only the top level. Old installers under the Windows, macOS, and Linux subdirectories were never considered.

All the tests had passed. The test fixtures used names such as client-v..., exactly matching the incorrect rule, and never represented the real client-... production convention.

One letter—v—turned “keep the latest two” into “never clean anything.”

Finding deletable data did not mean deleting it

DSH remained inside the read-only boundary after identifying the likely cause.

It selected three upload directories for which complete release copies already existed elsewhere, then calculated hashes for the files in both locations. All 5,487 files matched.

Only then did it recommend a concrete action:

Delete only the three verified duplicate upload directories. Expected recovery: approximately 15.4 GiB. Release artifacts, databases, and backups are outside the scope of this operation.

This distinction matters. Allowing an agent to enter a production server is not the same as allowing it to delete production data.

The investigation could proceed continuously. Destructive action still required a human decision about scope and consequences.

After I approved that exact scope, the cleanup removed only those three duplicate directories.

Available space increased from 6.41 GiB to 21.84 GiB. The other 39,392 protected files, 11 business-configuration tables, database backups, and deployed versions were unchanged.

At 5:22 p.m., free space exceeded the 17.40 GiB release budget and CI resumed. Ten minutes later, eight classes of downloadable packages, six platform-update configurations, and 24 web files passed validation. Version 0.1.115 went live.

A green release did not end the investigation

Recovering 15.4 GiB solved the immediate release failure, but it did not answer why retention had failed or whether the directory would keep growing.

In the same DSH conversation, I asked a follow-up:

Why is KeySync using so much disk space? Find the process that will cause it to continue growing.

The conversation still had the server’s directory layout, container state, release paths, and scripts in context. There was no need to reconstruct the incident in a new chat.

Using the real production naming convention, DSH reproduced the bug: with four upload directories present and retention set to two, the script deleted none of them.

It also found nine independent copies of the same Windows portable package across three release locations. Their hashes were identical, and together they consumed 1.62 GiB.

The real problem was not an undersized disk. Release files were duplicated, and the automatic cleanup rules did not cover the names and directory structure used in production.

A one-line fix required much more than a one-line safety process

The matching rule needed a one-line change. Production remediation required much more:

Add ten focused tests covering old and new naming conventions, retention counts, protection of the current version, unrelated directories, and symbolic links.
Check 20,083 files in eleven historical upload sets.
Create recoverable deduplicated backups for 1,512 files whose contents were not duplicated elsewhere.
Preserve approximately 7.89 GiB of unique data.
Limit the operation to upload staging instead of opportunistically cleaning public downloads, Docker, databases, or model files.

After the rule passed its tests and the recovery data was verified, I approved the final execution scope.

Eleven historical upload sets were removed, leaving only the two newest. The operation recovered 48.46 GiB, bringing sampled free space to approximately 63.19 GiB.

DSH then verified the current downloads, update feeds, web files, and business configuration on the same host. Protected files were unchanged except for the expected hard-link differences.

The result was a complete operational chain:

detect the anomaly -> rule out unsafe shortcuts -> locate the root cause -> control risk -> wait for authorization -> execute -> verify

Space the agent correctly refused to reclaim

The investigation also found several running containers with names beginning with test-. Some had been running for about ten months, alongside even older testing and tooling services.

That exposed a separate lifecycle problem: temporary deployments had gradually become part of a production server without a consistent retirement process.

But old does not mean safe to delete.

The containers were running, and some of their volumes contained real data. DSH classified them as systems requiring owner review, not as immediately reclaimable garbage.

Each service needs its dependencies, data value, and shutdown window confirmed before migration, archival, or deletion. Otherwise, an attempt to improve a disk-usage number simply trades a capacity risk for data loss.

Where remote agents are useful—and where authority should stop

If I already know the exact command I need, SSH remains simple and reliable.

The strongest case for a remote agent is the unknown phase of an incident: a Linux host is unhealthy, but nobody yet knows whether to start with logs, storage, containers, processes, configuration, or source code.

In this workflow, KeySync answers “how does the agent reach the correct machine?” DSH answers “once it is there, how does it continue the investigation?”

The convenience is that I do not need a separate remote-operation setup for every Linux host. The intelligence is that the agent does not wait passively for the next copied fragment of evidence.

The safety model is equally important:

Start with a read-only objective and explicit prohibitions.
Let the agent choose investigative commands based on evidence.
Keep deletion, restarts, and configuration changes behind human approval.
Define exact targets and expected effects before approval.
Verify protected data and service health after execution.

My view is that agents operating directly on remote hosts will become an increasingly common part of operations work. The concern is equally obvious: a single incorrect command on a production system can cause an outage or irreversible data loss.

Would you allow an AI agent to investigate or maintain production systems remotely? What safeguards would you require—read-only credentials, restricted shells, sudoers policies, command allowlists, sandboxes, approval gateways, snapshots, or something else?

Try the workflow

Download KeySync to connect a Linux device and remotely open its DSH instance.
Visit the DeepSeek Harness website for the official introduction, installation instructions, and open-source project.

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

Bobo Yang — Tue, 01 Sep 2026 14:03:23 +0000

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:

Networking knowledge: no need to understand port forwarding, NAT, VPN policy, reverse proxies, or certificates.
Headless Linux: the host can run without a desktop environment.
Access device: a normal browser is sufficient on a phone or computer.
UI fidelity: the remote interface is the complete native DSH Web UI.
Public exposure: the host opens no public inbound DSH or proxy port.
Content confidentiality: a relay or cloud service cannot decrypt DSH pages, prompts, responses, cookies, or files.
Authentication integrity: the solution preserves DSH's own token/cookie boundary instead of replacing it with an outer login page.
Current compatibility evidence: the project has a version statement, implementation path, or real test for the 0.1.2-alpha line.
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:

DSH creates a random launch token on startup.
dsh web prints a loopback URL containing ?token=....
The browser may exchange that token only at the root path for a signed cookie.
Every later Host RPC and WebSocket stream requires a valid browser session.
The cookie is bound to the normalized hostname and port and uses HttpOnly and SameSite=Strict.
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:

Install and sign in to KeySync on the machine running DSH.
Sign in with the same account from another computer or a phone browser.
Select the online device and choose Open remotely.
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

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.

Why I still wanted a DSH Codex plugin when the native Codex app is already good

Bobo Yang — Tue, 01 Sep 2026 09:29:26 +0000

A few people have asked a fair question:

If the native Codex desktop experience is already good, why build a DSH Codex plugin?

My answer is simple: if I only work on my own machine, in front of my own desktop, I would use the native Codex app too.

The DSH Codex plugin is not trying to prove that the native app is bad. It solves a different problem: remote access and headless/server-side agent workspaces.

The real problem: agent work is not always tied to one desktop

Many agent tasks are no longer just one prompt and one answer.

In practice, I often want to:

start a coding task on one machine;
leave that machine but still check progress from another device;
run work inside a remote Linux project environment;
keep using a conversation-style workbench instead of only a terminal;
open the same agent workspace through a browser.

The native desktop experience is excellent when I am sitting in front of that machine.

But once I want to open the same workspace remotely, or work with a server that has no desktop environment, I need another layer.

That is where KeySync + DSH becomes useful.

Reason 1: I want remote access to a running DSH workspace

KeySync provides a device entry point. From KeySync Web, I can open DeepSeek Harness running on another device through an Open remotely action.

The important part is not that this is "another chat UI".

The important part is that I can enter the agent workbench on that machine without physically sitting in front of it.

Once opened in the browser, DSH still gives me the familiar workbench shape: sessions, workspaces, mode selection, model selection, permission mode, tool feedback, and conversation history.

It feels closer to bringing the existing workbench into a remote browser than starting a separate web chat from scratch.

Reason 2: many Linux servers are SSH-only

This point needs to be phrased carefully.

I am not saying Linux desktop support does not exist. The better distinction is that many real development servers are not desktop machines.

They are often:

SSH-only;
headless;
not meant to run a long-lived GUI app;
where the project dependencies, build tools, data, and runtime live;
still places where a visual agent conversation can be helpful.

In that environment, a pure CLI workflow can be great, but it is not the same interaction model as a desktop-style agent workbench.

DSH + KeySync fills that gap: it gives me a browser-accessible conversation workspace for machines and environments where a desktop app is not the natural fit.

What role does the DSH Codex plugin play?

My mental model is:

DSH owns the workbench: sessions, workspace navigation, input, tool presentation, and side panels.
Codex owns the coding-agent capability.
The DSH Codex plugin connects the Codex-style agent backend into the DSH workbench.
KeySync provides the remote device entry point.

This is deliberately modest architecture. It is not a full IDE rewrite, and it is not trying to replace every native workflow.

It is a plugin-based way to bring coding-agent capability into a remote-friendly DSH environment.

This is not a replacement argument

I do not think the right question is "which tool replaces which?"

The better questions are:

Where is the task actually running?
Can I sit in front of that machine right now?
Does the machine have a desktop session?
Do I need terminal automation, or a conversation workbench?
Do I need to resume the same work from another device?

My current split is:

If I am doing local desktop development, the native Codex app is a great default.
If I need remote access to an agent workbench, DSH + KeySync fits better.
If I am working with an SSH-only or headless Linux server, the DSH Codex plugin gives me a more desktop-like conversation entry point.
If I only need scripted execution, CLI tools are still excellent.

Not Just a Working Demo: Why We Ran 162 Migration Tests for Two DSH Plugins

Bobo Yang — Sun, 30 Aug 2026 00:37:49 +0000

We use Codex and Claude Code to build Relay. They are also part of the routine work behind the plugin repositories: implementation, tests, review, and debugging. When we started using DeepSeek Harness (DSH) as a project entry point, we wanted that work to continue. Moving to a different interface should not mean giving up the capabilities and sessions we already rely on.

That is why we maintain two independently installable plugins for official DSH:

relay-dsh-plugin-codex (GitHub · npm) adds Codex App Server as a DSH conversation backend.
relay-dsh-plugin-claude (GitHub · npm) adds the Claude Code Agent SDK as a DSH conversation backend.

Neither plugin patches DSH core or requires a Relay checkout. After installation, Codex and Claude Code appear as conversation modes inside DSH and continue using its project, history, composer, and tool surfaces.

If the goal were only a demo, that would be enough: select a backend, send a prompt, and record the answer. We intend to use these plugins over time, so “it answered once” is not a useful acceptance standard.

We Did Not Want Users to Find the Boundaries for Us

A successful chat hides many of the failures that matter in real work.

Did the model actually receive the attached image? Can a user watch a ten-minute command make progress? Does Stop terminate the process, or only change the UI? Can a session survive a host restart? Do project Skills, MCP servers, and settings still apply? Can a secret used by a tool remain on disk even when it never appears in the visible conversation?

Those paths decide whether a plugin can become part of daily development. Because we use the plugins ourselves, we did not want to claim broad Codex or Claude support and wait for users to identify every exception.

We chose to map the boundary first. A workflow that completes is supported. A workflow that only partly completes is marked partial. A workflow that does not complete remains a failure. The purpose is not to produce a flattering score. It is to decide what to fix next and to tell users what work they can safely move.

Where the 162 Tests Came From

We split real development work into 162 atomic requirements: 76 for Codex and 86 for Claude. Every requirement has its own case, run record, and reviewed result.

The matrix covers conversation and multi-turn context, images and files, code and shell tools, tests and Git, Skills, MCP, project configuration, permissions, environment variables, session import, host restarts, and long-context continuation. These are not names collected for a checklist. They are paths we reach while using Codex and Claude Code on actual repositories.

By August 29, 2026, all 162 cases had results. We retained 167 runs in total; five were reviewed Codex reruns and do not inflate the requirement count.

Plugin	Atomic capabilities	Supported	Partial	Unsupported
`relay-dsh-plugin-codex`	76	59	6	11
`relay-dsh-plugin-claude`	86	78	3	5

The cases, run evidence, and support matrices remain in the repositories: Codex validation and Claude validation.

This table is the August 29 problem-discovery snapshot, not the current pass rate. Codex 0.1.3 and Claude 0.1.4, released the following day, fixed several of those failures. We will publish new counts after the complete 162-case suite has run again.

What the Failures Made Us Reconsider

Migration Is More Than Connecting an Interface

One test produced a result that was easy to misread. DSH stored and displayed the user's image correctly, but the actual Codex rollout contained no image input. The interface looked healthy while the model received incomplete information.

Claude exposed a related continuity gap. The plugin could create a new Session, but it did not yet have a reliable path for importing an existing native Session. Moving into DSH still meant starting over.

Those failures led us to repair Codex image transport and improve existing-session selection and import in both plugins. The point is not to add two names to a mode menu. It is to let users carry existing work forward.

A Control Must Reflect the Real State

In another case, DSH reported a Codex task as interrupted, but a child process still wrote its delayed file several seconds later. That is worse than having no Stop button because the interface gives false certainty.

We changed targeted process termination and long-command output handling. The rule is straightforward: running work should expose progress, and work reported as stopped must actually stop. If cleanup cannot be confirmed, the plugin should report a failure instead of displaying a successful cancellation.

Invisible State Needs Testing Too

A secret missing from the chat transcript can still be present on disk. Validation found persistence paths in Codex shell snapshots and Claude tool results.

Codex 0.1.3 disables persistent shell snapshots by default. Claude 0.1.4 redacts sensitive environment values before tool results enter history. These changes do not replace least-privilege configuration or prove that every third-party tool is safe. They close the paths we could reproduce.

Validation Is Part of Development, Not a Release Ceremony

The August 29 results did not end as a report. The two releases published the next day addressed failures in image transport, process interruption, long-command output, sensitive-value persistence, existing-session import, and tool routing.

This is the development loop we want to keep:

Use the plugins on real projects.
Reduce a problem to a repeatable case.
Repair the boundary between DSH and the native backend.
Run the case again and retain what remains unresolved.

That takes longer than writing a feature list, but it matches what we are trying to build. relay-dsh-plugin-codex and relay-dsh-plugin-claude are not proofs that two backends can be wired into DSH. We want them to carry continuous project work and to keep an accurate account of what they do and do not support after upgrades.

The Boundary Is Still Visible

The plugins cover the main conversation, coding, configuration, extension, and session-continuation paths. They are not complete replacements for the native Codex and Claude Code products.

Current boundaries include:

DSH does not yet provide a general document and file attachment path.
An imported Codex Thread or Claude Session should not have two active writers.
An existing Codex Thread does not automatically refresh DSH tools installed later.
Claude's CLI fallback remains a conservative text path and does not inherit all Agent SDK capabilities.
The complete post-release 162-case regression has not yet produced a new public matrix.

These limits stay in the documentation. Users should decide whether to migrate a task based on the capabilities it needs, not on a successful video alone.

Install and Follow the Work

Stop the running DSH Web process, then install either or both plugins:

dsh plugin --profile web add relay-dsh-plugin-codex@0.1.3
dsh plugin --profile web add relay-dsh-plugin-claude@0.1.4
dsh web

Codex plugin: GitHub · npm · v0.1.3
Claude plugin: GitHub · npm · v0.1.4
Relay: GitHub · plugin guide
DeepSeek Harness: official repository

We want to keep using these plugins on real projects months from now, not merely record a successful launch-day video. The 162 tests are not proof that the work is finished. They move it from “this seems to work” to “we know where it works and where we still have work to do.”

I Built a DeepSeek Harness Plugin That Installs Other Plugins from Chat

Bobo Yang — Wed, 26 Aug 2026 15:14:36 +0000

DeepSeek Harness supports plugins, but installing one usually means finding the
right package name, running a command, checking the profile, and deciding
whether DSH needs a restart.

I built a standalone plugin called relay-dsh-plugin-manager. Install it once,
and you can search for and manage other DSH plugins directly from a
conversation.

19-second demo: search for the Codex plugin, inspect the installation plan, confirm it separately, and finish the installation. Watch the full 38-second MP4 at normal speed.

What it does

You can write requests such as:

Find a workspace file browser plugin
Install relay-dsh-plugin-codex
List my installed plugins and their status
Disable example-dsh-plugin

Plugin Manager can:

search npm and GitHub from a description of the capability you need;
show a plugin's source, version, and basic information;
install, update, enable, disable, or remove a plugin;
show a plan first and wait for a separate confirmation before changing DSH.

Search and inspection are read-only. A vague request cannot immediately start
an installation.

How it differs from a typical plugin marketplace

Typical plugin marketplace	DSH Plugin Manager
Browse categories and lists	Describe the capability you need
Click an install button	Ask from the current conversation
Search mainly by name	Search with a natural-language requirement
Start after the click	Review a plan, then confirm separately

This is not meant to replace a visual marketplace. A traditional marketplace is
better for browsing. Plugin Manager is useful when you are already working in
DSH and want to find or install something without leaving the conversation.

Install it

The current release is a preview. Stop DSH Web, then run:

dsh plugin --profile web add relay-dsh-plugin-manager@next
dsh web

The manager itself still needs this one command. After that, other plugins can
be managed from Chat. KeySync's one-click DSH setup installs Plugin Manager
automatically.

The current release manages the running web profile. Some plugin changes may
still require a DSH restart.

Links

The plugin is developed in Relay but installs independently on official DSH. It
does not require a Relay fork.

Leave the Work PC Running: One Remote Workbench for DSH, Codex, and Claude

Bobo Yang — Tue, 25 Aug 2026 20:13:17 +0000

In an earlier KeySync demo, we filmed an intentionally ridiculous opening: someone cycling home while a laptop was still running an agent in the bike basket. Please do not copy that. The problem behind the shot is real, though: what happens to an active task after you leave your desk?

I do not want a fresh chat box on my phone. I want the same project, the same session, and a place to continue.

A composite made from the real three-device recording: the task runs on the Mac, is checked from a phone, and is continued from Windows. This earlier test used a native DSH conversation. Codex and Claude Code use the same DSH entry point described below, but keep separate sessions.

Why remote DSH alone was not enough

I do not use one agent for every job.

My current habit is simple. I start ordinary questions in native DSH. I use Codex when a task needs sustained code reading, shell commands, and file changes. I often use Claude Code for a second view on a document, design, or review. That is not a model ranking. It is a practical choice based on the task, price, and result I need.

The awkward part is everything around the answer. Conversations end up scattered across separate apps. Once I leave the work computer, each tool also needs its own way back in.

The setup I now use has three parts:

KeySync installs and runs official DeepSeek Harness (DSH) on the work computer, then provides a remote entry to that computer's DSH Web UI.
The Codex and Claude plugins add two optional conversation backends to DSH.
The Workbench, Files, and Terminal plugins keep the project files and shell next to the conversation.

KeySync does not bundle the Relay plugins. It installs DSH first; the plugins are added separately through DSH's own plugin system.

First, install official DSH

DeepSeek Harness has its own one-click install entry under KeySync's Devices and Apps page.

Real KeySync screen on macOS, ready to install DeepSeek Harness. This is the official DSH package, not a Relay-maintained fork.

After DSH is running, install the conversation plugins you need. Restart DSH, open New Session, and the mode menu keeps Standard mode while adding Codex and Claude Code.

Real mode menu from official DSH 0.1.1-rc.2 with both conversation plugins installed. Installing only one plugin adds only that backend.

Three agents together, without mixing their context

For the recording, I created three sessions under one workspace. Codex checked a code boundary. Claude Code reviewed a remote-handoff document. Native DSH analyzed test results.

Codex session recording: its tool call, reasoning, and answer stay visible in this DSH session.

Claude Code session recording: it reads a document and returns two review findings in its own session.

The three sessions can sit next to each other under the same project, but they do not automatically share context. To continue one, open that original session. What is unified is the project entry and session management, not the agents' memory.

The project is next to the conversation

Collecting chats is only half the job. When an agent mentions a file, I want to inspect it immediately. When I need to verify a command, I do not want to hunt for another terminal window.

Files shows the current workspace tree and text preview on the right. Terminal opens a real shell at the bottom. Workbench is only the shared panel host; it does not read files or start commands itself.

Official DSH running the Files plugin and previewing the Relay workspace's README.md.

Official DSH running echo in the current workspace. The screenshot keeps the real environment's zsh history permission warning instead of replacing the output with a mock.

Terminal is provider-neutral and needs another plugin to supply the actual shell. In this combination, the Codex plugin provides that shell backend. Files does not depend on Codex or Claude.

Change devices, keep the original session

After leaving the work computer, I can open its DSH instance from another KeySync desktop client or from the KeySync web page on a phone, tablet, or computer.

The important step is to open the existing session, not create a new one. Reopen the Codex session and a follow-up can depend on the earlier code review. The same rule applies to Claude Code and native DSH sessions.

Real remote recording: the browser reopens the original Codex session with the same workspace and session list. The outer frame and heading were added only to identify the recording context.

Three boundaries matter here:

The project, shell, and agents still run on the work computer. They are not moved to the phone or to a cloud runtime.
The work computer must remain online and awake enough to keep the programs running. KeySync and DSH must also stay active.
This opens the designated DSH Web UI; it is not general remote control of the computer. Use it only where the device owner and organization permit it.

Installation

The current public validation baseline is official DSH 0.1.1-rc.2. This command installs both conversation backends, the file panel, and the terminal panel:

npx @deepseek-ai/dsh@0.1.1-rc.2 plugin --profile web add \
  relay-dsh-plugin-codex@next \
  relay-dsh-plugin-claude@next \
  relay-dsh-plugin-workbench@latest \
  relay-dsh-plugin-files@latest \
  relay-dsh-plugin-terminal@latest

Codex and Claude Code can each be installed on their own. They are standalone npm packages, do not depend on Relay Events, and do not require a Relay checkout. Workbench is needed only by panel plugins such as Files and Terminal.

Restart DSH after installation. Codex and Claude Code still require their normal account authentication on the work computer.

As of August 26, 2026, the Codex next tag points to 0.1.1-rc.4, Claude next points to 0.1.1-rc.2, and the latest tag for Workbench, Files, and Terminal points to 0.1.0. Check the npm pages before installation because these tags will move.

What this is, and what it is not

This setup already handles four ordinary problems: I no longer search several interfaces for a project's conversations; DSH, Codex, and Claude sessions can be grouped by project; files and a shell remain beside the conversation; and I can return to the original session after leaving my desk.

It is not automatic multi-agent orchestration. I still decide which agent gets each task. Clear project, session, and backend boundaries give future handoffs a sensible foundation, but I do not want to market unfinished coordination as a current feature.

The useful change is much less grand: I can still choose a tool for cost, quality, and task fit without changing the entire place where I work.

Don't Start Over: Import Existing Codex Conversations into DeepSeek Harness

Bobo Yang — Tue, 25 Aug 2026 09:53:22 +0000

I want to use DSH as the front door to a project. I do not want a new interface
to make me repeat every requirement, test idea, and implementation decision that
is already in Codex.

relay-dsh-plugin-codex@0.1.1-rc.4 adds Workspace-level import. It finds the
Codex Threads that belong to a project and turns them into normal DSH Sessions.
Open one to read its history, then continue the same Thread.

This is not a mockup. The screenshot comes from official DSH 0.1.1-rc.2, the
published npm plugin, and real Codex App Server conversations.

Install the plugin

Stop the running DSH Web process, then install the npm prerelease:

dsh plugin --profile web add relay-dsh-plugin-codex@next
dsh web

next currently points to 0.1.1-rc.4. Replace @next with
@0.1.1-rc.4 when you need the exact version tested in this article.

You can also install the current development build from GitHub:

dsh plugin --profile web add \
  github:yangbobo2021/relay-dsh-plugin-codex#main

The plugin bundles a pinned official Codex App Server runtime for macOS,
Windows, and Linux, so it does not normally need a global codex command.
Codex authentication is still required. Start DSH as the same operating-system
user whose Codex profile contains the conversations you want to import.

Import one Workspace at a time

Add or open the project Workspace in DSH, then select Import Codex Sessions
near the bottom of the sidebar. The plugin scans Codex conversations by project
path and shows the totals before it changes anything.

The current release imports the entire Workspace; it does not offer per-Thread
checkboxes. Select Import all to continue. This run found three conversations,
imported all three, and reported zero failures.

Keep the useful titles and order

Imported Sessions show their Codex titles immediately and stay ordered by the
source activity time. You do not have to open every row to work out what it was.

The operation is idempotent. Running it again in this test produced Found 3,
Existing 3, and Ready 0, with no duplicate Sessions.

Open the history and keep going

When an imported Session opens, the plugin performs one thread/read and adds
missing terminal user and assistant messages to DSH's presentation history.
The original answer, tool activity, model, and reasoning effort remain visible.

I then asked which step from the earlier four-step plan should come first. Codex
answered from that existing context instead of starting a blank conversation.
After switching to another Session and back, both turns were still present.

What moves, and what does not

DSH stores normal presentation history plus a durable one-to-one binding between
the DSH Session and the Codex Thread. Codex App Server still owns model context,
tool state, and compaction. The plugin does not copy private Codex runtime records
into a second database.

Three limits are worth knowing:

Import currently works on a whole Workspace, not selected Threads.
A Session synchronizes once when it opens. There is no background polling or manual refresh action.
One Codex Thread cannot have two App Server writers. Fully quit the Codex client or process that owns the Thread before continuing it in DSH.

The practical result is simple: adopting DSH does not mean abandoning work that
already happened in Codex. Native DSH, Codex, and Claude conversations can live
under one project, while each task still uses the backend that makes sense for
its quality, cost, and tool needs.

One Project, Three AI Conversations: Why I Put DSH, Codex, and Claude Together

Bobo Yang — Mon, 24 Aug 2026 23:55:58 +0000

I did not bring Codex and Claude Code into DeepSeek Harness because either tool
was disappointing. I did it because each is useful, and I no longer wanted my
day to be organized around their separate applications.

A normal task can start as a requirements discussion in DSH, move to Codex when
the change becomes implementation-heavy, then end in Claude Code for an
independent review. Files and a terminal sit in two more windows. A few hours
later, the hard part is often not the code. It is remembering which window owns
the conclusion that matters.

I wanted to invert that arrangement: keep the project in place and choose the
tool for the task.

DSH is the front door, not the only answer

Native DSH conversations remain useful. Routine questions, short jobs, and work
already handled well by the installed DSH stack do not need another agent. When
a task reaches a capability limit, however, leaving the project workspace and
rebuilding context in another application is a poor handoff.

With the plugins installed, a new DSH session can use the native mode, Codex, or
Claude Code. DSH still owns the session, workspace, and interface. A Codex
session is driven by a Codex App Server Thread; a Claude session is driven by
the Claude Agent SDK. These are not generic API replies wearing different
labels. Each backend keeps its own execution model and conversation continuity.

The useful change is not merely two extra menu entries. Sessions still belong
to a project. Requirements, implementation, review, and verification for one
repository can live under one Workspace group instead of being recalled by
application.

Cost and quality are not a binary choice

"Which agent is strongest?" is rarely the question I need to answer during a
working day. The practical question is which backend this task deserves.

A routine question that should take ten minutes can begin in native DSH.
A change that requires repeated file edits, commands, and test repair can use a Codex session.
An independent review, a second design angle, or a difficult analysis can use a Claude Code session.

This is not a permanent division of labor or a model leaderboard. Subscription
terms, model versions, task shape, and team habits all affect cost and quality.
One entry point preserves the choice: inexpensive work does not need the most
expensive route, and important work does not have to accept a weaker result to
save a small amount.

What works today

The published plugins currently provide:

Codex and Claude Code choices in DSH's new-session mode menu;
continued Codex Threads and Claude Sessions across their respective DSH turns;
DSH input, history, approvals, and tool presentation;
a Workbench host for the Files side view and Terminal bottom view;
a project working directory attached to the session.

The Codex and Claude plugins install independently and do not require Relay
Events:

What has not happened yet

The user still decides which agent should take a task and creates the sessions
separately. The system does not yet compress a DSH conversation and hand it to
Codex automatically. It does not ask Claude to review a Codex implementation
when the implementation finishes. A shared interface is not the same thing as
multi-agent orchestration.

What has changed is the boundary. Projects, user-facing sessions, and execution
backends are no longer one inseparable choice. That is a prerequisite for later
coordination: a task can belong to a project, an agent can be selected, and a
future Relay event or handoff has a clear destination.

I prefer to treat the current release as a useful project workbench, not a grand
multi-agent diagram. Today it reduces application switching, organizes sessions,
and lets cost and quality guide backend choice. Automated coordination can earn
its place after a real end-to-end loop exists.

The next article opens the Codex plugin: who starts App Server, how one DSH
session binds to a Thread, and why the integration is not simply a shell call to
codex.