Mobile clients constantly drop and resume connections (background/foreground, network switches, app restarts). This issue tracks what’s currently missing or underspecified in ACP to make that experience reliable.
The mobile lifecycle
A standard flow:
- User sends a prompt.
- App backgrounds.
- Connection drops and later reconnects.
- Client
session/load / session/resume.
- UI must immediately choose: Stop (turn still running) vs Run (idle).
Today that UI decision is not deterministic without client heuristics, mainly because “turn is active” is not a canonical, replay-safe state in the protocol.
Reconnect-safe, deterministic turn state
Canonical active-turn state after session/load / session/resume
We need an explicit protocol-level source of truth for:
“Is a turn currently active right now?”
- optional
activeTurn (or activeTurnId + minimal metadata) in session/load and session/resume responses.
- or require a specific
session/update subtype that carries current turn state during replay/load.
Why: after load/resume, the client must be able to render Stop vs Run without guessing.
Turn identity on streamed updates
We need stable turn identity (e.g. turnId) on all turn-scoped session/update payloads.
Why: clients must be able to group streamed assistant chunks, tool calls, tool outputs, and other turn-scoped updates, especially after reconnect.
Replay safe sequencing
We need monotonic event id / sequence number + a replay cursor (e.g. since=...).
Why: this is the only way to guarantee clients don’t miss or duplicate updates after reconnect (unless we always request another "session/load"
Related ACP prior proposal: https://github.com/agentclientprotocol/agent-client-protocol/blob/main/docs/rfds/message-id.mdx
Remote / mobile usability
Remote-safe auth (non-terminal path)
On mobile, terminal-driven auth isn’t a reliable default.
ACP might need a clear non-terminal auth handoff: browser/device style auth (OAuth link / device code flow) + an observable completion state the client can poll/subscribe to.
Related discussion: https://github.com/orgs/agentclientprotocol/discussions/139
Client reads files from agent host (reverse of client fs/*)
ACP supports agent access to client FS via fs/*. Remote/mobile clients need the reverse: a standard client → agent file read.
Why: we need a consistent way to fetch artifacts/logs/outputs produced in the agent environment.
WebSocket as the recommended baseline transport
For long-lived bidirectional sessions on remote/mobile, WebSocket can be explicitly recommended as the baseline transport in ACP docs/guidance.
Related discussion: agentclientprotocol/agent-client-protocol#476
Mobile clients constantly drop and resume connections (background/foreground, network switches, app restarts). This issue tracks what’s currently missing or underspecified in ACP to make that experience reliable.
The mobile lifecycle
A standard flow:
session/load/session/resume.Today that UI decision is not deterministic without client heuristics, mainly because “turn is active” is not a canonical, replay-safe state in the protocol.
Reconnect-safe, deterministic turn state
Canonical active-turn state after
session/load/session/resumeWe need an explicit protocol-level source of truth for:
activeTurn(oractiveTurnId+ minimal metadata) insession/loadandsession/resumeresponses.session/updatesubtype that carries current turn state during replay/load.Why: after load/resume, the client must be able to render Stop vs Run without guessing.
Turn identity on streamed updates
We need stable turn identity (e.g.
turnId) on all turn-scopedsession/updatepayloads.Why: clients must be able to group streamed assistant chunks, tool calls, tool outputs, and other turn-scoped updates, especially after reconnect.
Replay safe sequencing
We need monotonic event id / sequence number + a replay cursor (e.g.
since=...).Why: this is the only way to guarantee clients don’t miss or duplicate updates after reconnect (unless we always request another "session/load"
Related ACP prior proposal: https://github.com/agentclientprotocol/agent-client-protocol/blob/main/docs/rfds/message-id.mdx
Remote / mobile usability
Remote-safe auth (non-terminal path)
On mobile, terminal-driven auth isn’t a reliable default.
ACP might need a clear non-terminal auth handoff: browser/device style auth (OAuth link / device code flow) + an observable completion state the client can poll/subscribe to.
Related discussion: https://github.com/orgs/agentclientprotocol/discussions/139
Client reads files from agent host (reverse of client
fs/*)ACP supports agent access to client FS via
fs/*. Remote/mobile clients need the reverse: a standard client → agent file read.Why: we need a consistent way to fetch artifacts/logs/outputs produced in the agent environment.
WebSocket as the recommended baseline transport
For long-lived bidirectional sessions on remote/mobile, WebSocket can be explicitly recommended as the baseline transport in ACP docs/guidance.
Related discussion: agentclientprotocol/agent-client-protocol#476