Confirm that the Host is reachable
Redock can reconnect through SSH or Mosh after the network path becomes available.
Workflows
02 / Stay connected
Keep long-runningAI coding sessions alive
Keep AI coding agents running through temporary disconnects and reconnect to your session when you are ready.
The agent is running in a tmux session on the development machine.
The phone is the current connection point; the code, terminal processes, and coding agent remain on the remote host.
- tmux session stays on the host
- Agent uses the development environment
- Reconnect when the path returns
IN THIS WORKFLOW
The connection can change while the session stays in place
This workflow explains how Redock works with tmux, SSH, and Mosh to separate a long-running coding-agent session from the current phone connection and return to it after a temporary disconnect.
- 01
Why a long task should not depend on one mobile connection
- 02
How a connection differs from a running session
- 03
How tmux keeps the session on the host
- 04
How Mosh responds to network changes
- 05
How to return to the original session
- 06
Which AI coding tasks benefit most
00
BEFORE YOU START
Put the coding agent inside a tmux session you can reattach
Persistence does not require the phone to stay online. It requires the agent to start inside a tmux session on the development machine.
Keep the host powered on, install tmux and the coding agent you use, then configure the host in Redock through SSH or Mosh.
- A development machine that can keep the task running
- tmux installed on the host
- An SSH or Mosh Host configured in Redock
- Claude Code, Codex, or OpenCode installed and signed in
Development machine terminalshell
cd ~/projects/your-app
# Create or re-enter a named tmux session
tmux new-session -A -s ai-coding
# Start the coding agent inside tmux
claude # or codex / opencodetmux can preserve only a session that still exists on a running host. Shutdowns, restarts, sleep, or an agent process exiting produce different results.
01
THE PROBLEM
The connection is often what changes, not necessarily the task
An AI coding task may run for tens of minutes while the agent reads the project, edits files, and runs tests.
During that time, the phone may lock, Redock may enter the background, Wi-Fi may become cellular, or the network may briefly disappear.
The important distinction is whether the phone can currently reach the host and whether the agent session still exists on that host.
Does the remote process remain after the phone locks?
What changes when Wi-Fi becomes cellular?
Can you return to the same output and context?
If the task depends on the current client connection, a disconnect makes the state difficult to recover.
Inside tmux, the session stays on the host. When the connection returns, you re-enter instead of restarting.
The task starts at the desk without depending on that client forever.
The repository, dependencies, tmux, and coding agent remain on the development machine.
You can leave the desk while the remote session handles the long-running task.
02
THE WORKFLOW
Keep the session on the host and allow the connection to be rebuilt
The goal is not to promise an uninterrupted phone connection. It is to make the running session independent of one continuous client connection.
tmux keeps the terminal session and agent process on the development machine. SSH or Mosh provides the path to the host, and Redock returns to the tmux session when that path is available.
During a temporary network change, the client may wait or disconnect while the agent continues remotely if the host and session remain healthy.
- 01
Start the agent inside tmux
Create a named session in the project and launch the terminal-based coding agent.
- 02
Keep the task on the host
The repository, dependencies, Git state, and agent process use the real development environment.
- 03
Allow the connection to change
The phone may lock, enter the background, or move between networks.
- 04
Reconnect to the original session
When the path returns, use Redock to open the same Host and tmux session.
Find and re-enter the tmux sessionshell
tmux list-sessions
# Re-enter the AI coding session
tmux attach-session -t ai-codingIf the session still exists, attaching returns to its current state rather than creating a new agent task.
The connection can wait while tmux keeps the session on the host.
Mosh may wait for the UDP path to recover during a network change.
That connection state does not mean the remote tmux session has ended. Recovery still depends on the host, network, and Mosh configuration.
03
RECONNECT
When you return, first confirm that the session still exists
Reconnecting does not rebuild the development environment. Return to the same Host, inspect existing tmux sessions, and re-enter the one containing the agent.
Confirm that the Host is reachable, the session exists, and the agent is still working, finished, or waiting for input.
Find the named tmux session
A clear session name identifies the project and task instead of opening an empty Terminal.
Review the agent state
The agent may still be working, may have finished, or may be waiting for a decision.
Continue from existing context
Reply in the original session or review the completed result without restarting the task.
After reconnecting to the Host, confirm:
Return to the original sessionshell
tmux list-sessions
tmux attach-session -t ai-coding
Return to the existing tmux session and continue.
The restored view is the session already running on the development machine, not a blank new task.
Its terminal output and agent state remain available for review or response.
04
A REAL SCENARIO
On the way to lunch, return to Claude Code still running on your Mac
At 12:06, before leaving the office, you start Claude Code in a tmux session named ai-coding and ask it to refactor an authentication module.
At 12:18, the phone locks and leaves office Wi-Fi. The current Redock connection becomes unavailable, while the tmux session and Claude Code remain on the Mac.
You left the connection, not the task
This is one tmux session continuing across the desktop, a disconnect, and a later mobile check-in.
- You · Mac12:06
Separate the token refresh logic in the authentication module. Keep the public API unchanged and run the authentication tests.
- Claude Code · ai-coding12:07
I will inspect the module and tests, refactor in stages, then run the relevant test suite.
- Connection12:18
The phone locks and leaves office Wi-Fi. Mosh waits for the network path to recover.
tmux: ai-coding · running on Mac - Claude Code · original host session12:31
The refactor is complete. 48 tests pass and one fails because of a refresh-token expiry assertion.
The output remains in tmux until you return. - Redock · iPhone12:34
The network is available again. You open the same Host and attach to ai-coding.
Welcome back · attached to existing session - You · Redock12:35
Update the test too, but keep the public API unchanged. Then rerun the authentication tests.
- Claude Code · original session12:36
Understood. I will update the assertion and rerun the tests without changing the public API.
- 01Agent runs inside tmux
- 02Phone locks or changes networks
- 03Connection becomes unavailable
- 04Redock reconnects
- 05Return to the original session
The check-in may take less than a minute because the project, agent, and terminal context already exist on the host.
This does not promise instant recovery under every network condition. The Host and network path must become available before Redock can re-enter the session.
05
HOW REDOCK SUPPORTS THE WORKFLOW
Three layers create a reconnectable remote session
tmux, SSH, and Mosh are not interchangeable features. They handle session persistence, secure access, and changing mobile networks.
tmux
Separate the session from the current client
The coding agent runs in a tmux session on the host, allowing the session and active processes to remain after the phone leaves.
SSH
Provide the secure connection to the host
SSH establishes the remote terminal connection. You can reconnect through SSH and attach to an existing tmux session without Mosh.
Mosh
Handle changing mobile network conditions
Mosh supports roaming, temporary packet loss, and network changes, then attempts to continue when the UDP path returns. Results still depend on the server and network.
06
HOW THE LAYERS DIFFER
Connection availability and session persistence are separate questions
- Connection: SSH / Mosh
- Session: tmux
- Execution: Host and agent
- Mobile entry point: Redock
SSH or Mosh determines how the phone currently reaches the host; tmux determines whether the terminal session exists independently of that connection.
When Mosh waits for recovery, the connection layer is responding to network changes. The coding agent may continue if the Host and tmux session remain healthy.
Redock exposes these choices separately: Mosh can be the connection mode while tmux provides session persistence. This explains the architecture without promising recovery in every circumstance.
tmux preserves the session. Mosh handles the connection path.
The coding agent and tmux session run on the development machine.
Redock reaches the Host through SSH or Mosh and re-enters the session after the path returns.
- 01Agent runs inside tmux
- 02Connection may change
- 03Reconnect to the session
PhoneMosh / SSHtmuxCoding Agent
07
WHEN IT FITS
Long tasks, changing networks, and repeated check-ins
Long agent refactors
The task spans multiple edits and checks and should not depend on one continuously connected phone.
Long tests, builds, or scripts
Keep the execution context in tmux and return later to review the result.
Frequent phone locks or backgrounding
The client state should not be the only lifecycle controlling the remote session.
Movement between Wi-Fi and cellular
Use Mosh for the changing connection and tmux for the host-side session.
For a task lasting only seconds, an ordinary SSH Terminal may be enough. This workflow is most useful when work continues for a while and you expect to leave and return.
08
THE RESULT
Reconnect the path and continue the original session
Connection and task coupled together: every disconnect raises concern that the agent context is gone.
Connection and session separated: tmux keeps the host-side context and Redock returns after the path recovers.
Long-running AI coding does not require the phone to stay online forever. It requires the execution environment and session to have a lifecycle independent of the client.
tmux keeps the session on the host, SSH or Mosh provides the current path, and Redock returns the phone to that session.
The sequence becomes: session runs remotely, connection changes, user reconnects, and work continues from the original context.
The outcome still depends on the Host being online, the agent process running, the tmux session existing, and the network path becoming available.
09
COMMON QUESTIONS
tmux, Mosh, and long-running coding sessions
Does tmux guarantee that the coding agent never stops?
No. tmux separates the session from the client connection, but shutdowns, restarts, sleep, resource limits, or the agent process exiting can still stop the task.
What is the difference between Mosh and tmux?
Mosh improves the terminal connection during IP changes and temporary interruptions. tmux keeps the terminal session and its processes on the remote host.
Can I reconnect to tmux using SSH without Mosh?
Yes. Re-establish SSH and attach to the tmux session if it still exists. Mosh is not required for tmux persistence.
Does a tmux session survive host sleep or restart?
Do not assume that it does. tmux depends on the Host and its processes continuing to run.
Does this workflow support Claude Code, Codex, and OpenCode?
Yes. A terminal-based agent running inside tmux can be revisited through Redock after the Host reconnects.
下一篇 Workflow
Control AI coding agents from your phone
STAY CONNECTED
Let the connection pause while the coding session keeps running
Connect Redock to the development machine, keep long-running AI coding sessions in tmux, and return from your phone after the network path recovers.
在 App Store 下载