The proxy takeover claude switch cannot be ticked in Claude Desktop mode - CC Switch

Quick fix

In claude-desktop mode, the takeover section hard-codes the Claude Code (claude) switch instead of the Claude Desktop one, so clicking does nothing.

Symptom

Error outputCopy

尝试勾选 claude → ❌ 勾不上 / 无反应或报错

English translation

Trying to tick claude -> ❌ will not tick / does nothing or errors

Cause

The problem comes from an AppType mapping mismatch between the cc-switch v3.16.0 frontend and backend. The backend treats 'claude' (the Claude Code CLI) and 'claude-desktop' (the Claude Desktop application) as two separate AppTypes. The "app takeover" section in the frontend ProxyPanel.tsx, however, hard-codes three switches: `["claude", "codex", "gemini"]`.

When you configure a provider in `claude-desktop` mode and start the proxy, the current context is `claude-desktop`. But clicking the "claude" takeover switch makes the frontend send `set_takeover_for_app("claude", true)` to the backend. The backend looks for a provider configuration with app_type="claude", and since you configured only a `claude-desktop` provider, it finds no matching `claude` configuration and the operation fails (will not tick, or errors). codex and gemini, by contrast, have their own independent AppTypes and do not interfere, so they tick normally.

Fix

1. 1

   Temporary workaround: enable takeover by editing the SQLite database directly. Open the SQLite database file cc-switch uses, find the proxy_config table, and set the enabled field to 1 by hand for the row with app_type='claude' matching your current proxy configuration.

   # 需定位到 cc-switch 存储数据的 SQLite 数据库文件

2. 2

   Real fix: wait for an official update. The developers have confirmed the bug. The suggested approach is to render the takeover switch list in ProxyPanel.tsx dynamically from the current activeApp (showing the claude-desktop switch in claude-desktop mode, for instance) and to add the matching takeover logic for AppType::ClaudeDesktop in the backend.

Affected Versions

ToolClaude Desktop

Version3.16.0

PlatformsWindows

Source Issues

This page is distilled from 2 real issues

• #3367Bug: claude-desktop 模式下设置页接管开关无法勾选 Claude，只能勾选 Codex/Gemini
• #3370Bug: 非 claude （codex/gemini）的接管开关在 claude-desktop provider form 设置页中可见，点击 claude 接管开关因无对应 Provider 而报错

FAQ

Why can the codex and gemini takeover switches be ticked and only claude cannot?

Because codex and gemini are independent AppTypes in the code, while the claude switch actually points at the Claude Code (CLI) configuration. In Claude Desktop mode there is no Claude Code provider configured in the system, so clicking the claude switch fails to find a configuration.

How do I tell whether my provider is in claude or claude-desktop mode?

When adding a provider, choosing the desktop integration (DeepSeek V4 for Claude Desktop, for instance) marks its app_type as "claude-desktop". That is a different identifier from the command-line "claude".

Do subagents work correctly after editing the database?

Yes. The user in Issue #3370 reports that after setting enabled to 1 by hand for the matching row in the proxy_config table, restore_proxy_state_on_startup restores the takeover state correctly and subagents can route models through the proxy.

Related problems

ANTHROPIC_AUTH_TOKEN and ANTHROPIC_API_KEYOpen `~/.claude/settings.json`, delete the duplicate auth variable so only the one your provider needs remains, save, and restart Claude Code.4 issues mergedThe model cannot discover any tools - CodexUpgrade cc-switch past 3.16.1 and edit cc-switch-model-catalog.json to set supports_search_tool to false for the DeepSeek models.2 issues mergedUnknown name "prompt_cache_key" - cc-switchUpgrade cc-switch to v3.16.2+ to fix prompt_cache_key injection, or use an OpenRouter endpoint that natively speaks the Claude Code format.6 issues merged