[BUG] disableSideloadFlags breaks Claude Desktop's Local Session entirely

Status Open
Reported on v2.1.218
Maintainer reply None cached
Activity 3 comments · opened Jul 24, 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?

With disableSideloadFlags: true in managed settings (managed-settings.json), Claude Desktop's Local Session (a chat tied to a project folder) fails on every session start. This affects the app's primary workflow.

Cause, found in ~/Library/Logs/Claude/main.log: Local Session spawns the CLI with --plugin-dir to load 9 bundled first-party MCP integrations (claude-in-chrome, mcp-registry, Claude Code iOS Simulator, visualize, Claude Browser, ccd_session, ccd_directory, ccd_session_mgmt, scheduled-tasks). disableSideloadFlags rejects --plugin-dir unconditionally, so the CLI process exits with code 1 before the session can start.

The settings docs do mention that this flag blocks "Cowork local sessions in the desktop app," so the block itself is intentional. Two gaps remain:

  1. No warning that this takes down the entire Desktop chat flow, not a secondary feature.
  2. No way to exempt Desktop's own bundled --plugin-dir usage while still blocking arbitrary third-party paths.

What Should Happen?

Either Desktop loads its bundled integrations through a path that disableSideloadFlags doesn't need to touch, or the setting supports a scoped exemption (an allowlist of trusted paths or marketplace names) so orgs can block arbitrary sideloading without losing Local Session.

Error Messages/Logs

# Error shown in Desktop app
Claude Code process exited with code 1. stderr: --plugin-dir is disabled by your organization's managed settings (disableSideloadFlags). Plugins, custom agents, and MCP servers can only be loaded from sources your administrator has approved. Ask your administrator to remove disableSideloadFlags from managed settings, or use an approved marketplace / settings file instead.

--plugin-dir is disabled by your organization's managed settings (disableSideloadFlags). Plugins, custom agents, and MCP servers can only be loaded from sources your administrator has approved. Ask your administrator to remove disableSideloadFlags from managed settings, or use an approved marketplace / settings file instead.

# ~/Library/Logs/Claude/main.log excerpt (root cause context)
2026-07-24 09:50:22 [error] Failed to get SDK commands for local_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx {
  error: Error: Claude Code process exited with code 1. stderr: --plugin-dir is disabled by your organization's managed settings (disableSideloadFlags). Plugins, custom agents, and MCP servers can only be loaded from sources your administrator has approved. Ask your administrator to remove disableSideloadFlags from managed settings, or use an approved marketplace / settings file instead.
}
2026-07-24 09:50:22 [info] [CCD CycleHealth] unhealthy cycle for local_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (3s, hadFirstResponse=false, reason=no_response)

Steps to Reproduce

  1. Set disableSideloadFlags: true in managed settings.
  2. Open Claude Desktop, open a local project folder, start a Local Session.
  3. Send any message.
  4. The session fails immediately with hadFirstResponse=false, reason=no_response. Reproduces every time.

A plain terminal claude session is unaffected, since it never needs --plugin-dir for these bundled integrations.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.218

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

  • Screenshot

<img width="550" height="605" alt="Image" src="https://github.com/user-attachments/assets/3edbc4c2-a437-4ddb-8f15-5917577bc422" />

  • Diagnosed by cross-referencing Grafana/Loki OTel telemetry with ~/Library/Logs/Claude/main.log.

View original on GitHub ↗

3 Comments

mick-feller · 1 month ago

can confirm that we are facing the same issue.

mrtronje · 18 days ago

Confirming this on Windows with server-managed settings (Claude Code admin console, not a local managed-settings.json). Same failure mode as described: every Local Session in the Desktop app fails immediately with exit code 1, both new and resumed sessions. Plain CLI sessions in the terminal are unaffected.

Environment:

  • Claude Desktop on Windows, bundled CLI 2.1.227 (%APPDATA%\Claude\claude-code\2.1.227\claude.exe)
  • disableSideloadFlags: true delivered via server-managed settings on a Team plan

Captured the spawned command line via Get-CimInstance Win32_Process. The Desktop app passes multiple --plugin-dir flags: two pointing at regular marketplace-installed plugins in the user cache, and one at an app-internal skills plugin:

claude.exe --output-format stream-json ... --permission-prompt-tool stdio
  --allowedTools mcp__computer-use,mcp__ccd_session__spawn_task,mcp__ccd_session_mgmt__list_sessions,...
  --setting-sources=user,project,local
  --plugin-dir C:\Users\<user>\.claude\plugins\cache\claude-plugins-official\superpowers\6.2.0
  --plugin-dir C:\Users\<user>\.claude\plugins\cache\gitkraken\gitkraken-hooks\3.1.72
  --plugin-dir C:\Users\<user>\AppData\Roaming\Claude\local-agent-mode-sessions\skills-plugin\<uuid>\<uuid>
  --settings {}

Two observations that may be useful:

  1. The Desktop app also routes marketplace-installed plugins through --plugin-dir (first two paths above). These were installed from a marketplace explicitly allowlisted in strictKnownMarketplaces, so they are policy-approved, yet the sideload block still kills the session. The same plugins load fine in a plain CLI session without any flags.
  2. The third path (local-agent-mode-sessions\skills-plugin\...) is injected by the app itself, so the crash presumably occurs even with zero user-installed plugins.

For enterprise admins this is a rough trade-off: disableSideloadFlags is the only control that closes the --plugin-dir / --mcp-config bypass around strictKnownMarketplaces and the MCP allowlist, but enabling it makes the Desktop app unusable for the whole org. A scoped exemption as suggested in the OP (trusted paths, or honoring the already-allowlisted marketplace provenance of cached plugins) would resolve this.

Happy to provide full logs if helpful

refract13 · 13 days ago

I am seeing the same issue with local managed-settings.json.