Continue AI Coding Agent Sessions From Your Phone Like a Chat

1. The Problem: The Agent Runs on Your Desktop, but You Are Rarely There

AI coding assistants—call them coding agents—work in a fundamentally different way from traditional completion tools. They read repositories on their own, edit multiple files, run commands, and execute test suites, and a single task often lasts anywhere from a few minutes to tens of minutes. That combination of “long wait plus human confirmation required at critical points” collides directly with how developers actually work: builds are running, tests are running, a refactoring plan is being weighed, and meanwhile the person is in a meeting, commuting, eating, or simply away from the desk.

Conventional setups bind the interaction layer directly to a local terminal: the process’s input and output hang off the current TTY, and session context dies with the terminal. The moment you step away, you are out of the loop. The usual workaround is to “deal with it when I get back”—long tasks sit idle—or to move to a cloud development environment (remote desktop, browser IDE) and start over, losing the context.

The ideal shape is to decouple the agent’s execution from the human interaction entry point: the agent keeps running on the computer (or a remote host), the interaction channel becomes a message stream that multiple clients can take over, and the phone is just one lightweight client among them. That is the engineering meaning of “continue a coding session like a chat,” and it is what the rest of this article unpacks.

2. Capability Breakdown: What a Usable Mobile Handoff Must Have

Abstracting the original requirement into a capability list yields five layers. Missing any one of them shows up quickly in real use:

1. Session decoupling layer — the agent process’s I/O is detached from the terminal; output lands as a structured event stream that any client can subscribe to.
2. Control layer — an explicit answer to “who is the single writer,” with safe handoff between desktop and phone so that two endpoints never inject instructions simultaneously and scramble state.
3. Transport and synchronization layer — long-lived connections plus event numbering plus a replay mechanism, so state can still converge across flaky networks, network switches, and an app being backgrounded.
4. Security layer — trustworthy pairing, encrypted transport and storage, keys that never touch the server, and source code and prompts that are not left exposed.
5. Notification layer — event classification, aggregation and debouncing, and escalation paths, so that “push every log line” does not end in notification fatigue.

The rest of the article goes through the design points layer by layer.

3. Reference Architecture

┌──────────────┐         ┌──────────────────┐         ┌──────────────┐
│ Desktop Agent│◄───────►│  Local bridge    │◄───────►│ Mobile / Web │
│ (coding agent)│ event  │  daemon          │ long-lived│  clients    │
│               │  stream │ (session host +  │  conn.   │             │
│               │         │  PTY)            │          │             │
└──────────────┘         └────────┬─────────┘         └──────────────┘
                                  │ encrypted tunnel (optional relay)
                          ┌───────▼────────┐
                          │  Relay/signaling│  forwards ciphertext only,
                          │  service        │  never holds session keys
                          └────────────────┘

The key point: the bridge daemon (the agent-side host) is the single source of truth for the session. The mobile client does no business computation—it renders events, sends decision commands, and shows diff summaries. The relay service only carries ciphertext when the two ends cannot connect directly (different networks, failed NAT traversal); it should not store or parse plaintext.

4. Design 1: Decoupling Session State From Terminal I/O

Do not wrap the agent in a “screen mirroring” layer (capturing terminal frames as images or forwarding raw escape sequences). That leaves the phone with a stream of ANSI control codes—hard to render and impossible to interact with. The more robust approach is a structured event model:

// Base event: the monotonically increasing seq is the sole basis for replay and dedup
{
  "seq": 1042,
  "session": "frontend-auth",
  "ts": 1756240000123,
  "type": "message.delta",
  "payload": { "role": "assistant", "text": "Editing src/auth/session.ts" }
}

The common event types should be narrowed to a finite set:

Type	Meaning	Mobile client handling
message.delta	Streaming text increment	Append and render
tool.start / tool.end	Tool invocation (read file, run tests)	Collapse into a one-line status
approval.request	High-risk action requiring human confirmation	Dialog + push notification
diff.summary	Changed files and line counts	Summary card, expandable on demand
task.done / task.error	Terminal task state	Push + vibration
control.changed	Control handoff	Update available UI state

Only once the output is structured does “chatting on the phone” become possible: text increments render directly as conversation bubbles, tool calls collapse, and high-risk actions can be intercepted. The original terminal byte stream is replayed only when the user explicitly asks to “view raw output.”

5. Design 2: Single-Writer Control and Preemption

The number one risk of multi-client takeover is double writing: you press Enter on the desktop, the phone sends “continue” at the same moment, the two instructions interleave, and the agent’s context immediately becomes untrustworthy. Three rules apply:

• Single writer — at any instant, exactly one endpoint holds the control lease; all others are read-only observers.
• Explicit handoff plus local preemption — when the desktop detects local keyboard input it takes control back automatically (no command needed); the phone requests control through a “Take over” button. Every handoff must broadcast control.changed.
• Lease expiry on timeout — the lease carries a heartbeat and expires automatically past a threshold (for example, 30 seconds without a heartbeat), so a crashed phone cannot lock the desktop out permanently.

# Control lease decision logic (illustrative)
class ControlLease:
    def __init__(self, ttl=30.0):
        self.holder = None      # "desktop" | "mobile:<device_id>"
        self.deadline = 0.0
        self.ttl = ttl
    def try_acquire(self, who: str, now: float, force=False) -> bool:
        alive = self.holder is not None and now < self.deadline
        if not alive or force:          # local keyboard input = force preemption
            self.holder, self.deadline = who, now + self.ttl
            self.broadcast_changed(who)
            return True
        return False
    def heartbeat(self, who: str, now: float):
        if self.holder == who:
            self.deadline = now + self.ttl

The companion mechanism is input isolation: in read-only mode the phone’s input field should be disabled with a visible explanation, not accept input and fail silently—silent failure is the most common experience defect in tools like this.

6. Design 3: Reliable Delivery and State Convergence on Unstable Networks

Mobile networks are inherently unstable: switching cells in a subway, the app being suspended by the system after backgrounding, handoff between Wi-Fi and 5G. Making the experience feel uninterrupted requires three things:

1. Event numbering plus incremental replay — the client records the highest seq it has consumed and sends last_seq on reconnect to request the remainder. The server keeps a bounded ring buffer of events (for example, the most recent 5000 events or 30 minutes); once requests fall outside that window, it degrades to a full snapshot.
2. Idempotent deduplication — the same command may be sent twice because of a retry, so commands carry a client-generated client_msg_id and the server deduplicates on that ID.
3. Exponential backoff with jitter — min(2^n * 500ms, 15s) ± jitter, to avoid a thundering herd of reconnects overwhelming the relay the moment the network comes back.

async def resync(session, client):
    snapshot = await session.snapshot()          # context summary + last N messages
    await client.send({"type": "snapshot", "payload": snapshot})
    since = client.last_seq                    # reported by the client
    async for ev in session.events_since(since):
        await client.send(ev)                  # replay in ascending seq order
    await client.send({"type": "sync.done"})

Until sync.done arrives, the client should show a “Syncing…” placeholder rather than rendering replayed history as new messages.

7. Design 4: Trusted Pairing and End-to-End Encryption

Code, keys, and internal addresses are all highly sensitive assets; security design cannot be retrofitted later.

• Pair with one-time credentials — the desktop displays a short-lived pairing code or QR code. The QR code embeds a one-time public key, the server’s public key fingerprint, and a short session identifier; scanning it completes the key exchange and the credential is consumed (TTL of 60–120 seconds is a reasonable range), so a photographed QR code does not stay valid indefinitely.
• No key agreement on the server — the two ends derive a symmetric session key through elliptic-curve key exchange (for example X25519); the server sees only ciphertext. Messages are encrypted with AEAD (AES-GCM or ChaCha20-Poly1305) and bound to seq, which provides confidentiality plus tamper resistance and replay protection.
• Fingerprint verification against man-in-the-middle — after the first connection, the client shows a short key fingerprint code; the two devices compare it manually once to anchor trust, then reuse the stored public key. Any change triggers a warning.
• Device revocation and rotation — if a phone is lost, you can revoke that device_id from the desktop in one action and rotate the session keys. Pairing keys should be rotated periodically rather than reusing one credential indefinitely.
• Minimize the transport path — connect directly whenever possible (same LAN, intranet tunneling, VPN). When traffic must go through a public relay, the relay forwards ciphertext packets only and enforces rate limits, connection counts, and source checks.

# Session key derivation and message sealing (illustrative)
sk_shared = x25519(my_priv, their_pub)          # shared secret, exists only on the two ends
k = hkdf(sk_shared, salt=session_id, info=b"happy-bridge-v1")
nonce = aead_nonce(seq)                          # nonce bound to seq
ct = aead_encrypt(k, nonce, plaintext, aad=seq.to_bytes(8, "big"))

8. Getting Started: From Zero to Usable

# 1) Install the bridge daemon on the machine hosting the agent
#    (use your language ecosystem's package manager)
pipx install <agent-bridge-cli>          # or the equivalent for your ecosystem
# 2) Start a session in managed mode, named so you can recognize it on the phone
<agent-bridge-cli> --name "frontend-auth" --workdir ~/src/web
# 3) The daemon prints a pairing QR code and a short code (limited TTL, watch
#    out for screen savers)
#    ┌──────────────────────────────┐
#    │  Scan to pair  |  Code 482 913 │
#    └──────────────────────────────┘
# 4) Scan from the phone client to complete key exchange and enter the session list
# 5) When you need to leave, tap "Take over" on the phone; press any key back at the
#    desktop and control returns to the local machine automatically

Two engineering details are worth emphasizing. First, declare the working directory explicitly so the agent cannot perform write operations in the wrong repository. Second, validate at startup (branch, uncommitted changes, whether a build is already running) so the risks surface up front, instead of the phone discovering mid-commute that you edited the wrong repository.

9. Parallel Sessions: Namespaces, Not Memory

Pushing frontend, backend, and database tasks forward at the same time is normal. The workable way to manage it is a separate namespace per session:

<agent-bridge-cli> --name "web-auth"    --workdir ~/src/web      --branch feat/oauth
<agent-bridge-cli> --name "api-order"   --workdir ~/src/api      --branch feat/idempotent
<agent-bridge-cli> --name "db-schema"   --workdir ~/src/migrate  --branch chore/indexes

Three practical rules go with it:

• One repository per session — running two agents in the same working directory in parallel means they fight over file locks and build artifacts.
• Session labels and priority — tag sessions “running / awaiting confirmation / failed” and have the phone sort by “needs my decision” rather than by creation time.
• Context isolation is not context loss — before switching sessions, keep a summary snapshot (what is done, current assumptions, open items) so you can rebuild your mental model quickly when you switch back.

10. Notification Tiering: Push Only When It Matters

Pushing every event is equivalent to having no notifications. A three-tier classification plus quiet-hours rules works well:

Level	Trigger condition	Channel	Policy
P0 blocking	Approval requests, destructive operations (delete, force push, production config changes)	Push + sound + vibration	Deliver immediately, may repeat
P1 done/failed	Terminal task state, test failures, build errors	Push, deferred during quiet hours	Aggregated per session, merged into one within 5 minutes
P2 progress	Tool invocations, interim explanations	In-app only	No push

It is also worth adding a heartbeat-style long-task reminder: if a single task produces no events for longer than a threshold (say 20 minutes), notify once. That is how you spot an agent stuck in a retry loop—this kind of “silent hang” wastes more time than an outright error.

11. Security Boundaries and Operational Observability

A few red lines are non-negotiable. The relay carries ciphertext only. Pairing credentials are one-time. Devices can be revoked. High-risk actions require secondary confirmation by default—especially git push, database migrations, dependency installation, and reading production configuration. The mobile client caches no credentials in plaintext; tokens go into the system secure storage. Logs are redacted, and full prompts and keys must never be written to searchable server-side logs.

On the operational side, track the metrics that map directly to perceived quality: end-to-end message latency (P50/P95), event backlog length, reconnect count and mean recovery time, control lease overlap duration (which should always be zero), and P0 notification delivery rate. Non-zero lease overlap means the lease implementation is broken—a serious defect that must be fixed.

12. Mapping Cloud Deployment Requirements to General Capabilities

For enterprise intranets or multi-developer shared deployments, the relay and gateway usually need to run in the cloud. These requirements map onto general cloud product categories rather than any proprietary solution: use a container platform to host the stateless relay and gateway (for elastic scaling and rolling upgrades), object storage to archive session records and audit snapshots with lifecycle policies, a message queue to absorb spikes and decouple the event stream from notification delivery, a logging service with monitoring and alerting to cover connection quality, backlogs, and anomalous logins, and a key management service to hold server certificates and rotation keys—combined with private networking, access control, and the gateway for source restrictions. On Baidu AI Cloud, needs like these are typically covered by a combination of such general-purpose capabilities; check the relevant product documentation for specific specifications and quotas.

One caveat: if code assets are not permitted to leave the intranet, the correct approach is to deploy the entire relay privately rather than depend on a public cloud relay. Encryption protects data in transit; it does not change data residency compliance requirements.

13. Anti-Patterns and a Recommended Workflow

Anti-patterns

• Doing large-scale refactoring, broad diff reviews, or long continuous conversations on a phone—screen size and input efficiency make the payoff minimal.
• Keeping a read-only connection open while constantly sending commands, ending with inconsistent state on both ends. Diagnosing that costs more than restarting the task.
• Printing, posting, or leaving a pairing QR code valid long-term, which is equivalent to publishing write access to your repository.
• Solving mobile access with “screen mirroring” forwarding, which yields a pile of escape sequences you cannot interact with.

Recommended workflow

1. Prepare context on the desktop (branch, dependencies, baseline tests), then start a managed session.
2. Hand long tasks to the agent and use the phone for three things only: reviewing progress summaries, approving critical checkpoints, and sending short follow-up instructions.
3. Confirm all destructive actions back at the desktop.
4. After the session ends, archive the diff on the desktop, run the full test suite, and open the review.

Conclusion

“Continue an AI coding session from your phone like a chat” is not fundamentally a client UI problem; it is a distributed session problem: state ownership, write mutual exclusion, reliable delivery, and key trust. Get those four right and the mobile client is just a thin client. Get them wrong and no amount of polished interface will survive the first network switch or the first simultaneous input from both ends. And the real payoff is not whether the phone can write code—it is that long-running tasks stop idling just because you left your desk. Give the waiting time back to people, and spend their attention on decisions.