Remote control relay injects never-typed, AI-suggested reply texts as invisible drafts into the bridged CLI input box (ghost prompts)

Summary

When using /remote-control (claude.ai/code bridged to claude --rc running in tmux on a Mac mini), the input relay deposits texts the user never typed into the CLI's input box as unsent drafts. The injected texts are contextually appropriate AI-generated reply suggestions for the specific session (phrased in the user's language and style, answering the assistant's last message), and they are invisible in the claude.ai client UI — the user cannot see, send, or delete them from the remote client. They sit in the tmux input box where any stray Enter submits them as a real prompt.

This is a serious safety issue for sessions running with elevated permissions: a prompt the user never wrote can trigger real actions.

Environment

• Claude Code v2.1.214 (Homebrew), macOS (Apple Silicon, Darwin 25.3.0)
• 5 parallel claude --rc sessions, each as root process of its own tmux session
• Client: claude.ai/code from iPhone/browser
• German-language user; all injected drafts were fluent German

Observed behavior (single evening, timeline)

1. Known submit bug (precondition): messages typed in the remote client sometimes land in the CLI input box as a draft but never submit (bare Enter on the relay-owned draft does not fire; only Ctrl+U → retype locally → Enter submits). Related to the "stopped responding mid-turn" family (#58665, #76530, #75215).
2. Replay drip-queue: the relay delivers a queue of stale inputs one at a time — each time the input box empties, the next item appears. Items included paraphrases of messages the user had sent earlier in a different session, messages that never arrived, and a slash command that had already been executed an hour earlier and resurfaced as a fresh draft. When one session's box stayed occupied, the queue continued into a different session.
3. Novel/generated texts (the core of this report): drafts appeared that the user verifiably never typed anywhere, yet were perfect next-user-replies for the exact session they appeared in. Examples (paraphrased for privacy):

• After the assistant asked for a go-ahead on a proposed fix, a draft appeared: "Yes, build the fix and look up X" — submitting it (see below) triggered a repo commit and reading a private document.
• After the assistant recommended a security check, a draft appeared claiming the user had performed the check with an all-clear result ("I checked the devices, all fine, only my own") — the user had not done the check. Note the hazard: this would have falsely closed a security verification.
• In parallel, a second session received a draft matching its context ("X is my son, create the person file") while that session was working on exactly that topic.

1. The user confirmed for each of these texts, immediately and unprompted, that he never wrote them. None of them are visible anywhere in the client's chat view or input field.

Impact

We had a local watchdog that auto-submitted stuck drafts (built as a workaround for bug 1, on the assumption "whatever sits in the input box was typed by the user"). Because of 2 and 3 that assumption is false, and two never-typed prompts were executed as real instructions — one of them acted as a fake "go" for a system change, on a session running with bypass permissions. We have since disabled auto-submit and now auto-clear stuck drafts after alerting the user via a side channel.

Even without such automation, the injected drafts are one accidental Enter away from executing, and the user has no visibility of them in the client.

Working hypothesis

The texts look exactly like client-side generated "suggested replies" (contextual, user-voice, per-session). It appears a relay bug routes suggestion texts (and stale queued inputs) into the bridged CLI's input box as if the user had typed them. Happy to provide sanitized logs/timestamps privately.

Expected behavior

• The remote-control relay must never place text into the CLI input box that the user did not explicitly type and submit.
• Anything the relay does place there should be visible (and deletable) in the client UI.

Steps to reproduce (best effort)

1. Run several claude --rc sessions in tmux, connect via claude.ai/code from a mobile client with intermittent connectivity.
2. Interact across multiple sessions; leave sessions idle with empty input boxes.
3. Watch the input boxes (e.g. tmux capture-pane) — unsent drafts appear over time without any user input: stale queue items and contextually generated reply texts.