Redock starts from a practical mobile problem: coding agents now do meaningful work in terminal TUIs, but phones need better controls for steering those sessions. SSH is the transport. The product challenge is everything around the transport: context, input, repeated tasks, session survival, and returning to the right piece of work after interruption.
That is why Redock is better described as an AI coding mobile workbench than as a traditional SSH app. The target workflow is not "open a remote shell and type everything." The target workflow is "open the right project, start or resume the agent, send a clear instruction, run verification, and keep work alive while the phone comes and goes."
Project context changes the starting point
Many mobile terminal sessions fail before the first useful command. You connect successfully, but then you need to remember the project path, current branch, test command, agent command, and whether there was already a tmux session. The connection exists, but the development context is missing.
Redock introduces Projects so the working context has a stable place. A Project can represent a repository on a Mac, a service on a VPS, a production log directory, or a personal automation workspace. It gives repeated mobile work a named entry point.
A useful Project usually answers four questions:
- Which Host should this work run on?
- Which directory should the terminal enter first?
- Which snippets or commands are relevant here?
- Which recent sessions or Runs belong to this work?
That structure matters because mobile time is often fragmented. The faster you return to context, the more likely you are to do useful work from the phone.
Actions turn tasks into mobile controls
Actions are Redock's way to make repeated development tasks explicit. Instead of retyping a command, you save it with a name and choose how it should run.
For agent workflows, the mode matters as much as the command:
| Task | Example | Good run mode |
|---|---|---|
| Talk to an agent | codex, claude --resume, opencode |
Terminal Interactive |
| Check current state | git status --short |
Quick Task |
| Run focused tests | npm test -- login |
Quick Task |
| Run a long build | npm run build |
Background Long Task |
| Follow logs | tail -f logs/app.log |
Terminal Interactive or tmux |
This gives mobile work a clear shape. An agent session stays interactive. A quick check leaves output. A long task can run in tmux and survive the phone leaving the app.
Agent TUI first
Claude Code, Codex, OpenCode, and similar agents are conversational, long-lived, and stateful. They run inside terminal interfaces, but their interaction pattern is not the same as a short shell command. You read a lot, scroll back, copy output, send paragraph-length prompts, and often keep the session alive for a long time.
Redock keeps the terminal central while improving the controls around it:
- Scrolling and history behavior must work on a touch screen.
- Copy, paste, and selection need to coexist with terminal gestures.
- CJK input has to be reliable for mixed-language development prompts.
- Long prompts should be composed before being sent.
- Agent snippets should be close enough to run without retyping.
- Multiple connections and sessions should not collapse into one confusing state.
For AI coding, the terminal is not just a console. It is the conversation surface for the agent.
Prompt input matters
Agent instructions are often paragraphs, not single shell commands. A developer might need to mention a failing test, a constraint, a file path, and a preferred implementation direction in one prompt. On mobile, direct terminal typing is the wrong place to assemble that text.
Staged input gives the prompt a buffer. You can write, paste, dictate, edit, and only then send. This design is especially useful for:
- Long natural-language agent instructions.
- Mixed Chinese and English prompts.
- Commands that include file paths or code symbols.
- Corrections after reading a test failure.
- Prompts drafted from voice transcription.
The difference is small but important: mobile input becomes prepared intent instead of fragile keystrokes.
Recovery matters
Mobile networks change. Apps go to the background. A coding agent may continue thinking, editing, running tests, or waiting for confirmation while the phone is no longer connected. If the process belongs only to the current SSH connection, the workflow is brittle.
Redock puts tmux recovery close to the normal flow. You can create or attach sessions from the Host or Project context, run long tasks in tmux, and return to existing work through Activity or connection pickers. The remote machine keeps the work. The phone returns when it can.
This is useful for long agent sessions, builds, database migrations, log watching, and anything that should not depend on the mobile app staying foregrounded.
What makes Redock different in practice
The product difference shows up in small repeated moments:
- You open a Project instead of remembering a path.
- You tap an Action instead of retyping the launch command.
- You dictate a paragraph prompt, review it, and send it to the agent.
- You run a build as a background task and leave the phone.
- You reopen Redock and attach to the tmux session that kept running.
- You inspect recent Run output instead of hunting through scrollback.
These details are easy to underestimate from a desktop mindset. On mobile, they decide whether a development task is actually reachable.
Quick answer
Redock is different because it is designed around the mobile lifecycle of AI coding work: Project context, reusable Actions, agent TUI input, staged prompts, speech transcription, tmux recovery, and visible activity. SSH connects the device to the machine, but Redock organizes the development workflow around that connection.