[BUG] VS Code extension: Remote Control session shows "Connected" but never consumes messages from mobile/web; extension processes accumulate

Status Open
Reported on v2.1.260
Maintainer reply None cached
Activity 0 comments · opened Sep 5, 2026

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?

Title

VS Code extension: Remote Control session shows "Connected" but never consumes messages from mobile/web; extension processes accumulate

---

Body

Summary

A Remote Control session started from the VS Code extension registers correctly and appears as Connected in the Claude mobile app, with a session ID matching the Remote Control badge in the VS Code prompt box. However, nothing sent from the mobile app has any effect on the machine: prompts never execute, and /model never changes the model. No error is shown on any surface.

The same operation works fully via the standalone CLI on the same machine, same account, same network.

Separately (and possibly the cause), the extension leaves claude.exe processes running: three coexisted over roughly six hours, all children of VS Code, all with identical arguments.

Environment

  • OS: Windows 10/11 x64 (corporate virtual desktop, hostname vhd1040010)
  • Plan: Claude Pro
  • VS Code extension: anthropic.claude-code-2.1.260-win32-x64
  • Extension binary: ...\.vscode\extensions\anthropic.claude-code-2.1.260-win32-x64\resources\native-binary\claude.exe
  • CLI (installed later, for comparison): npm-global 2.1.261, commit 1349cf9c224c, platform win32-x64
  • Node: v24.18.0
  • claude doctor: No installation issues found. Reports Multiple installations found (npm-global + native).
  • No ANTHROPIC_API_KEY, no custom ANTHROPIC_BASE_URL, no telemetry-disabling env vars.

Steps to reproduce

  1. In VS Code with the Claude Code extension, open a Claude Code panel.
  2. Run /remote-control in the prompt box. The Remote Control badge appears in the prompt box footer.
  3. Open the Claude mobile app → Code tab. The session is listed with a green dot and Connected.
  4. Confirm the session ID in the app matches the one the badge links to.
  5. From the mobile app, send /model sonnet.
  6. From the mobile app, send a prompt with an observable side effect, e.g. create a file named rc_test.txt in the project root containing "ping".

Expected behavior

The model changes in the VS Code panel, and the prompt executes on the local machine.

Actual behavior

  • The mobile app shows the message as sending/processing, then nothing.
  • The model in the VS Code panel is unchanged (stays Opus 5 High).
  • No file is created. A recursive search across the whole project tree (C:\repo143, which contains all six --add-dir paths of the running processes) finds nothing.
  • The session title remains the auto-generated vhd1040010-streamed-twilight and is never updated to reflect the prompt, which suggests no prompt ever completed server-side.
  • No error appears in the VS Code panel, in the mobile app, or in the session list. The session stays marked Connected throughout.

Session ID involved: 01DwY3T7CC9v7nJNcT3nj5tq.

Process accumulation

Three extension processes coexisted, spawned across a normal working day, with identical arguments:

ProcessId : 11080   CreationDate : 2026-09-04 18:20:33
ProcessId : 25968   CreationDate : 2026-09-04 19:40:56
ProcessId : 16584   CreationDate : 2026-09-05 00:03:09

CommandLine (identical for all three):
...\.vscode\extensions\anthropic.claude-code-2.1.260-win32-x64\resources\native-binary\claude.exe
  --output-format stream-json --verbose --input-format stream-json
  --max-thinking-tokens 31999 --permission-prompt-tool stdio
  --setting-sources=user,project,local --permission-mode auto
  --include-partial-messages
  --add-dir c:\repo143\STI143_ExtratorPecasSEEU --add-dir c:\repo143\robot
  --add-dir c:\repo143\Infodip --add-dir c:\repo143\STI143_API_SAJ
  --add-dir c:\repo143\SEEU_Web_Extrator --add-dir c:\repo143\STI143_Integracao_SEEU
  --debug --debug-to-stderr --enable-auth-status --no-chrome --replay-user-messages

After killing all of them and reopening a single VS Code window, two more appeared under the same parent PID, about three minutes apart:

ProcessId  CreationDate          ParentProcessId
27748      2026-09-05 01:05:13   29884
24512      2026-09-05 01:08:02   29884

With those two alive, the failure reproduces: neither /model sonnet nor a file-creating prompt sent from mobile had any effect.

Working comparison: CLI

With all extension processes killed, on the same machine, account and network:

cd C:\repo143\STI143_Integracao_SEEU
claude --remote-control "teste rc limpo"

The terminal shows /remote-control is active and /rc active. From the mobile app, /model and file-creating prompts both work immediately. This rules out network/proxy interference, plan eligibility, environment variables and any server-side failure.

Not isolated

I did not test the extension with exactly one process alive, so I cannot say whether the root cause is:

  • (A) the extension's bundled binary failing to consume remote messages regardless of process count, or
  • (B) contention between coexisting extension processes, where the one holding the remote session is not the one backing the visible panel.

If it is (B), the underlying defect is still the extension not terminating its process when a panel is closed, which is what allows the processes to pile up in the first place.

Impact

Remote Control is unusable from the VS Code extension, with no error surfaced anywhere. The session presents as healthy and connected, so there is no signal that messages are being lost. The workaround is to abandon the extension and run Remote Control from the CLI.

What Should Happen?

Title

VS Code extension: Remote Control session shows "Connected" but never consumes messages from mobile/web; extension processes accumulate

---

Body

Summary

A Remote Control session started from the VS Code extension registers correctly and appears as Connected in the Claude mobile app, with a session ID matching the Remote Control badge in the VS Code prompt box. However, nothing sent from the mobile app has any effect on the machine: prompts never execute, and /model never changes the model. No error is shown on any surface.

The same operation works fully via the standalone CLI on the same machine, same account, same network.

Separately (and possibly the cause), the extension leaves claude.exe processes running: three coexisted over roughly six hours, all children of VS Code, all with identical arguments.

Environment

  • OS: Windows 10/11 x64 (corporate virtual desktop, hostname vhd1040010)
  • Plan: Claude Pro
  • VS Code extension: anthropic.claude-code-2.1.260-win32-x64
  • Extension binary: ...\.vscode\extensions\anthropic.claude-code-2.1.260-win32-x64\resources\native-binary\claude.exe
  • CLI (installed later, for comparison): npm-global 2.1.261, commit 1349cf9c224c, platform win32-x64
  • Node: v24.18.0
  • claude doctor: No installation issues found. Reports Multiple installations found (npm-global + native).
  • No ANTHROPIC_API_KEY, no custom ANTHROPIC_BASE_URL, no telemetry-disabling env vars.

Steps to reproduce

  1. In VS Code with the Claude Code extension, open a Claude Code panel.
  2. Run /remote-control in the prompt box. The Remote Control badge appears in the prompt box footer.
  3. Open the Claude mobile app → Code tab. The session is listed with a green dot and Connected.
  4. Confirm the session ID in the app matches the one the badge links to.
  5. From the mobile app, send /model sonnet.
  6. From the mobile app, send a prompt with an observable side effect, e.g. create a file named rc_test.txt in the project root containing "ping".

Expected behavior

The model changes in the VS Code panel, and the prompt executes on the local machine.

Actual behavior

  • The mobile app shows the message as sending/processing, then nothing.
  • The model in the VS Code panel is unchanged (stays Opus 5 High).
  • No file is created. A recursive search across the whole project tree (C:\repo143, which contains all six --add-dir paths of the running processes) finds nothing.
  • The session title remains the auto-generated vhd1040010-streamed-twilight and is never updated to reflect the prompt, which suggests no prompt ever completed server-side.
  • No error appears in the VS Code panel, in the mobile app, or in the session list. The session stays marked Connected throughout.

Session ID involved: 01DwY3T7CC9v7nJNcT3nj5tq.

Process accumulation

Three extension processes coexisted, spawned across a normal working day, with identical arguments:

ProcessId : 11080   CreationDate : 2026-09-04 18:20:33
ProcessId : 25968   CreationDate : 2026-09-04 19:40:56
ProcessId : 16584   CreationDate : 2026-09-05 00:03:09

CommandLine (identical for all three):
...\.vscode\extensions\anthropic.claude-code-2.1.260-win32-x64\resources\native-binary\claude.exe
  --output-format stream-json --verbose --input-format stream-json
  --max-thinking-tokens 31999 --permission-prompt-tool stdio
  --setting-sources=user,project,local --permission-mode auto
  --include-partial-messages
  --add-dir c:\repo143\STI143_ExtratorPecasSEEU --add-dir c:\repo143\robot
  --add-dir c:\repo143\Infodip --add-dir c:\repo143\STI143_API_SAJ
  --add-dir c:\repo143\SEEU_Web_Extrator --add-dir c:\repo143\STI143_Integracao_SEEU
  --debug --debug-to-stderr --enable-auth-status --no-chrome --replay-user-messages

After killing all of them and reopening a single VS Code window, two more appeared under the same parent PID, about three minutes apart:

ProcessId  CreationDate          ParentProcessId
27748      2026-09-05 01:05:13   29884
24512      2026-09-05 01:08:02   29884

With those two alive, the failure reproduces: neither /model sonnet nor a file-creating prompt sent from mobile had any effect.

Working comparison: CLI

With all extension processes killed, on the same machine, account and network:

cd C:\repo143\STI143_Integracao_SEEU
claude --remote-control "teste rc limpo"

The terminal shows /remote-control is active and /rc active. From the mobile app, /model and file-creating prompts both work immediately. This rules out network/proxy interference, plan eligibility, environment variables and any server-side failure.

Not isolated

I did not test the extension with exactly one process alive, so I cannot say whether the root cause is:

  • (A) the extension's bundled binary failing to consume remote messages regardless of process count, or
  • (B) contention between coexisting extension processes, where the one holding the remote session is not the one backing the visible panel.

If it is (B), the underlying defect is still the extension not terminating its process when a panel is closed, which is what allows the processes to pile up in the first place.

Impact

Remote Control is unusable from the VS Code extension, with no error surfaced anywhere. The session presents as healthy and connected, so there is no signal that messages are being lost. The workaround is to abandon the extension and run Remote Control from the CLI.
.

Error Messages/Logs

# Title

VS Code extension: Remote Control session shows "Connected" but never consumes messages from mobile/web; extension processes accumulate

---

# Body

## Summary

A Remote Control session started from the VS Code extension registers correctly and appears as **Connected** in the Claude mobile app, with a session ID matching the **Remote Control** badge in the VS Code prompt box. However, nothing sent from the mobile app has any effect on the machine: prompts never execute, and `/model` never changes the model. No error is shown on any surface.

The same operation works fully via the standalone CLI on the same machine, same account, same network.

Separately (and possibly the cause), the extension leaves `claude.exe` processes running: three coexisted over roughly six hours, all children of VS Code, all with identical arguments.

## Environment

- OS: Windows 10/11 x64 (corporate virtual desktop, hostname `vhd1040010`)
- Plan: Claude Pro
- VS Code extension: `anthropic.claude-code-2.1.260-win32-x64`
- Extension binary: `...\.vscode\extensions\anthropic.claude-code-2.1.260-win32-x64\resources\native-binary\claude.exe`
- CLI (installed later, for comparison): npm-global 2.1.261, commit `1349cf9c224c`, platform win32-x64
- Node: v24.18.0
- `claude doctor`: `No installation issues found`. Reports `Multiple installations found` (npm-global + native).
- No `ANTHROPIC_API_KEY`, no custom `ANTHROPIC_BASE_URL`, no telemetry-disabling env vars.

## Steps to reproduce

1. In VS Code with the Claude Code extension, open a Claude Code panel.
2. Run `/remote-control` in the prompt box. The **Remote Control** badge appears in the prompt box footer.
3. Open the Claude mobile app → **Code** tab. The session is listed with a green dot and **Connected**.
4. Confirm the session ID in the app matches the one the badge links to.
5. From the mobile app, send `/model sonnet`.
6. From the mobile app, send a prompt with an observable side effect, e.g. `create a file named rc_test.txt in the project root containing "ping"`.

## Expected behavior

The model changes in the VS Code panel, and the prompt executes on the local machine.

## Actual behavior

- The mobile app shows the message as sending/processing, then nothing.
- The model in the VS Code panel is unchanged (stays `Opus 5 High`).
- No file is created. A recursive search across the whole project tree (`C:\repo143`, which contains all six `--add-dir` paths of the running processes) finds nothing.
- The session title remains the auto-generated `vhd1040010-streamed-twilight` and is never updated to reflect the prompt, which suggests no prompt ever completed server-side.
- No error appears in the VS Code panel, in the mobile app, or in the session list. The session stays marked **Connected** throughout.

Session ID involved: `01DwY3T7CC9v7nJNcT3nj5tq`.

## Process accumulation

Three extension processes coexisted, spawned across a normal working day, with identical arguments:


ProcessId : 11080   CreationDate : 2026-09-04 18:20:33
ProcessId : 25968   CreationDate : 2026-09-04 19:40:56
ProcessId : 16584   CreationDate : 2026-09-05 00:03:09

CommandLine (identical for all three):
...\.vscode\extensions\anthropic.claude-code-2.1.260-win32-x64\resources\native-binary\claude.exe
  --output-format stream-json --verbose --input-format stream-json
  --max-thinking-tokens 31999 --permission-prompt-tool stdio
  --setting-sources=user,project,local --permission-mode auto
  --include-partial-messages
  --add-dir c:\repo143\STI143_ExtratorPecasSEEU --add-dir c:\repo143\robot
  --add-dir c:\repo143\Infodip --add-dir c:\repo143\STI143_API_SAJ
  --add-dir c:\repo143\SEEU_Web_Extrator --add-dir c:\repo143\STI143_Integracao_SEEU
  --debug --debug-to-stderr --enable-auth-status --no-chrome --replay-user-messages


After killing all of them and reopening a single VS Code window, two more appeared under the same parent PID, about three minutes apart:


ProcessId  CreationDate          ParentProcessId
27748      2026-09-05 01:05:13   29884
24512      2026-09-05 01:08:02   29884


With those two alive, the failure reproduces: neither `/model sonnet` nor a file-creating prompt sent from mobile had any effect.

## Working comparison: CLI

With all extension processes killed, on the same machine, account and network:


cd C:\repo143\STI143_Integracao_SEEU
claude --remote-control "teste rc limpo"


The terminal shows `/remote-control is active` and `/rc active`. From the mobile app, `/model` and file-creating prompts both work immediately. This rules out network/proxy interference, plan eligibility, environment variables and any server-side failure.

## Not isolated

I did not test the extension with exactly one process alive, so I cannot say whether the root cause is:

- **(A)** the extension's bundled binary failing to consume remote messages regardless of process count, or
- **(B)** contention between coexisting extension processes, where the one holding the remote session is not the one backing the visible panel.

If it is (B), the underlying defect is still the extension not terminating its process when a panel is closed, which is what allows the processes to pile up in the first place.

## Impact

Remote Control is unusable from the VS Code extension, with no error surfaced anywhere. The session presents as healthy and connected, so there is no signal that messages are being lost. The workaround is to abandon the extension and run Remote Control from the CLI.

Steps to Reproduce

Title

VS Code extension: Remote Control session shows "Connected" but never consumes messages from mobile/web; extension processes accumulate

---

Body

Summary

A Remote Control session started from the VS Code extension registers correctly and appears as Connected in the Claude mobile app, with a session ID matching the Remote Control badge in the VS Code prompt box. However, nothing sent from the mobile app has any effect on the machine: prompts never execute, and /model never changes the model. No error is shown on any surface.

The same operation works fully via the standalone CLI on the same machine, same account, same network.

Separately (and possibly the cause), the extension leaves claude.exe processes running: three coexisted over roughly six hours, all children of VS Code, all with identical arguments.

Environment

  • OS: Windows 10/11 x64 (corporate virtual desktop, hostname vhd1040010)
  • Plan: Claude Pro
  • VS Code extension: anthropic.claude-code-2.1.260-win32-x64
  • Extension binary: ...\.vscode\extensions\anthropic.claude-code-2.1.260-win32-x64\resources\native-binary\claude.exe
  • CLI (installed later, for comparison): npm-global 2.1.261, commit 1349cf9c224c, platform win32-x64
  • Node: v24.18.0
  • claude doctor: No installation issues found. Reports Multiple installations found (npm-global + native).
  • No ANTHROPIC_API_KEY, no custom ANTHROPIC_BASE_URL, no telemetry-disabling env vars.

Steps to reproduce

  1. In VS Code with the Claude Code extension, open a Claude Code panel.
  2. Run /remote-control in the prompt box. The Remote Control badge appears in the prompt box footer.
  3. Open the Claude mobile app → Code tab. The session is listed with a green dot and Connected.
  4. Confirm the session ID in the app matches the one the badge links to.
  5. From the mobile app, send /model sonnet.
  6. From the mobile app, send a prompt with an observable side effect, e.g. create a file named rc_test.txt in the project root containing "ping".

Expected behavior

The model changes in the VS Code panel, and the prompt executes on the local machine.

Actual behavior

  • The mobile app shows the message as sending/processing, then nothing.
  • The model in the VS Code panel is unchanged (stays Opus 5 High).
  • No file is created. A recursive search across the whole project tree (C:\repo143, which contains all six --add-dir paths of the running processes) finds nothing.
  • The session title remains the auto-generated vhd1040010-streamed-twilight and is never updated to reflect the prompt, which suggests no prompt ever completed server-side.
  • No error appears in the VS Code panel, in the mobile app, or in the session list. The session stays marked Connected throughout.

Session ID involved: 01DwY3T7CC9v7nJNcT3nj5tq.

Process accumulation

Three extension processes coexisted, spawned across a normal working day, with identical arguments:

ProcessId : 11080   CreationDate : 2026-09-04 18:20:33
ProcessId : 25968   CreationDate : 2026-09-04 19:40:56
ProcessId : 16584   CreationDate : 2026-09-05 00:03:09

CommandLine (identical for all three):
...\.vscode\extensions\anthropic.claude-code-2.1.260-win32-x64\resources\native-binary\claude.exe
  --output-format stream-json --verbose --input-format stream-json
  --max-thinking-tokens 31999 --permission-prompt-tool stdio
  --setting-sources=user,project,local --permission-mode auto
  --include-partial-messages
  --add-dir c:\repo143\STI143_ExtratorPecasSEEU --add-dir c:\repo143\robot
  --add-dir c:\repo143\Infodip --add-dir c:\repo143\STI143_API_SAJ
  --add-dir c:\repo143\SEEU_Web_Extrator --add-dir c:\repo143\STI143_Integracao_SEEU
  --debug --debug-to-stderr --enable-auth-status --no-chrome --replay-user-messages

After killing all of them and reopening a single VS Code window, two more appeared under the same parent PID, about three minutes apart:

ProcessId  CreationDate          ParentProcessId
27748      2026-09-05 01:05:13   29884
24512      2026-09-05 01:08:02   29884

With those two alive, the failure reproduces: neither /model sonnet nor a file-creating prompt sent from mobile had any effect.

Working comparison: CLI

With all extension processes killed, on the same machine, account and network:

cd C:\repo143\STI143_Integracao_SEEU
claude --remote-control "teste rc limpo"

The terminal shows /remote-control is active and /rc active. From the mobile app, /model and file-creating prompts both work immediately. This rules out network/proxy interference, plan eligibility, environment variables and any server-side failure.

Not isolated

I did not test the extension with exactly one process alive, so I cannot say whether the root cause is:

  • (A) the extension's bundled binary failing to consume remote messages regardless of process count, or
  • (B) contention between coexisting extension processes, where the one holding the remote session is not the one backing the visible panel.

If it is (B), the underlying defect is still the extension not terminating its process when a panel is closed, which is what allows the processes to pile up in the first place.

Impact

Remote Control is unusable from the VS Code extension, with no error surfaced anywhere. The session presents as healthy and connected, so there is no signal that messages are being lost. The workaround is to abandon the extension and run Remote Control from the CLI.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.261 (Claude Code)

Platform

Other

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_

View original on GitHub ↗