[BUG] Windows Desktop: Remote Control sessions repeatedly disconnect after clean reinstall; resumed and forked sessions cannot stay attached

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

I am experiencing a persistent Remote Control / Claude Desktop session-bridge failure on Windows.

The issue originally started after Claude Desktop crashed while I was using the Chrome/browser integration during normal work. After that crash, Claude Desktop became unstable enough that I was advised to uninstall and reinstall it.

I performed a clean troubleshooting sequence, including uninstalling Claude Desktop, identifying and isolating leftover Claude state, reinstalling the latest Desktop app, verifying the Chrome Native Host integration, verifying local Claude Code access to my project directory, and creating a completely new Remote Control session.

The clean reinstall initially appears successful:

• Claude Desktop launches normally.
• Cowork starts.
• Local Claude Code sessions work.
• Existing project files are readable.
• Claude in Chrome works.
• Browser control works against a neutral test page.
• A completely new claude --remote-control session successfully registers and reports that it can be controlled remotely.
• A fork of an old session can initially load the full conversation context and respond correctly.

However, after a short period, Remote Control becomes disconnected again.

Eventually all affected sessions show Remote Control disconnected, including sessions that were newly forked after the reinstall.

The Desktop application itself remains running.

This makes it look less like a corrupt individual transcript and more like a failure in the Desktop/Claude Code Remote Control bridge lifecycle, registration, reconnection, or persisted session state.

Environment

Claude Desktop
Windows MSIX package:

Claude_1.30096.5.0_x64__pzs8sxrjxfjjc

Main executable:

C:\Program Files\WindowsApps\Claude_1.30096.5.0_x64__pzs8sxrjxfjjc\app\Claude.exe

Package family:

Claude_pzs8sxrjxfjjc

Claude Code used by Claude Desktop

Claude Desktop launches its own bundled Claude Code binary:

%APPDATA%\Claude\claude-code\2.1.229\claude.exe

Example Desktop-launched command:

%APPDATA%\Claude\claude-code\2.1.229\claude.exe
  --output-format stream-json
  --verbose
  --input-format stream-json
  --effort medium
  --model claude-sonnet-5
  --permission-prompt-tool stdio
  --resume=<session-id>
  --setting-sources=user,project,local
  --permission-mode auto
  --include-partial-messages
  ...

Standalone Claude Code CLI

The separately installed CLI is newer:

claude --version
2.1.233 (Claude Code)

where.exe claude resolves to the npm installation:

%APPDATA%\npm\claude
%APPDATA%\npm\claude.cmd

So there are currently two different Claude Code builds involved:

Claude Desktop bundled CCD: 2.1.229
Standalone npm CLI:         2.1.233

I do not know whether this version difference is causal, but it may be relevant because the failure involves Remote Control session creation/resume/reconnection.

I am using the current standalone Claude Code release (2.1.233), and Claude Desktop was freshly reinstalled before reproducing this issue. However, the current Desktop installation independently launches its bundled Claude Code 2.1.229 binary, as shown in the process inspection below — this is not a version I chose to keep outdated; it is the binary Desktop itself launches.

Full troubleshooting timeline

1. Original Desktop/browser failure

The original problem occurred while using Claude Desktop together with its browser/Chrome functionality during normal work.
After that event, Claude Desktop became unstable and required reinstalling.
Several uninstall/reinstall attempts did not initially resolve the behavior.
This led me to investigate whether state was surviving uninstall.

2. Claude was uninstalled, but Chrome Native Host was still present and actively running

After Claude Desktop had already been uninstalled, the following executable still existed:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe

File information at the time:

Length        : 1018704
CreationTime  : 2026-08-09 23:36:54
LastWriteTime : 2026-08-09 23:36:42

More importantly, it was not just a leftover file. It was still running.

Example process tree:

ProcessId       : 8336
ParentProcessId : 1620
Name            : chrome-native-host.exe
ExecutablePath  : %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe

Its parent was:

Name : cmd.exe

with a command line invoking:

chrome-native-host.exe
chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/
--parent-window=0

using Chrome native-messaging pipes.

This was happening even though Claude Desktop itself had already been uninstalled.

3. The leftover Claude state could not initially be renamed

I attempted to quarantine the old local state instead of deleting it:

Rename-Item `
"$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude" `
"Claude_BACKUP_20260815"

The result was:

Rename-Item : Access to the path
'...\LocalCache\Roaming\Claude'
is denied.

FullyQualifiedErrorId : RenameItemIOError

The folder ACL showed that my Windows account had FullControl, so this did not appear to be a simple filesystem-permission problem.

The active processes were then identified:

cmd.exe
chrome-native-host.exe

After stopping those processes:

Stop-Process -Id <chrome-native-host-pid>,<cmd-pid> -Force

the Claude directory could be renamed successfully.

This strongly suggests that the leftover native-host process was holding the old Claude state open after Desktop had already been uninstalled.

4. Chrome extension was temporarily disabled

To prevent Chrome from immediately re-launching the old native host, I temporarily disabled the Claude / Claude in Chrome extension.
A process check then showed no remaining claude, anthropic, cowork, chrome-native-host processes.

5. Claude Desktop was reinstalled cleanly

Claude Desktop was installed again from the official installer. The application launched successfully.
A new local Claude state directory was created:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude

with a new creation timestamp corresponding to the reinstall. This suggests the new installation was no longer using the old quarantined local state.

6. Basic Claude Desktop operation worked

Claude Desktop was tested before reintroducing the browser integration. A normal Claude interaction worked correctly. Claude was also given access to an existing local project directory.

Example working directory:

D:\Claude Code Local

Claude successfully performed a read-only top-level directory listing. No files were modified.

This confirmed that:

• Desktop was running.
• Claude Code local execution was working.
• Existing project data was accessible.
• The project directory itself did not appear to be causing the crash.

7. Chrome integration was re-enabled and tested independently

The Claude Chrome extension was then re-enabled. A new chrome-native-host.exe process appeared from the newly created Claude state:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe

The process was again correctly connected to the Claude Chrome extension. This was expected after reinstall and indicated that the Chrome ↔ Claude Desktop native messaging bridge had been rebuilt.

8. Browser integration itself successfully passed a neutral test

Before testing any real production site, browser control was tested with:

https://example.com

Claude successfully opened/read the page and returned:

Example Domain

No crash occurred.

Therefore:

Claude Desktop           = working
Local Claude Code        = working
Project directory access = working
Chrome extension         = working
Chrome Native Host       = working
Basic browser control    = working

at this stage.

Remote Control failure

9. Opening an old session triggered device verification

When I returned to one of my previous Claude Code/Desktop conversations, Desktop displayed:

Sign in again to verify your device

I signed in again. This was understandable after reinstalling the application.

10. Old session then hung

After signing in, the old conversation initially loaded. When attempting to continue the conversation, the request remained in a processing state for an extended period rather than completing.

Eventually the UI displayed:

Remote Control disconnected

with the detailed explanation:

Claude Code on the computer that runs this session is no longer connected.
Turn Remote Control back on there and this session will reconnect.

The Desktop app itself had not crashed.

11. Remote Control default setting was enabled

In Settings → Claude Code, I enabled "Connect new sessions to Remote Control". This did not restore the already disconnected sessions.

12. Existing sessions could be seen but not reliably restored

Running:

cd "D:\Claude Code Local"
claude --resume

showed the existing sessions. The session history was still present. However, the sessions showed the same disconnected Remote Control state. Attempting to reconnect them did not restore normal operation.

Important version discrepancy

At this point I verified the standalone CLI:

claude --version
2.1.233 (Claude Code)

But the Desktop process inspection showed Desktop was launching:

%APPDATA%\Claude\claude-code\2.1.229\claude.exe

So Desktop was not using the newer global CLI. It was using its own bundled 2.1.229 executable.

Again, I do not know whether this is the root cause, but it seems important for investigation.

Fresh Remote Control session works initially

13. Completely new Remote Control session was created

To determine whether Remote Control itself was completely broken, I ran:

cd "D:\Claude Code Local"
claude --remote-control

This was not an old resumed conversation. It created a completely new Remote Control session. The session successfully appeared and Claude reported that it was ready to be controlled remotely from my phone. Therefore authentication and initial Remote Control registration were capable of succeeding.

This was an important distinction: "Remote Control cannot initialize at all" was NOT the behavior. Instead: "Remote Control can initialize successfully, but does not remain/recover reliably."

Attempt to preserve an old conversation by forking it

14. Old session was forked

To avoid depending on the old Remote Control identity, I attempted to create a new session ID while preserving the old conversation context:

cd "D:\Claude Code Local"
claude --resume --fork-session

I selected an important old session. It was a large conversation of approximately 131.3k tokens.

Claude offered:

Resume from summary
Resume full session as-is

I selected "Resume full session as-is" because preserving the full working context was important.

15. Forked session initially worked

The session loaded. It was initially archived, so I selected "Unarchive". The forked conversation could then be accessed. When I asked Claude a normal context-related question, it returned a coherent answer based on the previous conversation.

This proved that the transcript/context was intact and that the problem was not simply corrupted conversation history.

16. /remote-control indicated the fork was already being accessed remotely

Inside that fork, attempting /remote-control returned approximately:

/remote-control isn't available over Remote Control

which appeared to indicate that the session was already being accessed through Remote Control at that moment.

So at this point the fork appeared to have succeeded: old context → new fork/session ID → session responsive → Remote Control present.

Failure returns

17. All sessions later became disconnected again

After the successful tests above, the problem returned. Multiple/all relevant conversations again became "Remote Control disconnected". This included sessions that had been created/forked after the clean reinstall.

At this point the hypothesis that only "old sessions are broken because their original owner process was lost" no longer fully explained the problem. A newly created/forked session was also affected.

Process state after the failure

After the sessions became disconnected again, I inspected running processes. The Desktop infrastructure was still alive. For example, cowork-svc.exe was still running. The main Desktop application was also still running:

C:\Program Files\WindowsApps\Claude_1.30096.5.0_x64__pzs8sxrjxfjjc\app\Claude.exe

Multiple normal Electron subprocesses were present: crashpad-handler, gpu-process, network service, renderer, node service, audio service, video capture service.

So this was not simply "Claude Desktop process exited" or "Cowork service stopped".

18. Desktop was actively launching a bundled Claude Code resume process

After the disconnect, Desktop had a child Claude Code process similar to:

%APPDATA%\Claude\claude-code\2.1.229\claude.exe

with:

--resume=<session-id>
--permission-mode auto
--setting-sources=user,project,local
--include-partial-messages

So Desktop was attempting to resume a session using the bundled CCD process.

This makes the situation especially confusing:

• Desktop remains open.
• Cowork service remains open.
• A bundled Claude Code process exists.
• Session history exists.
• Authentication works.
• New Remote Control registration can initially work.
• But Remote Control sessions later show disconnected and cannot reliably recover.

Cowork / VM observations

Earlier Cowork service logs also showed that the underlying local VM/network stack could initialize correctly. The log included successful events equivalent to:

VM started successfully
sdk-daemon connected
Network status: CONNECTED
sdk-daemon is ready
API reachability: REACHABLE

So I did not find evidence that the failure was simply caused by the Cowork VM being unable to reach Anthropic.

One secondary log event occurred during idle shutdown:

Graceful shutdown failed, forcing termination
HcsShutdownComputeSystem failed with HRESULT ... 0x80070032

The VM was subsequently stopped and resources released. I do not know whether this is related, so I am including it only as an additional observation.

Expected behavior

After a clean reinstall and successful re-authentication:

1. Existing Claude Code conversations should remain resumable.
2. If the original local owner process for a conversation no longer exists, Desktop should either: spawn a new Claude Code worker and adopt the existing transcript; re-register Remote Control for the session; explicitly offer "Reconnect / Take over this session"; or fork the conversation into a clean new Remote Control session.
3. A session successfully created with claude --remote-control should remain connected while the corresponding Claude Code process is alive, or should automatically recover from transient bridge failures.
4. A fork created with claude --resume --fork-session should not inherit an unrecoverable/stale Remote Control state from the source conversation.
5. If Remote Control cannot reconnect, Desktop should expose the actual reason rather than only "Remote Control disconnected".

Actual behavior

Observed behavior is:

Clean reinstall
→ Desktop works
→ project access works
→ Chrome integration works
→ browser integration works
→ new Remote Control session can initialize
→ old conversation can be forked
→ fork initially works
→ Remote Control later disconnects
→ multiple/all sessions become disconnected
→ attempts to reconnect old sessions fail
→ Desktop and Cowork remain running

The issue therefore appears to involve the Remote Control/CCD/Desktop bridge state rather than basic application startup, authentication, project access, or browser functionality.

Reproduction sequence from my system

A shortened reproduction path is:

1. Install/start Claude Desktop on Windows.
2. Enable Settings → Claude Code → "Connect new sessions to Remote Control".
3. Start a normal local project session.
4. Verify the session works.
5. Start a clean Remote Control session: claude --remote-control
6. Verify it appears remotely and initially works.
7. Resume or fork an existing session: claude --resume --fork-session
8. Load the full transcript.
9. Verify the fork initially responds correctly.
10. Continue using/opening Remote Control sessions.
11. Observe that sessions eventually show "Remote Control disconnected".
12. Attempt to restore them.
13. The sessions do not reliably reconnect, even though Claude Desktop and Cowork are still running.

Why I do not think this is simply authentication

Authentication appears capable of succeeding: Desktop sign-in works, device verification works, normal Claude conversations work, Claude Code local execution works, a fresh claude --remote-control session successfully registers, the remote client initially recognizes the new session.

Therefore the failure appears to happen after successful authentication/registration, during bridge persistence, ownership, resumption, or reconnection.

Why I do not think this is simply corrupted conversation history

A fork created from an old ~131k-token conversation successfully loaded the full context and produced a coherent answer. Therefore the transcript itself appears usable. The failure is specifically associated with keeping/re-establishing Remote Control connectivity to that session.

Why I do not think this is simply a dead Desktop application

When the failure is present: Claude.exe running, cowork-svc.exe running, Electron children running, bundled CCD running/resuming a session — yet Remote Control still reports disconnected.

Possible areas to investigate

These are hypotheses only, not confirmed root causes.

1. Stale Remote Control bridge ownership — A previous remote/session ID may remain associated with a bridge/environment and prevent a newly resumed or forked local worker from becoming the effective owner.
2. Re-registration path on resume — Desktop may successfully "warm" or --resume a session without performing whatever Remote Control registration is required after the original worker disappeared.
3. Fork inherits stale remote metadata — A --fork-session transcript receives a new session ID but may still inherit some local/server-side bridge state that later causes it to disconnect.
4. Desktop bundled Claude Code version — Desktop currently uses 2.1.229 while the standalone CLI is 2.1.233. It may be useful to test whether Desktop still exhibits the bug when its bundled CCD is updated to the same/newer version.
5. Persistent Desktop bridge state — It may be useful to inspect whether Desktop stores a local Remote Control binding (a state file or local database under %APPDATA%\Claude\) that contains a stale remoteSessionId/localSessionId pairing that gets re-adopted after restart. I have deliberately not modified any local Desktop state files because I wanted to preserve the failing state for diagnosis.
6. Native Host lifecycle after uninstall — The Chrome Native Host process remaining active after Desktop uninstall (see troubleshooting timeline steps 2–4) may indicate another lifecycle/state-cleanup problem, though I'm not asserting it is the cause of the Remote Control disconnect behavior described here.

Potentially related existing issues

This looks related to several existing Remote Control reports, but my reproduction includes a clean reinstall, a surviving Chrome Native Host after uninstall, a successful fresh Remote Control registration, a successful full-session fork, and then a subsequent global disconnect.

Possibly related:

• #60790 — existing session cannot resume after original CLI owner is gone
• #85435 — Desktop local session Remote Control bridge is not re-registered after app restart
• #86717 — Windows Desktop stale/persisted Remote Control bridge binding
• #34255 — Remote Control automatic reconnection fails after connection drop

My case may be an overlap of more than one lifecycle problem rather than an exact duplicate of a single one.

Questions for maintainers

I would be very grateful for guidance on the following:

1. Is Claude Desktop 1.30096.5.0 expected to bundle Claude Code 2.1.229 even when standalone Claude Code 2.1.233 is installed?
2. Can Desktop be forced to use/update the bundled Claude Code version for diagnostic purposes?
3. Is there a supported way to completely reset only the Remote Control bridge state without deleting local conversation history or project configuration?
4. Is there a specific local Desktop/Remote Control state file or database on Windows that stores remoteSessionId/localSessionId bindings, and is there a supported way to reset only that state?
5. When a session is resumed after its original worker has disappeared, should Desktop automatically create a new worker and re-register Remote Control?
6. Should --fork-session guarantee completely independent Remote Control metadata, or can a fork still inherit remote/bridge state from its source?
7. What logs would be most useful to capture at the exact moment a previously working Remote Control session transitions to disconnected?
8. Is there a debug/verbose mode for the Desktop bridge comparable to standalone claude --remote-control --verbose that would expose transport teardown/reconnection events?

Impact

This is a high-impact workflow issue for me because I use long-running Claude Code/Desktop sessions containing substantial project context. The transcripts and project files are still present, but Remote Control instability makes it unsafe to rely on those sessions for continued work.

The most problematic behavior is that a session may appear restored and usable, including after being forked into a new session, and then later return to "Remote Control disconnected" without the Desktop application itself having crashed. This makes it difficult to know whether a session is genuinely recovered or only temporarily attached.

Additional logs available

I can provide, with personal information/session tokens redacted:

• full process listings before and after disconnect;
• cowork-service.log;
• Claude Desktop logs;
• exact process command lines;
• Chrome Native Host process information;
• timestamps for uninstall/reinstall and reconnect attempts;
• Remote Control session/fork timeline;
• relevant %APPDATA%\Claude state file contents if maintainers specify which files are safe/useful to share.

Please let me know which specific log files or debug flags would be most useful.

Current state

At the time of filing:

Claude Desktop:                    launches and remains running
Cowork:                            running
Local project access:              working
Chrome integration:               working
Basic browser control:             working
Standalone Claude Code 2.1.233:    working
Desktop bundled Claude Code 2.1.229: running
Fresh Remote Control creation:     initially succeeds
Old Remote Control sessions:       disconnected / unreliable
Forked old sessions:               can initially work, later disconnect
Automatic reconnection:            not reliably recovering

The main issue I would like help diagnosing is:
Why do Remote Control sessions lose or fail to recover their local Desktop/Claude Code bridge even after a clean reinstall and even when newly created/forked sessions initially connect successfully?

What Should Happen?

Remote Control sessions (fresh ones created with claude --remote-control, resumed sessions, and forked sessions via claude --resume --fork-session) should stay connected to Claude Desktop's Remote Control bridge for as long as the underlying Claude Code process and Claude Desktop application remain running. If the bridge cannot stay connected, Desktop should surface the actual failure reason and/or automatically re-register a new worker, instead of silently showing "Remote Control disconnected" for sessions whose processes are still alive.

Error Messages/Logs

Remote Control disconnected
Claude Code on the computer that runs this session is no longer connected.
Turn Remote Control back on there and this session will reconnect.

Secondary Cowork log event observed during idle shutdown:
Graceful shutdown failed, forcing termination
HcsShutdownComputeSystem failed with HRESULT ... 0x80070032

Rename-Item error encountered while quarantining old Claude local state after uninstall (before chrome-native-host.exe was stopped):
Rename-Item : Access to the path '...\LocalCache\Roaming\Claude' is denied.
FullyQualifiedErrorId : RenameItemIOError

Steps to Reproduce

1. Install/start Claude Desktop on Windows (MSIX package Claude_1.30096.5.0_x64__pzs8sxrjxfjjc).
2. Enable Settings -> Claude Code -> "Connect new sessions to Remote Control".
3. Start a normal local project session (e.g. in D:\Claude Code Local) and verify it works.
4. Start a clean Remote Control session:

``powershell
cd "D:\Claude Code Local"
claude --remote-control
``

1. Verify it appears in the mobile/remote client and initially works.
2. Resume or fork an existing (large/old) session:

``powershell
claude --resume --fork-session
``
Choose "Resume full session as-is".

1. Load the full transcript and verify the fork initially responds correctly to a normal question.
2. Continue using/opening these Remote Control sessions for a short period.
3. Observe that sessions eventually show:

``
Remote Control disconnected
Claude Code on the computer that runs this session is no longer connected.
Turn Remote Control back on there and this session will reconnect.
``

1. Attempt to reconnect/restore them (re-enable the Remote Control setting, re-resume via claude --resume).
2. The sessions do not reliably reconnect, even though Claude.exe, cowork-svc.exe, and a bundled claude-code\2.1.229\claude.exe --resume=<session-id> process are all still running.

Full troubleshooting timeline, process listings, and additional context are in the Description field above (this reproduction was preceded by an uninstall/reinstall cycle in which a chrome-native-host.exe process kept the old Claude local state locked after uninstall).

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.233 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Additional system details:

• OS: Windows 11 x64
• Claude Desktop: 1.30096.5.0
• Desktop bundled Claude Code: 2.1.229
• Standalone Claude Code: 2.1.233
• Installation type: Windows MSIX / WindowsApps
• Remote Control default setting: Enabled
• Claude in Chrome extension: Enabled after clean reinstall
• Machine was not intentionally rebooted between the successful Remote Control test and the later disconnect.