Device-connected (`sdk-cli`) sessions load none of the desktop-native MCP servers — no browser, computer-use, scheduled-tasks or session-management tools

Summary

On the same machine, same account and same settings files, a session started by connecting the device (recorded in the transcript as entrypoint: sdk-cli) loads none of the MCP servers that the desktop app provides to its own sessions (entrypoint: claude-desktop).

The remote claude.ai connectors (Gmail, Calendar, Slack, Asana, Figma) are present and connected in both. Everything the desktop application supplies itself is missing from the device path.

The sessions don't fail visibly. They just quietly do worse work, because the tools they'd reach for aren't there. It took a fair amount of transcript analysis to notice and diagnose.

Environment

• Windows 10 Home 19045
• Claude Code desktop app: 2.1.229
• CLI (%USERPROFILE%\.local\bin\claude.exe): originally 2.1.204, updated to 2.1.233 and re-verified — behaviour unchanged
• Plan: Max 5x

Evidence

Measured across all 167 local session transcripts (~/.claude/projects/<project>/*.jsonl), grouped by the entrypoint field:

| | claude-desktop | sdk-cli (device) |
|---|---:|---:|
| tool calls | 13,568 | 417 |
| distinct tools | 75 | 15 |
| MCP tool calls | 2,201 | 0 |
| distinct MCP servers used | 8 | 0 |

Six consecutive sdk-cli sessions made zero MCP calls between them. The only tools they used were Bash, Read, Edit, Write, Grep, Glob, WebFetch, WebSearch, ToolSearch, Skill.

What is present vs missing

claude mcp list from the CLI (on 2.1.233) returns only the claude.ai remote connectors:

• Connected: Gmail, Google Calendar, Slack, Asana, Figma
• Needs authentication: Intercom, Linear, Atlassian Rovo, Notion

None of the desktop-native servers appear at all:

Claude_Browser · claude-in-chrome · computer-use · scheduled-tasks · ccd_session_mgmt · ccd_session · ccd_directory · terminal · visualize

So a device-connected session cannot drive a browser, control the screen, list/create/modify scheduled tasks, or read any other session.

Why this isn't user-fixable

There is no mcpServers configuration anywhere on disk to point the CLI at:

• ~/.claude.json — no global mcpServers; all 42 project entries have mcpServers: null
• No .mcp.json at user or project level
• ~/.claude/settings.json, project .claude/settings.json, and both managed-settings.json files contain no mcpServers key
• No MCP server manifests or binaries under C:\Program Files\ClaudeCode (which contains only managed-settings.json) or %LOCALAPPDATA%\Claude

The desktop-native servers appear to be internal to the desktop application, so there is nothing to register and no documented way to grant a device-connected session the same toolset.

Impact

Connecting the device is the main way I use Claude Code away from the desk. In that mode the assistant loses browser control, screen control, scheduled-task visibility and cross-session memory — which is the majority of my actual workflow. Because nothing errors, the degradation reads as the model simply performing worse.

Expected behaviour

Either device / sdk-cli sessions load the same server set as desktop sessions, or the disparity is documented and the desktop-native servers are made registrable by the user.

Workaround (for anyone hitting this)

Triggering an existing scheduled task from the device spawns a claude-desktop session with the full toolset. Only bare device-started sessions land on sdk-cli. So "Run now" on a task beats starting a fresh session remotely.

Possibly related

• #77252 (remote control / desktop session staleness)
• #81568 (session state differing per device)