Remote control: task chips are delivered to the remote client but can't be activated from mobile

What I'd like

When a session spawns a background task chip (spawn_task), let me see and activate that
chip from the phone while remote-controlling the session — not just from the desktop window.

Why this matters

My end-of-session ritual is: write a handoff document, then spawn a chip carrying a
self-contained prompt for the next piece of work. The chip is the only mechanism that
sets a new session's title and sidebar group (title comes from the chip's title,
grouping is computed from its cwd at creation, and a session can't rename itself). So
the chip isn't a convenience — it's the only correctly-named entry point into the next
session.

I do most of my triage from the phone via remote control. Today, a chip spawned by a
remote-controlled session is invisible there, and by the time I'm back at the desktop the
app has often restarted — which silently drops every unclicked chip, since
backgroundTaskSuggestions is in-memory only and never persisted.

Current behavior, from the shipped app bundle

Poking at app.asar in the desktop app, the gap looks narrow — most of the plumbing is
already there:

1. The chip data already crosses the bridge. formatSessionForEvent includes

backgroundTaskSuggestions in the same session payload that carries bridgeSessionId
and remoteControlAvailable. So the remote client is already receiving titles and
prompts.

1. Activation is desktop-only. Chips resolve through popBackgroundTaskSuggestion /

popBackgroundTaskSuggestionById, which are Electron IPC methods on the
LocalSessions interface with origin validation. There's no bridge operation that
pops a chip. The bridge's vocabulary is send_message, list_sessions,
start_session, plus intercepted slash commands (/rc, /usage|/stats|/cost,
/color).

1. Mobile session creation already exists behind a flag. startSession throws

"Remote session control is disabled" when channel === "mobile" and feature
2216414644 is off.

Concretely, either of these would solve it

• A bridge operation to list and pop a session's pending chips, so the remote client can

render them and launch one; or

• Enabling the channel: "mobile" session-start path, which would let me start the

spawned session from the phone even without chip UI.

Smaller, independent improvement

Consider persisting backgroundTaskSuggestions with the rest of the session metadata.
Right now an app restart drops unclicked chips with no on-disk trace. The prompt is
recoverable from the CLI transcript, but the title and cwd aren't — and those are
exactly what can't be reconstructed by hand.

Environment

• Claude desktop app 1.24012.9 (macOS)
• Claude Code CLI 2.1.220