claude-code - 💡(How to fix) Fix Title: Remote control: cloud→local input channel broken (account-scoped);outputchannelworks

Preflight Checklist

• I have searched existing issues for similar behavior reports
• 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: [email protected] (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
2. Open claude.ai → Remote Control → select the live
   session
3. Type a prompt in the browser window (e.g. say hi)
4. Expected: prompt executes in the local terminal
   session
5. 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 [email protected] / 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. 4. Verify the output channel works: type a command
locally at the i9 terminal and watch it stream up to the browser/mobile view. ✅ 5. In the browser window, type any prompt (e.g. say hi) and press Enter. 6. Observed: browser shows a spinner indefinitely; the
prompt never executes in the local terminal session; no transcript entry is written locally. 7. 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.