A good SSH client is valuable. It should connect reliably, render terminal output, handle keys, and stay out of the way. SSH is still the foundation for many remote development workflows. But coding-agent work on a phone creates requirements that plain SSH clients were not designed to own.
The difference is not whether SSH matters. It does. The difference is whether the product stops at remote shell access or helps you move through the development loop: choose a project, start an agent, send a prompt, run verification, keep work alive, inspect results, and resume later.
A shell connection is not the full workflow
When you open a terminal, it does not know which repository matters, which command starts the agent, which test command is safe to run, or which tmux session belongs to the current task. You have to rebuild that context manually.
On a laptop that is annoying. On a phone it is the difference between a useful check-in and a session you abandon.
For agent-driven development, the repeated context usually includes:
- The Host you want to connect to.
- The working directory for the current repository.
- The agent launch command.
- The branch, test command, build command, or log command.
- The tmux session that should survive disconnection.
- The recent output you need before sending the next instruction.
If every mobile session starts by reconstructing that list, the tool technically works but the workflow remains fragile.
Coding agents need repeatable entry points
Agent workflows have common moves: start the agent in a project directory, resume a previous session, run a verification command, tail logs, check Git, or start a background job. These should be fast to trigger from a phone, not retyped from memory every time.
Redock uses Projects and Actions to make those entry points explicit. A Project gives the terminal a working context. An Action gives a repeated task a name and a run mode.
That distinction matters:
| Need | Plain SSH habit | Redock workflow |
|---|---|---|
| Open a repository | Type or paste cd ... |
Open a saved Project |
| Start an agent | Retype command | Tap an agent Action |
| Run tests | Remember exact script | Run a saved verification Action |
| Keep work alive | Manually manage tmux | Use tmux-aware session entry points |
| Review output later | Scroll terminal history | Use Run output or Activity |
| Send long prompt | Type directly into shell | Compose in staged input first |
The point is not to hide the terminal. The point is to reduce the mobile steps around the terminal.
Results should be easy to revisit
A quick check should produce output you can inspect later. A background task should expose logs. A long interactive agent session should be recoverable. Traditional SSH clients often leave these distinctions to the user.
That creates ambiguity on mobile. Did the command finish? Did it fail after the app went into the background? Which session contains the output? Is the agent still running, or did the network disconnect kill the process?
For development work, these states are product-level concerns. A mobile workbench should make them visible because the user is often moving between networks, apps, and attention contexts.
Mobile input is different
Typing raw shell input on a phone is slow. Agent prompts are often paragraph-shaped. They contain intent, constraints, file names, test names, and follow-up instructions. Sending that kind of prompt one character at a time through a terminal line is a poor mobile interface.
Useful mobile input needs a buffer. You should be able to draft, edit, paste, dictate, and review before sending. This is especially important for CJK input, mixed Chinese-English prompts, command names, paths, and code symbols. A small transcription mistake is acceptable while drafting. It is not acceptable if the text is blindly sent to the shell.
Redock's staged input, snippets, and speech transcription are designed around that difference.
When a normal SSH client is enough
A traditional SSH client is enough when you only need occasional server access, a quick command, or direct terminal control from an external keyboard. It is also enough when you already know the exact command and do not need session recovery or saved context.
Redock becomes more useful when the work is repeated, agent-driven, long-running, or mobile-first:
- You switch between multiple projects.
- You use Claude Code, Codex, OpenCode, or similar terminal agents.
- You often run the same tests, builds, logs, or deploy checks.
- You want long tasks to survive app backgrounding or network changes.
- You want to dictate or stage longer prompts before sending.
Quick answer
SSH gives remote access, but AI coding workflows need more than access. They need project context, saved Actions, agent-friendly input, recoverable tmux sessions, visible task output, and a way to resume work after mobile disconnection. That is the layer Redock adds around the terminal.