Skip to content

auto mode cannot determine the safety: Claude Code error

Quick fix

Upgrade CC Switch first. If the error persists, check thinking parameters, model mapping, stop support, and the response format when stream is omitted.

Error output
Error: claude-opus-4-7[1m] is temporarily unavailable, so auto mode cannot determine the safety of Bash right now.

This message is a generic error shown when the Claude Code Auto Mode safety classifier fails; it does not necessarily mean the model is offline. Reported causes include the `openai_chat` conversion in CC Switch 3.14.1 not mapping `thinking.type=disabled` to the upstream parameter that actually disables thinking, causing reasoning to exhaust the classifier's token budget; the Copilot OpenAI Chat API possibly not supporting `stop`; and the old switching process writing the default model ID instead of the user's configured model to `settings.json`. Maintainers confirmed that the related conversion issues were fixed in v3.15.0 or superseded by v3.16.0, while 4.0 rewrote the Claude Code switching process.

Later reports show that the same message can also result from upstream limitations. With CC Switch 3.20.2, one third-party DeepSeek upstream could not actually disable reasoning. In a 4.0.11 native Anthropic pass-through case, maintainers confirmed that CC Switch treated an omitted `stream` as non-streaming, but the upstream still returned SSE. If the issue persists after upgrading, do not treat every variant as the same CC Switch defect. Bypass CC Switch, connect directly to the upstream, and compare the response and parameter support.

  1. If you use CC Switch 3.14.1, upgrade to v3.15.0 or later first. Maintainers confirmed that this version fixed the known Auto Mode routing and conversion issue.

  2. Confirm that the provider's local proxy is taking control, then inspect the actual request models for Sonnet, Opus, and Haiku. Since v3.9.0, cc-switch maps classifier models using keywords such as `sonnet`, `opus`, and `haiku`, so a third-party backend does not need to support `claude-sonnet-4-6` directly.

  3. If the GitHub Copilot configuration in 3.15.0 writes the default model ID to `settings.json`, override the relevant variables in Claude's Common Config with models actually supported by the provider. Version 4.0 rewrote the switching process and removed this merge mechanism, so check the switched values in the latest version.

    settings.json
    {
    "env": {
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "claude-opus-4.6",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-opus-4.6",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "claude-opus-4.6",
    "ANTHROPIC_MODEL": "claude-opus-4.6",
    "ANTHROPIC_REASONING_MODEL": "claude-opus-4.6"
    }
    }
  4. If you use `api_format=openai_chat`, directly test whether the upstream supports the parameter for disabling thinking and supports `stop`. Some upstreams still generate reasoning tokens after receiving `enable_thinking:false`; in that case, the upstream must provide compatibility, and this parameter alone cannot fix the issue.

  5. If you use Local Routing with the native `anthropic` format, bypass CC Switch and send the provider an equivalent request with `stream` omitted, then inspect `Content-Type`. If the direct upstream returns `text/event-stream`, report it to the provider because omitting `stream` should return non-streaming JSON.

ToolClaude Code
VersionUnknown
PlatformsWindowsmacOS
Has this issue been resolved?
Some causes have been fixed. Maintainers confirmed that the known Auto Mode routing and conversion issues were fixed in v3.15.0 or superseded by v3.16.0, and 4.0 rewrote the model configuration switching process. However, the same generic error can still occur when a third-party upstream cannot disable reasoning, does not support `stop`, or incorrectly returns SSE when `stream` is omitted.
Is there a recommended configuration for this conversion path, or does the earlier fix cover the current version?
The known `openai_chat` conversion for disabling thinking was marked as fixed, but a report for 3.20.2 showed that some third-party DeepSeek upstreams continued generating reasoning tokens even after receiving the parameter to disable thinking. Coverage therefore depends on the specific provider's capabilities.
How can I confirm that the upstream should resolve the issue?
Bypass CC Switch and send the same request directly to the provider endpoint. Check whether the parameter for disabling thinking works, whether `stop` is accepted, and whether omitting `stream` returns JSON. If the same behavior occurs with a direct connection, report it to the upstream provider.

This is an unofficial community wiki with no affiliation to the cc-switch authors or the project itself. Its content is compiled from the project's public GitHub issues. This site distributes no software.