Remote Control: no per-message provenance — injected/meta messages are indistinguishable from local input in the transcript

Summary

During a Claude Code session that had an active Remote Control bridge, a spurious
"system"-style message (non-English, instructing the assistant to "take back control"
and disregard supposed injected instructions) and a spurious user message
("Your tool call was malformed and could not be parsed. Please retry.") appeared
appended to a normal user turn. Neither was something I typed.
appended to a normal user turn. Neither was something I typed.

This turned out to be more of an observability/auditing gap than a single bug:
once it happened, there was no way for me to determine from local data whether the
content arrived via the Remote Control bridge or via local input.

### Environment

• Claude Code CLI (entrypoint: cli)
• Model: Claude Opus 4.8
• Platform: Linux (WSL2)
• Remote Control: bridge was active on the session

### What I observed (local transcript, ~/.claude/projects/.../*.jsonl)

• The injected fake user message was stored as type: user with isMeta: true,

while genuine prompts are isMeta: null.

• User-message events only carry entrypoint (cli / claude-vscode / sdk-ts)

and userType — there is no per-message field indicating Remote Control vs local
origin, nor any sender/device/client identifier.

• bridge-session events (which record the bridge association) carry no timestamp,

so the bridge attach time cannot be correlated with the injected message time.

### Why it matters
For a session reachable via Remote Control, there is currently no local audit trail to
answer "did this message come from the remote bridge or from my terminal, and from which
client?" That makes prompt-injection / spoofed-input incidents hard to triage locally.

### Suggestions

1. Tag each user message with its origin (local terminal vs remote bridge; ideally a

stable remote client identifier) in the transcript.

1. Add a timestamp to bridge-session events.
2. Provide a way to list currently-connected remotes and revoke a specific client.

### Note on disclosure
I have the concrete correlation identifiers (session ID, bridge session ID, exact
timestamps/UUIDs) but am intentionally not posting them here, since they are
account-scoped and this is security-adjacent. I can provide them privately through
the security channel on request.