DEV Community: Joey 、

Remote-controlling your computer from your phone: the security traps that worry me

Joey 、 — Mon, 17 Aug 2026 16:26:30 +0000

Remote-controlling the agent on your computer from your phone: what security traps worry you most?

An open security discussion. I'll share four real concerns I've hit or thought about. I want your fuller list — I'm sure there's stuff I haven't thought of.

Remote control has always been a tug-of-war between "convenient" and "safe." After turning my phone into a remote for the agent on my computer, I've put together a few real security concerns and would love to hear your complete checklist — there's definitely things I'm missing.

Three I've handled so far

Building DeepSeek Phone Harness (drive your desktop agent from your phone over 4G/5G), I dealt with at least three layers:

Token auth: every endpoint requires Authorization: Bearer; the token lives in a local config.json, never in any repo (I scrubbed history once already).
Approval cards: before the agent does something risky (writing files, running commands) → a "authorization needed" card pops on the phone; allow/reject is a human decision. I believe this is the floor for remote control — when you're not at the computer, authorization has to be interceptable.
Network isolation: recommend Tailscale private-network direct access, don't expose the port raw to the public internet; if public, go through a reverse proxy + strong token.

The ones I'm honestly unsure about

These have no clear answer from me yet — open to being corrected:

MITM on 4G/5G: Tailscale encrypts, but if exposed without it, is a bearer token over HTTP acceptable?
Agent privilege boundary: an approval card can only block what I know to block. Could an agent chain harmless steps into a harmful outcome (read a bunch of files, then quietly write one)?
Lost phone: unlocked phone = control over your desktop agent. Should there be a second factor / device PIN / expiring tokens?
Prompt injection on the model: if I feed the agent a crafted prompt, could it run something unexpected? How granular should permissions really be?

What I most want from you

A good security checklist for remote control is something the community knows better than one person. Let's hear:

When you remote-control your own computer, which class of risk worries you most?
Besides "authorization interception", what mechanism do you consider essential?
What's your one-line objection to "control your computer from your phone"?

I want to turn this into an open-source security checklist for remote-control tools (and fold it into the project's SECURITY.md if it's useful), so every reply gets read and credited.

Project (MIT): https://github.com/2903077918-lgtm/DeepSeek-phone-harness
My security-ish implementation is open for review: src/transport-lan.js (auth / approval relay)

Your agent asked a question and froze the queue for 10 min — how do you all handle ask_user_question?

Joey 、 — Mon, 17 Aug 2026 16:26:27 +0000

Your agent casually asked a question and froze the queue for 10 minutes — how do you all handle `ask_user_question`?

A real pain point. I'll share my solution and the traps I hit, but I really want to hear how the community actually deals with it.

Quick one for everyone: do your agents randomly stop to ask you questions? And what happens to the running task when they do?

Here's what happened to me: DeepSeek Harness's agent calls ask_user_question mid-task — "should this module be sync or async?" "OK to run this high-risk command?" Sounds reasonable. But it deadlocked my entire task queue for 10 minutes.

The problem: a question = a silent deadlock

The worst part: it doesn't error. The task just hangs there, pending keeps climbing, you think it's thinking — but it's actually waiting for a human answer that will never come. Because the question goes through the question channel (question/requested), which is completely separate from the approval channel (approval/requested).

My first relay only listened to approvals, so:

Agent stops on the computer, waiting for a user
      ↓
question-channel messages silently dropped by my relay
      ↓
phone has no idea
      ↓
task hangs forever until timeout

It took me two days to realize: it wasn't DSH hanging — the question just never reached a human.

My fix: turn questions into "your answer needed" cards

While building DeepSeek Phone Harness (remote-control your desktop agent from your phone), I made questions a card that drops right into the message stream:

Agent asks → phone shows "your answer needed" card
Pick an option / type a custom answer / skip
Answer it and the task continues; ignore it and it waits

Protocol has to match the official Web GUI exactly ({ok:true, value:{sessionId, answer:{answers:[{id, selected}]}}}), or DSH won't accept it.

What I'd really like to hear

My fix only handles the "phone side." I want the broader community's practice:

Do you let agents ask you questions at all, or disable ask_user_question?
Granularity: which questions are worth interrupting a human for, and which should the agent just decide?
Async handling: when a question blocks a task, what does your queue do — block, skip, or run around it?
Has anyone set a "question budget" per task, or use an alternative tool?

Honestly my current stance is conservative (ask only if it must, always interrupt). But I suspect that's not optimal — "when to interrupt a human" is probably the deeper question than "how to interrupt."

Would love to hear your practices below. And if you've had an agent-question deadlock too, drop a comment so I can gauge how common this actually is.

Implementation is open source (MIT): https://github.com/2903077918-lgtm/DeepSeek-phone-harness

We made a 31-second promo to say one thing: your phone is the best remote for your agent

Joey 、 — Sun, 16 Aug 2026 09:07:23 +0000

We made a 31-second promo to say one thing: your phone is the best remote for your agent

The DeepSeek Phone Harness promo is live. 31 seconds, 8 shots, one message: your phone controls your computer.

Watch it first

🎬 DeepSeek Phone Harness · 31s promo (grab https://github.com/2903077918-lgtm/DeepSeek-phone-harness/releases/download/v0.4.0/promo.mp4 (with BGM) / https://github.com/2903077918-lgtm/DeepSeek-phone-harness/releases/download/v0.4.0/promo-nobgm.mp4 (no BGM, SFX kept) from the repo)

In the dark, a phone screen glows gold. Messages type out on it. Tool cards fly in — which file was read, what command ran, done or failed, all visible. The agent asks a question; a card pops up for the answer. Model switching is a thumb-swipe. Finally, phone and computer connect across deep space: Phone in hand. Computer at your command.

Made with video-shotcraft — picked from 152 shot recipe cards: ink crosshair opening, graze-face tour, card dealing, line-carry transition, 3D terminals, overhead file reveal, segmented control, deep-space outro. Real screenshots, fictional demo data, 31 seconds, 8 shots.

What the promo is really about

One sentence: the phone is the best remote for your agent.

Most people use agents by sitting at the computer watching them work. But the whole point of an agent is that it does the work for you — and yet you have to babysit it. That's backwards.

On the commute, want to dispatch a task: phone
In bed, want it to start running: phone
Mid-meeting, it needs approval: phone, one tap
Away from the desk, want to check progress: phone

Mobile isn't a shrunken web page — it's a different paradigm: approvals, questions, and tool cards inline in the message stream, your thumb as the mouse, every step of the agent visible.

Why it's worth a look

Zero npm dependencies: one Node process + one HTML file, clone and run
Direct 4G/5G: free Tailscale, no public IP
Tool cards show paths: which file was read, what changed, the result — tap to expand
No deadlocks: the agent asks → a card pops up → answer → it continues
MIT open source: ~4000 lines, stars/PRs/issues welcome

Run it in three minutes

git clone https://github.com/2903077918-lgtm/DeepSeek-phone-harness
cd DeepSeek-phone-harness && cp config.example.json config.json
node agent.mjs --mode=both

Install Tailscale on the phone, open http://<computer IP>:8788/, go.

"Wherever you are, your agent is too." — not a tagline. It's been my real life for two weeks.

Repo: https://github.com/2903077918-lgtm/DeepSeek-phone-harness

What would YOU make your desktop agent do from your phone? Comments open.

Where DeepSeek Phone Harness goes next — and how you can shape it

Joey 、 — Sun, 16 Aug 2026 07:10:21 +0000

Where DeepSeek Phone Harness goes next — and how you can shape it

A roadmap, an honest status check, and a call for contributors. The most-requested feature ships first.

Two weeks ago this was a sketch. Today DeepSeek Phone Harness runs on my phone every day. Here's where it's headed — and where you come in.

Status check (honest)

Working well:

Chat + streaming typewriter, multi-turn sessions
Tool cards: icon, status, file path, expandable args/result
Approval cards + ask_user_question answer cards (no more deadlocks)
Model switching, image attachments, thinking disclosure
Terminal, file browser, task history, session management
Zero npm dependencies; runs on any Node 22+

Known limits (being honest):

Web page, not a native app (PWA covers most of it)
Terminal runs commands one at a time — no full PTY interactivity yet
No push notifications yet — you poll, it doesn't call you
Cloud channel requires deploying your own Worker

Roadmap — most-requested first

Push notifications — task finished, approval needed → phone notifies without opening the page
PWA offline shell — add to home screen, feels native
Persistent PTY terminal — interactive commands, not just run-and-collect
Multi-device / multi-account — one agent, several controllers
Native shell (Tauri/Electron) — if the demand shows up

How you can shape it

Open an issue with your most-wanted feature — the roadmap above is literally "what people asked for"
PR welcome: the codebase is ~4000 lines of plain Node + one HTML file. No build step, no framework to learn. A focused PR is a weekend at most
Report the ugly: a weird hang, a wrong tool card, a confusing flow — file it, I read everything

The rule

The roadmap is ordered by request count, not by my preference. If your feature isn't on the list, that's because nobody asked for it yet. So ask.

Repo:

https://github.com/2903077918-lgtm/DeepSeek-phone-harness

What's the one feature that would make you use this daily? One line is enough.

Why I open-sourced the tool I built "just for myself"

Joey 、 — Sun, 16 Aug 2026 07:10:20 +0000

Why I open-sourced the tool I built "just for myself"

It started as a selfish project: a phone remote for my own desktop agent. Three reasons made me push it public. The third one surprised me.

I built DeepSeek Phone Harness for one reason: I was in bed at 1 a.m., wanted to send a task to the agent on my computer, and refused to get up. Pure selfishness.

It worked so well that I kept using it. And then I had to decide: keep it private, or open it up?

Reason 1: the bug that cost me two days deserves a warning sign

The hardest bug — the one that made tasks hang forever — was invisible until you knew it existed: DSH's agent-question channel is separate from its approval channel. Miss it, and every ask_user_question call deadlocks your pipeline silently.

There's no way to discover this by reading docs. You have to capture a real event stream, notice a frame type nobody told you about, and chase it for two days. That kind of hard-won knowledge should be public — someone else shouldn't have to re-pay that tuition.

Reason 2: the pattern deserves to be copied

"Phone as a remote for a desktop agent" is a genuinely useful pattern. But right now it lives in scattered, platform-specific implementations. An MIT-licensed, zero-dependency reference implementation lowers the floor: anyone can clone it, read ~4000 lines, and build their own — for DeepSeek Harness, or any agent runtime with a similar event model.

Reason 3 (the surprise): it changed how I write code

Open-sourcing it forced me to do things I wouldn't have bothered with otherwise:

Remove secrets from history (filter-branch, .gitignore — my token never touches GitHub)
Write real docs and onboarding instead of "works on my machine"
Structure the code so a stranger could read it
Take feedback as a feature list instead of a threat

The tool got better in the week after open-sourcing than in the week before. That surprised me, and it's the reason I'll keep building in public.

What I ask in return

Nothing, really. But if you take one thing: when you fix a nasty bug nobody warned you about, write it down and put it where others can find it. That's the entire spirit of this project.

Repo (MIT, zero dependencies, three-minute setup):

https://github.com/2903077918-lgtm/DeepSeek-phone-harness

Have you open-sourced something you built "for yourself"? What changed? I'd genuinely like to know.

Streaming a desktop agent to your phone with zero npm dependencies

Joey 、 — Sun, 16 Aug 2026 07:05:08 +0000

A weekend project that streams a desktop agent to your phone — with zero npm dependencies

One WebSocket, one Node process, one HTML file. Here's the architecture behind DeepSeek Phone Harness, and the three decisions that made it work.

Last weekend I built DeepSeek Phone Harness — a mobile remote for DeepSeek Harness. The constraint I set myself: zero npm dependencies. Not because I'm a purist, but because a tool like this should be "clone and run," not "install 47 packages and hope."

Here's the architecture that made it work.

One process, three responsibilities

Phone browser (relay.html)
   │  HTTPS / Tailscale
   ▼
Agent (Node, :8788)  ── http server + static page + WS relay
   │ 127.0.0.1:3080
   ▼
DeepSeek Harness gateway (dsh web)

The Agent is a translator, not a replacement: it speaks REST to the phone and RPC to DSH.

Decision 1: one WebSocket for all realtime events

DSH exposes events.mux — a WebSocket stream carrying approvals, questions, and session events in one pipe. Instead of opening one connection per concern, I keep one persistent connection and route frames locally:

Frame	Goes to
`approval/requested`	pending table → phone approval cards
`question/requested`	pending table → phone answer cards
`session/event`	ring buffer (200/session) → phone stream polling

The phone polls /api/events?afterSeq=N — each poll returns only new bytes, which keeps 4G streaming smooth.

Decision 2: the question channel is NOT the approval channel

The single most important bug I fixed: DSH agents call ask_user_question through a separate channel from approvals. If you only listen for approval/requested, the moment the agent asks something the task deadlocks forever — it's waiting for a human answer that the phone never shows.

The answer protocol had to match the Web GUI exactly:

{ "ok": true, "value": { "sessionId": "...", "answer": { "answers": [{ "id": "q1", "selected": ["..."] }] } } }

Decision 3: tool calls become cards keyed by callId

Every tool/call event creates a tool card (name, icon, status, file path extracted from arguments). Every tool/result pairs back by callId and flips the card to done/failed. Tapping expands the full arguments and result.

One trap: DSH's tool/result content is double-nested (content[].content[].text) — my first version read one level too shallow and results came back empty. Lesson: capture a real payload before trusting any schema.

The result

~4000 lines, zero dependencies
Single-file frontend (relay.html)
Streaming typewriter, tool cards, approval/answer cards, model switching, terminal, file browser
4G/5G via Tailscale, no public IP

Why this matters

"Phone remote for a desktop agent" sounds like it needs a platform team. It doesn't. The barrier to entry for this whole category just collapsed — anyone with Node 22+ can build or extend one in a weekend.

The code is open (MIT):

https://github.com/2903077918-lgtm/DeepSeek-phone-harness

Questions about the architecture? Happy to go deeper in the comments.

"Remote-controlling your agent from a phone" — the 10 questions everyone asks

Joey 、 — Sun, 16 Aug 2026 07:00:00 +0000

"Remote-controlling your agent from a phone" — the 10 questions everyone asks, answered

Collected from comments and DMs. Read this and you'll know whether this is for you.

Since building DeepSeek Phone Harness, the same 10 questions keep coming up. Let's answer them all at once.

Q1: Is remote-controlling a desktop agent from a phone safe?

Depends on how you use it. The project has two layers of protection: every API requires a Bearer token, and risky operations first show an "authorization needed" card that you allow or reject on your phone. But the safety ceiling of any remote-control tool is set by your network — use a private network like Tailscale, and don't expose port 8788 raw to the public internet.

Q2: Do I need a public IP? A server?

Neither. 4G/5G connects directly to the computer via Tailscale (free); LAN works directly. A Cloudflare Worker is optional if you want a public entry.

Q3: How is this different from remote desktop (TeamViewer/AnyDesk)?

Remote desktop transmits a screen — you look at the display and move the mouse. This transmits semantics — instructions and results. You see the agent's reasoning, tool calls, and outcomes, not a shrunken screen. An order of magnitude less bandwidth, and far clearer on a phone.

Q4: How much of the web experience does the phone have?

Most of it: chat, streaming, model switching, image attachments, approvals, questions, terminal, files, tasks. On a few details mobile is actually ahead: approval/question cards inline in the message stream (no context break), and tool calls as a vertical timeline (made for portrait). Heavy work (large-scale editing) still belongs at a desk.

Q5: Do tasks hang? What if the agent asks something?

They used to — that was the biggest trap I hit. When an agent calls ask_user_question, an unanswered task hangs forever. Now the question becomes a "your answer needed" card: pick an option / type a custom answer / skip. Answer and it continues; ignore and it waits. Tasks never deadlock because "nobody's listening."

Q6: Can I see exactly what the agent is doing?

Yes — and it's the part I'm proudest of. Every tool call is a tool card:

[📄 read]                          ● done
C:/Users/Joey/Documents/.../config.json
▾ tap to expand: full arguments + full result

Which file was read, what command ran, the outcome — all visible. The agent's reasoning folds into a collapsible block too.

Q7: Is it smooth on 4G/5G?

Yes. Streaming is incremental polling — each pull only fetches a few hundred new bytes; tool cards and approval cards are lightweight JSON. The typewriter effect stays smooth on 4G in practice.

Q8: Do I need an app? Any setup?

No app — the phone browser opens a page directly (PWA add-to-home-screen works). On the computer you need Node 22+ and a running DeepSeek Harness. Setup is one config.json with a token.

Q9: "Zero dependencies" — really? Is deployment easy?

Really. The agent uses only Node built-ins (http / child_process / crypto / fs) — zero npm dependencies. Clone → set token → node agent.mjs --mode=both. The frontend is a single relay.html file.

Q10: What's the relationship with DeepSeek official?

Pure community project, not official. I just believed "controlling your desktop agent from a phone" was a need someone should fill, so I filled it. Official is building Harness itself; I built its "pocket remote."

Verdict

Is it for you? One-line test: if you often want your agent to work while you're away from the desk — yes; if you're always at the desk — it's a nice-to-have.

Open source (MIT):

https://github.com/2903077918-lgtm/DeepSeek-phone-harness

Any other questions? Ask in the comments — I reply to every one. Popular questions will keep updating this list.

The 5 agent tasks I most often run from my phone: a real list

Joey 、 — Sun, 16 Aug 2026 06:59:59 +0000

The 5 agent tasks I most often run from my phone: a real list

No concepts — a list. These are real tasks I dispatched to my desktop agent from my phone over the past week.

After building DeepSeek Phone Harness, I developed a habit: anything that can be done on the phone, never get up and walk to the study. Here's last week's real log.

Task 1: Dispatch on the commute, collect the result on arrival

Most used. On the subway, open the phone, send "list the 5 largest files in downloads, sorted by size." Get off and read the answer.

Phone experience: send, lock screen. The agent runs slowly on the computer; I sway slowly on the train. Tool cards show it running dir, du — every step in plain sight.

Task 2: Tweak config before bed, find it verified in the morning

At night, in bed, send "change the timeout in config to 30 seconds, then run the tests." Next morning the tests are done, conclusion waiting on the phone.

Why on the phone: because I'm turning off the lights. If this task required the computer, I'd probably procrastinate it into oblivion.

Task 3: Tap approvals mid-meeting

The agent needs authorization mid-task — previously that meant waiting until I was back at the desk. Now a "authorization needed" card pops up, thumb taps "Allow once", it continues.

Best moment: a colleague at the same table asked what I was doing in the meeting. "Greenlighting my desktop agent."

Task 4: Quick code lookups from the couch

Lying on the sofa, wanting to confirm whether a certain function exists in a file. Before: get up → study → open editor → search → come back. Now: phone → file browser → read → keep lying down.

Tool cards shine here: when the agent searches code, cards show exactly which file it's reading, path at a glance.

Task 5: Model comparison experiments

Want to compare deepseek-v4-flash vs v4-pro on the same task — tap the model name at the top, switch, re-send, compare side by side.

Before: edit CLI config, restart, retry. Now: two taps.

The common thread

All five tasks share one trait: none of them require you to be at the computer. They only need:

Send an instruction
See the process
Make decisions at key moments (approvals/questions)
Collect the result

The phone happens to provide all four. And "not being at the computer" is exactly the most overlooked part of the agent experience.

The toolkit

Open source (MIT):

https://github.com/2903077918-lgtm/DeepSeek-phone-harness

Direct 4G/5G (free Tailscale), three-minute setup
Streaming output, tool cards (path/status/detail), approvals, question answers, model switching, terminal, files
Zero npm dependencies, single-file frontend

Which agent tasks would you want to do from your phone? List them — the most requested ones ship next.

From "a thought in bed" to open source: one week of development diary

Joey 、 — Sun, 16 Aug 2026 06:54:52 +0000

From "a thought in bed" to open source: one week of development diary

No glamorous start — just a late-night thought. A week of building DeepSeek Phone Harness, from zero to release.

Day 1 · 1 a.m., a thought

In bed that night, I realized I could have the agent on my computer run a task early. Get up and walk to the study? Too much trouble. Give up? Unsatisfying.

In that moment it hit me: the agent's value is doing work for me, yet I'm chained to the computer.

Next morning I opened the editor and decided to solve it myself.

Day 2 · First version: a working "translator"

The core idea was simple: the phone sends HTTP, an agent process translates it into DSH RPC, and translates responses back.

That evening the first version worked: send a sentence from the phone, the agent on the computer executes, the result returns to the phone. Ugly, but it moved.

Day 3 · Deadlocked all day: ask_user_question

On day three, tasks started "randomly hanging." I dug until late night and found: the agent asks the user questions, questions don't go through the approval channel, and I wasn't listening to the question channel. Tasks waited forever on a question nobody answered.

When it was fixed, my commit message said three words: "no more hangs."

Day 4 · Make the work visible

Results weren't enough — I wanted the phone to see what the agent does, step by step.

So tool cards were born: one card per tool call, with icon, status, the file path it touched, and expandable full arguments and results. The agent's reasoning also folds into a collapsible block.

That night I sat watching the agent work on my phone for a long time. "Watching it think and move" versus "waiting for a result" are two completely different experiences.

Day 5 · Terminal, files, tasks: from usable to useful

Added the terminal (remote commands), file browsing, task history (one-tap re-run), and session management (rename/delete/search).

Day 6 · Polishing

Approval and question cards inserted directly into the message stream — no context breaks
Model picker, image attachments, thinking disclosure
Fixed browser caching that made users "never see the new UI"

Day 7 · Open source

Wrote the README, wrote the promo posts, pushed to GitHub. There was no ceremony — just git push and a long exhale.

~4000 lines, zero npm dependencies, one Node process + one HTML file.

A week later, now

It runs stably: dispatch tasks on the commute, tweak config before bed, tap approvals mid-meeting. The phone became the agent's remote — "wherever you are, your agent is too" is no longer just a slogan.

Try it

Open source (MIT), three-minute setup:

git clone https://github.com/2903077918-lgtm/DeepSeek-phone-harness
cd DeepSeek-phone-harness && cp config.example.json config.json
node agent.mjs --mode=both

Install Tailscale on the phone, access over 4G/5G.

https://github.com/2903077918-lgtm/DeepSeek-phone-harness

If you were to build an open-source project "for yourself," what pain point would you solve first? Comment below — the next viral project might start here.

The agent's next stop is your pocket: why mobile may be the agent's best form

Joey 、 — Sun, 16 Aug 2026 06:54:51 +0000

The agent's next stop is your pocket: why "mobile" may be one of the agent's best forms

We moved agents from the terminal to the browser. Now it's time to move them into your pocket. This isn't "mobile adaptation" — it's a shift in interaction paradigm.

DeepSeek Harness just went open source, and the community is excited — models, tools, agent loops, all pluggable. But amid the noise I noticed something:

Everyone's discussing what agents can do. Almost nobody discusses where you use them.

Let's talk about the second one — and I'll give you my own answer.

Agent usage is moving from "sit down" to "anytime"

First generation: open a terminal, sit down, watch.

Second generation (Web GUI): open a browser, sit down, watch.

Essentially it's still "you must be seated at the computer." But an agent's whole value is that it does the work for you — and yet you have to babysit it. Is that reasonable?

On the commute, I want it to start running first
Before bed, I want to assign tomorrow's tasks
Mid-meeting, it needs an approval — I want to tap once and let it continue

All these share one trait: you're not at the computer, but the agent is working. Who's the remote? The phone is the only answer.

Mobile isn't a "shrunk webpage" — it's a new paradigm

I used to think mobile = shrunk web. After actually building it, I found mobile's interaction logic is fundamentally different:

1. From "multiple windows" to "a single timeline"

The web has panels side by side: conversation, tool output, approval dialogs. Mobile naturally has one vertical timeline — user message, agent reasoning, tool cards, approval cards, question cards, all linear. The agent's work becomes a replayable pipeline, which is clearer, not less.

2. From "clicking around" to "making decisions"

On desktop you click everywhere. On mobile, thumb reach is limited, which forces interactions into "look once → decide": allow this tool call or not? How to answer this question? — judgment calls, not browsing sessions.

3. From "accompanying" to "async"

On desktop you sit with the agent. On mobile you dispatch → leave → come back for results. That pushes the agent side to do state management properly (task queues, result retention, failure notifications) — which is exactly where agent products are heading.

My answer: an open-source project that puts the agent in your pocket

Based on the above, I built DeepSeek Phone Harness:

Control DeepSeek Harness on your computer from a mobile browser (4G/5G, Tailscale direct)
Streaming output, tool cards (path/status/detail), approvals, question answers, model switching, terminal, files
Zero npm dependencies, ~4000 lines, single-file frontend
MIT open source, clone and run

It's no revolutionary invention — just a plain answer: "when the agent works for you, you shouldn't have to be there."

https://github.com/2903077918-lgtm/DeepSeek-phone-harness

Your turn

What do you think is the agent's next form?

Mobile (a pocket remote)?
Always-on cloud (unattended agents)?
Something else?

Comment below — this is a topic worth arguing about.

Watching my agent work from the phone and the desktop at the same time

Joey 、 — Sun, 16 Aug 2026 06:49:43 +0000

Watching my agent work from the phone and the desktop at the same time — I can't go back

You'd expect the phone to be a "downgraded" web page. After a side-by-side test, I found some experiences are actually better on mobile.

Before building DeepSeek Phone Harness, I set my own acceptance bar: the phone must reach 80% of the desktop web experience, or it's not done.

After finishing, I ran a controlled test: the same task, watched simultaneously on a desktop browser and a phone browser. The result surprised me — a few experiences are genuinely better on mobile.

The test: one task, both screens

Task: let the agent read the project config, summarize current progress, and run a test.

Dimension	Desktop web	Phone
Streaming output	Fine	Fine (typewriter)
Tool-call visibility	Present	Stronger: each card shows the file path; tap for args + result
Approvals	Dialog/panel	Cards inline in the message stream — no page switch
Questions	Input takeover	Option cards, one tap
Model switching	Dropdown	Bottom sheet, thumb-reachable
Away from desk	Must be at the computer	Works from anywhere

Why mobile is better at some things

1. Approvals/questions don't break context

On desktop, an approval is a separate dialog that interrupts what you're reading. On mobile, I made approvals and questions cards inserted directly into the message stream — the context of where the agent is and why it's asking stays continuous.

2. Tool cards are naturally built for portrait

"Read file → run command → edit code" — a vertical sequence of tool calls is made for a portrait screen. On desktop you juggle logs and lists; on mobile it's one clean timeline:

[📄 read]   C:/.../config.json          ● done
[⚙️ pwsh]   npm test                    ● running…

3. Your thumb is the best mouse

Model switching, attachments, card expansion — everything lives within thumb reach.

An honest comparison

Mobile is not a replacement for the desktop — heavy work (editing lots of code, digging logs, multi-terminal) still belongs at a desk. But mobile closes the desktop's biggest gap: the moments you're not at the computer.

Send a task on the commute, read the result when you arrive
Tweak a config before bed, find it verified in the morning
Approve an agent request mid-meeting with one tap

"Wherever you are, your agent is too" — that's mobile's real value, not "a smaller webpage."

The project

Open source (MIT):

https://github.com/2903077918-lgtm/DeepSeek-phone-harness

Direct 4G/5G (free Tailscale), three-minute setup, zero npm dependencies.

Which of your agent tasks could be done while you're away from the desk? List them below — I'll see what belongs on the roadmap.

3 traps I fell into while letting a phone control a desktop agent

Joey 、 — Sun, 16 Aug 2026 06:49:42 +0000

3 traps I fell into while letting a phone control a desktop agent — it's harder than it looks

On the surface it's an HTTP layer and a web page. Underneath, every step fights your assumptions. Real pitfalls, so you can avoid them.

Before building DeepSeek Phone Harness, I assumed "mobile remote control for a desktop agent" was just moving a web page to a phone. After finishing it, I admit: the idea took 10 minutes; the bug-fixing took a week.

Here are 3 real traps — each one made tasks "gracefully deadlock" in production.

Trap 1: The moment the agent asks a question, the task hangs forever

This is the nastiest one.

Our relay listened to DSH's approval channel (approval/requested) — all good. Until one day a test task never finished. Not an error — just hung, pending climbing.

Two days of digging later: DSH agents can call the ask_user_question tool to ask the user something — and that goes through a different channel (question/requested), not the approval channel. My relay only listened for approvals, so question frames were silently dropped.

Result: the agent waits on the computer for a human answer, the phone has no idea, the task hangs forever. It only continues once the user answers.

Fix: ingest question frames separately, forward them as "your answer needed" cards, and use the exact same answer protocol as the official Web GUI.

Lesson: in an agent's realtime event stream, every frame type exists for a reason. Miss one, and tasks die in ways you'd never guess.

Trap 2: Tool results live two layers deep

The phone shows "tool cards": tool name + file path + result. Name is easy, path is easy (extract from arguments). Result?

I assumed tool/result content was [{type:'text', text:'...'}]. Naive. The real shape:

content: [{
  "type": "tool-result",
  "content": [{ "type": "text", "text": "<path>...<content>..." }]
}]

Two levels of nesting, with toolCallId on the inner block. My first version only read one level: cards had names and paths, but results were always empty.

Fix: recursive text collection + pairing calls to results via source.callId.

Lesson: no protocol doc beats capturing one real payload.

Trap 3: Mobile browser caching made users see a forever-old UI

Changed the UI, opened the phone — still the old one. Refresh, restart browser, switch browser — same.

Not a network issue. It's caching: the old page was cached, and Cache-Control wasn't set.

Fix: serve HTML with no-store, no-cache, must-revalidate. Every open is now the latest.

Lesson: for mobile web apps, cache strategy matters as much as feature code.

Why these traps are worth sharing

Each one reveals the real complexity of "remote-controlling an agent from a phone":

It's not a static page — it's a faithful courier of a realtime event stream
It's not a toy — it must handle approvals, questions, tool results at production level
It's not a demo — it must stay low-latency, retryable, recoverable on 4G

After fixing all of it, tool cards look like this on the phone:

[📄 read]                          ● done
C:/Users/Joey/Documents/.../config.json
▾ tap to expand: full arguments + full result

Every step the agent takes — which file, what command, the outcome — is visible. Permission requests and questions become cards. Tasks never hang because "nobody answered."

The project

Open source (MIT). Stars / PRs / issues welcome:

https://github.com/2903077918-lgtm/DeepSeek-phone-harness

What's the weirdest bug you've hit while working with agents? Share it below — I bet it beats mine.

DEV Community: Joey 、

Remote-controlling your computer from your phone: the security traps that worry me

Remote-controlling the agent on your computer from your phone: what security traps worry you most?

Three I've handled so far

The ones I'm honestly unsure about

What I most want from you

Your agent asked a question and froze the queue for 10 min — how do you all handle ask_user_question?

Your agent casually asked a question and froze the queue for 10 minutes — how do you all handle ask_user_question?

The problem: a question = a silent deadlock

My fix: turn questions into "your answer needed" cards

What I'd really like to hear

We made a 31-second promo to say one thing: your phone is the best remote for your agent

We made a 31-second promo to say one thing: your phone is the best remote for your agent

Watch it first

What the promo is really about

Why it's worth a look

Run it in three minutes

Where DeepSeek Phone Harness goes next — and how you can shape it

Where DeepSeek Phone Harness goes next — and how you can shape it

Status check (honest)

Roadmap — most-requested first

How you can shape it

The rule

Why I open-sourced the tool I built "just for myself"

Why I open-sourced the tool I built "just for myself"

Reason 1: the bug that cost me two days deserves a warning sign

Reason 2: the pattern deserves to be copied

Reason 3 (the surprise): it changed how I write code

What I ask in return

Streaming a desktop agent to your phone with zero npm dependencies

A weekend project that streams a desktop agent to your phone — with zero npm dependencies

One process, three responsibilities

Decision 1: one WebSocket for all realtime events

Decision 2: the question channel is NOT the approval channel

Decision 3: tool calls become cards keyed by callId

The result

Why this matters

"Remote-controlling your agent from a phone" — the 10 questions everyone asks

"Remote-controlling your agent from a phone" — the 10 questions everyone asks, answered

Q1: Is remote-controlling a desktop agent from a phone safe?

Q2: Do I need a public IP? A server?

Q3: How is this different from remote desktop (TeamViewer/AnyDesk)?

Q4: How much of the web experience does the phone have?

Q5: Do tasks hang? What if the agent asks something?

Q6: Can I see exactly what the agent is doing?

Q7: Is it smooth on 4G/5G?

Q8: Do I need an app? Any setup?

Q9: "Zero dependencies" — really? Is deployment easy?

Q10: What's the relationship with DeepSeek official?

Verdict

The 5 agent tasks I most often run from my phone: a real list

The 5 agent tasks I most often run from my phone: a real list

Task 1: Dispatch on the commute, collect the result on arrival

Task 2: Tweak config before bed, find it verified in the morning

Task 3: Tap approvals mid-meeting

Task 4: Quick code lookups from the couch

Task 5: Model comparison experiments

The common thread

The toolkit

From "a thought in bed" to open source: one week of development diary

From "a thought in bed" to open source: one week of development diary

Day 1 · 1 a.m., a thought

Day 2 · First version: a working "translator"

Day 3 · Deadlocked all day: ask_user_question

Day 4 · Make the work visible

Day 5 · Terminal, files, tasks: from usable to useful

Day 6 · Polishing

Day 7 · Open source

A week later, now

Try it

The agent's next stop is your pocket: why mobile may be the agent's best form

The agent's next stop is your pocket: why "mobile" may be one of the agent's best forms

Agent usage is moving from "sit down" to "anytime"

Mobile isn't a "shrunk webpage" — it's a new paradigm

My answer: an open-source project that puts the agent in your pocket

Your turn

Watching my agent work from the phone and the desktop at the same time

Watching my agent work from the phone and the desktop at the same time — I can't go back

The test: one task, both screens

Why mobile is better at some things

Your agent casually asked a question and froze the queue for 10 minutes — how do you all handle `ask_user_question`?