After desktop app update to 2.1.247, new sessions report "/remote-control isn't available in this environment" until the app is fully restarted

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?

What happened:

The Claude Code desktop app (Windows 11, desktop release 1.40609.0, Claude Code 2.1.247) auto-updated in place. Afterward, every newly created session responded to /remote-control with:

/remote-control isn't available in this environment.

Sessions created before the update kept Remote Control working normally — one still-running session even showed "Remote Control is already on: this session connected automatically when it started." Two brand-new sessions created after the update both refused the command.

No user-side blockers were present: no telemetry-disabling env vars (DISABLE_TELEMETRY, DO_NOT_TRACK, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC), no custom ANTHROPIC_BASE_URL in the registry, shell profiles, or Claude settings, and a full-scope OAuth login (scopes included user:sessions:claude_code).

Workaround/fix:

Fully quitting the desktop app (from the tray icon) and restarting it resolved the problem — new sessions accept /remote-control again and connect normally.

Suggestion:

If the availability check fails because of stale post-update state, the error message could say so (e.g., "restart the app to enable Remote Control") instead of the generic "isn't available in this environment," which sends users hunting through env vars and settings. Possibly related to the Remote Control availability-check changes noted in the 2.1.239 and 2.1.247 changelog entries.

Environment:

• Windows 11 Home 10.0.26100
• Claude Code desktop app release 1.40609.0
• Claude Code 2.1.247 (entrypoint claude-desktop)
• Auth: claude.ai OAuth (paid plan)

What Should Happen?

/remote-control should work in sessions created after an in-place auto-update, the same as in sessions created after a fresh app launch. If the availability check genuinely can't pass until the app restarts, the message should say that (e.g., "restart the app to enable Remote Control") rather than the generic "isn't available in this environment."

Error Messages/Logs

/remote-control isn't available in this environment.

Steps to Reproduce

1. Run the Claude Code desktop app on Windows with Remote Control working (sessions connect normally).
2. Let the desktop app auto-update in place to 2.1.247 (desktop release 1.40609.0) without fully restarting it.
3. Create a new session in any project and type /remote-control.
4. Observe: "/remote-control isn't available in this environment." A second brand-new session behaves the same.
5. Note that sessions created before the update still have Remote Control working (a still-running one reports "Remote Control is already on: this session connected automatically when it started").
6. Fully quit the app from the tray icon and relaunch. New sessions now accept /remote-control and connect normally.

Related (same auto-update trigger, different symptom): #77871 reports the mirror image — after an auto-update, PRE-update sessions lose Remote Control while new sessions connect fine. #84502 may also be adjacent (code-tab sessions never registering for Remote Control).

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.247 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

This was the Claude Code desktop app (release 1.40609.0), not a terminal — "Other" selected under Terminal/Shell for that reason. "Last working version" is left blank because the pre-update sessions that kept Remote Control were created Aug 26–29 and I don't know exactly which Claude Code version they were on; the update to 2.1.247 landed in place while they were running.