Bobo Yang

Posted on Sep 1 AI-assisted

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

#remote #ai #devtools #linux

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.

DEV Community