[FEATURE] Expose ACP over network transport (`claude serve`) for remote/mobile session attach

Resolved 💬 4 comments Opened Feb 9, 2026 by colonelpanic8 Closed Mar 14, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

There is no way to attach to a running Claude Code session from another device. If you start a long agentic task on your workstation and step away, you cannot monitor progress or respond to approval prompts from your phone or another machine.

The current workaround is SSH + tmux, which works but provides no structured interaction — you're just staring at raw terminal output on a phone screen with no way to one-tap approve, no push notifications, and no awareness of session state.

Why a protocol-level solution matters

The community has built 20+ third-party projects to work around this limitation — mobile apps (Happy Coder, 10.8K stars; Omnara, YC S25, 2.6K stars; Claude Remote; Termly; Moshi; Sled), web UIs, Discord/Telegram/email bridges, and more.

Every one of these projects reinvents the same plumbing: screen-scraping terminal output, building custom encrypted relays, polling PTY sessions for approval prompts, and maintaining internal adapters that break when Claude Code updates. This is the same fragmentation that existed before LSP standardized editor-language server communication.

Prior art: this is already solved elsewhere

OpenCode ships native client-server separation today:

opencode serve                              # headless server
opencode web --port 4096 --hostname 0.0.0.0 # web UI  
opencode attach http://10.20.30.40:4096     # attach from anywhere

Codex has an app-server exposing bidirectional JSON-RPC 2.0 with full session lifecycle (thread/start, thread/resume, thread/fork), approval workflows (requestApproval), and event streaming. Their TUI is being refactored to connect to remote app-server instances.

Both prove the architecture works. Neither speaks a standard protocol.

Proposed Solution

Claude Code already supports ACP (Agent Client Protocol) as a subprocess. The request is to also support ACP over a network transport — Unix socket, TCP socket, or HTTP/WebSocket — so that remote clients can attach to a running session.

Something like:

# Listen on a Unix socket (ideal for SSH access — no port forwarding needed)
claude serve --socket /tmp/claude.sock

# Or listen on a TCP port  
claude serve --port 3284

# Attach from the same machine, or over SSH
claude attach /tmp/claude.sock
claude attach host:3284

This would let any ACP-compatible client — including potential mobile apps, web UIs, or tools like Toad (2.1K stars, universal ACP terminal client) — connect to a running Claude Code session without custom plumbing.

Why ACP over network, not a custom API

ACP already defines the message semantics (prompts, streaming responses, tool calls, approval requests). It has adoption from Zed, JetBrains, GitHub Copilot CLI, Gemini CLI, and Claude Code itself (#6686, 439 upvotes). Adding network transport is a small extension to what already exists — not a new protocol.

This would also make every existing third-party mobile/remote project simpler and more maintainable, since they could speak ACP directly instead of building fragile wrappers.

Related issues

  • #6686 — ACP support (editor integration, 553 reactions)
  • #15922 — Mobile companion app (14 upvotes)
  • #24145 — Bidirectional session sync CLI ↔ Web
  • #14666 — Universal session teleporting
  • #15208 — SSH connector

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗