Title: Remote control: cloud→local input channel broken (account-scoped);outputchannelworks

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude's behavior changed between sessions

What You Asked Claude to Do

Summary

On claude --remote-control, the cloud→local input
channel is broken while the local→cloud output channel
works. Prompts typed in the browser (claude.ai) or
mobile app show a spinner and never execute in the local
terminal. Output streams up to browser/mobile
correctly. Locally typed input at the terminal works.

The failure is account-scoped: a known-good laptop
running the same client reproduces the bug when logged
in as my account, and works flawlessly when logged in as
a different account. Not a client bug — server-side
state tied to my account.

Environment

• Client: Claude Code v2.1.152 (npm @latest, clean

global install — also reproduced on 2.1.150)

• OS: Windows 11 Home 10.0.26200
• Terminal: Windows Terminal 1.24.11321.0 + PowerShell 7
• Account: markbuff03@gmail.com (UUID

d3bbb8c8-8184-4362-ae3b-d3b9a258ec6e) — Max plan, org
admin

• First broken: 2026-05-26 (worked fine the day before

on the same client + same OS + same terminal)

• Still broken: 2026-05-29

Reproduction

1. On Windows i9 workstation, launch: claude

--remote-control gunzee

1. Open claude.ai → Remote Control → select the live

session

1. Type a prompt in the browser window (e.g. say hi)
2. Expected: prompt executes in the local terminal

session

1. Actual: browser shows spinner indefinitely; local

terminal never receives the prompt; no transcript entry
is written

Mobile app behavior is identical (rules out
browser-specific). Locally typed input at the i9
terminal works (rules out local agent / stdin /
terminal).

What I verified to rule out other causes

• Single clean session. Audited live: exactly one

claude.exe --remote-control process, valid session file
in ~/.claude/sessions/<pid>.json, healthy bridge
(peerProtocol:1, live bridgeSessionId). Output relays
fine, proving the bridge is established.

• No duplicate sessions. Get-CimInstance Win32_Process

-Filter "Name='claude.exe'" returns exactly one
remote-control process. Old sessions explicitly killed
and their session files deleted.

• Correct picker selection. Confirmed selecting the live

session (not a stale entry) in the cloud picker.

• Fresh OAuth. /logout → fresh terminal → /login does

not fix it. .credentials.json refresh does not fix it.

• Client version. 2.1.150 and 2.1.152 both reproduce. No

client update on or around the regression date — broke
under the same client that was working the previous day.

• OS / terminal. No Windows updates between 5/13 and

5/27 (KB5089573 landed AFTER the break). Windows
Terminal unchanged since 5/14.

• SSH into the i9 works fine — stdin / inbound network

path to the machine is healthy.

• Not server-wide. A coworker on a different account

using the same claude.ai remote-control feature works
flawlessly. So the cloud relay itself is not broken
globally.

The decisive isolator: account-scoped, not
machine-scoped

• Coworker on his account on his laptop: works.
• Coworker on MY account on his (known-good) laptop: bug

reproduces identically. Browser/mobile input spins;
output relays fine.

• Me on my account on my i9: bug reproduces.

Same client, same OS family, same network class — the
only differentiator is the account. The failure is
server-side state attached to account
markbuff03@gmail.com / UUID
d3bbb8c8-8184-4362-ae3b-d3b9a258ec6e.

Hypothesis

Something on the server-side session/device record for
my account is misrouting the cloud→local input channel
to a dead handle (or dropping it entirely), while the
output channel continues to broadcast correctly.
Plausibly a stale device/session grant or a
managed-policy flag that flipped around 2026-05-26.

What I'd like

• Server-side inspection of my account's active

device/session records for the remote-control bridge.

• Force-revocation of all server-side session records

tied to that account UUID so I can re-pair from scratch.

• Confirmation whether any managed-policy /

device-approval / remote-control toggle changed on my
org around 5/26.

Interim workaround

Type at the local terminal directly. Browser/mobile are
read-only for monitoring until the input channel is
repaired.

I also have detailed per-day diagnostic notes (process
audits, session-file dumps, timeline of every config
change tried) if helpful — happy to attach on request.

What Claude Actually Did

WhenItypeapromptintheclaude.aibrowserwindow(or mobile app) while attached to my claude
--remote-controlsession,thepromptshowsaspinner
indefinitely and never executes locally. The local
terminal session never receives the input — no
transcriptentryiswritten,noacknowledgment, nothing.
Theoutputchannel(local→cloud)workscorrectlythe
whole time: anything the terminal prints streams up to
the browser and mobile app as expected. Only the
cloud→local input direction is broken. Typing directly
at the i9 terminal keyboard works fine, so the local
agent and stdin are healthy.

Expected Behavior

Being able to enter prompts and command from the iOS mobile app and or Claude code on a browser

Files Affected

Unsure

Permission Mode

I don't know / Not sure

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

1.OnaWindowsworkstation,launchClaudeCodewith
remote control: claude --remote-control gunzee
2.Confirmexactlyoneclaude.exe --remote-control
process is running and a valid session file exists at
~/.claude/sessions/<pid>.json with a live
bridgeSessionId.
3.Openclaude.aiinabrowser(ortheClaudemobile
app), go to Remote Control, and select the live "gunzee"
session from the picker.

1. Verify the output channel works: type a command

locally at the i9 terminal and watch it stream up to the
browser/mobile view. ✅

1. In the browser window, type any prompt (e.g. say hi)

and press Enter.

1. Observed: browser shows a spinner indefinitely; the

prompt never executes in the local terminal session; no
transcript entry is written locally.

1. Expected: prompt is delivered to the local session

and executes, same as if typed at the local terminal.

Reproduces 100% of the time on my account. Does NOT
reproduce on a coworker's account using the same
feature. Reproduces on a known-good laptop when that
laptop is logged in as my account — confirming the
failure is tied to the account, not the machine.

Claude Model

Opus

Relevant Conversation

I spent hours and hours with Claude trying to debug and resolve with no

Impact

Critical - Data loss or corrupted project

Claude Code Version

2.1.152

Platform

Anthropic API

Additional Context

My set up was working for months and then all of a sudden just stopped working. I confirmed that it was not my hardware and had my son try it on his laptop and mobile phone by logging into my account and it showed the same behavior, one-sided communication. Claude code from the terminal worked fine, it mirrored output to the mobile app and or browser, but no command or prompts could be entered in the browser or mobile app. When he logged in to his own Claude account, everything worked fine.