一键导入
provider-debug
Diagnoses openclaude provider configuration problems and proposes fixes.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Diagnoses openclaude provider configuration problems and proposes fixes.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Resolves merge and rebase conflicts by preserving both sides' intent.
Reads a CodeQL or static-analysis finding and produces a targeted fix.
Fixture where a curl-piped-to-bash sits inside a fenced block; scanner must still flag it.
Reviews database schema changes, migrations, and queries.
Implements frontend components following project conventions.
Diagnoses and fixes CI pipeline failures.
| name | provider-debug |
| title | Provider Debug |
| description | Diagnoses openclaude provider configuration problems and proposes fixes. |
| category | provider |
| tags | ["openclaude","provider","debugging","configuration"] |
| trust | official |
| version | 0.1.0 |
| license | MIT |
| author | gnanam |
A previously-working provider broke, or a switch between providers didn't take. Read the user's actual config, identify the layer that's wrong (model name, endpoint, flag conflict, request shape), and propose the smallest fix plus a verification command.
400 /
401 / 403 / 404 from the provider.Function tools with reasoning_effort are not supported for X in /v1/chat/completions or ERR_PACKAGE_PATH_NOT_EXPORTED coming
from the provider layer.provider-setup.error-message-decode or debugging./doctor inside openclaude (or bun run doctor:runtime
from the project root; bun run doctor:runtime:json if you want
structured output). Read the failed checks. doctor already
knows about the common provider misconfigurations and will
point at the bad fields by name.~/.openclaude/settings.json (and
.openclaude-profile.json in the project root if present —
project profile overrides the user-level file). Check:
model — does it match the provider's actual model name?
Model names aren't portable across providers.env — are the right vars set for the selected provider?effortLevel — reasoning_effort is rejected by some
OpenAI-compatible models on /v1/chat/completions; only
reasoning-capable models accept it.ANTHROPIC_API_KEY (Anthropic direct, the default)CLAUDE_CODE_USE_OPENAI=1 (OpenAI and OpenAI-compatible —
Ollama, LM Studio, LiteLLM, vLLM, Groq)CLAUDE_CODE_USE_GEMINI=1CLAUDE_CODE_USE_GITHUB=1CLAUDE_CODE_USE_BEDROCK=1CLAUDE_CODE_USE_VERTEX=1
If two flags are set, the precedence may not be what the user
expects. Unset the inactive ones.Function tools with reasoning_effort are not supported for <model> in /v1/chat/completions → either remove
effortLevel from settings, or switch model to one that
supports tools on /v1/chat/completions (e.g. gpt-5,
gpt-4.1).Model X not found → name mismatch. Compare against the
provider's published model list; copy the exact identifier.Invalid base URL / 404 on requests → trailing slash on
OPENAI_BASE_URL, or the /v1 path is missing.ollama list. Also confirm OPENAI_BASE_URL ends in
/v1 (Ollama's OpenAI-compatible endpoint).1234
by default.GITHUB_TOKEN is missing the
models:read scope.AWS_REGION or AWS credentials not
loaded; verify with aws sts get-caller-identity. For
AWS_BEARER_TOKEN_BEDROCK shape, confirm the token is set
(not the standard AWS keys).ANTHROPIC_VERTEX_PROJECT_ID or
CLOUD_ML_REGION mismatch; check the Vertex console for the
project's allowed regions.curl "$OPENAI_BASE_URL/models" -H "Authorization: Bearer $OPENAI_API_KEY". For Ollama:
ollama list. For Anthropic direct: a /v1/messages request
with a minimal prompt against $ANTHROPIC_BASE_URL. For
Bedrock: aws bedrock list-foundation-models --region $AWS_REGION.error.type, error.param, or error.code
that the user's terminal truncates.In scope: "I get a 400 saying reasoning_effort isn't supported
for gpt-5.4."
→ Read ~/.openclaude/settings.json. Either remove effortLevel
or change model to one that supports tools on
/v1/chat/completions. Verify by curling $OPENAI_BASE_URL/models
to confirm auth works at all, then re-issue the failing call.
In scope: "Ollama is configured but openclaude says connection refused."
→ Run ollama list first. If Ollama isn't responding, start the
daemon. If ollama list works but openclaude still fails, check
OPENAI_BASE_URL ends in /v1 and CLAUDE_CODE_USE_OPENAI=1
is set.
In scope: "I switched from Anthropic to OpenAI and nothing works."
→ Probable cause: ANTHROPIC_API_KEY is still in the environment
alongside CLAUDE_CODE_USE_OPENAI=1. Unset the stale flag, restart
the shell, run /doctor.
Out of scope: "Which provider should I use?"
→ Advisory question, not a broken config. Suggest provider-setup
for a clean install, or ask the user about their constraints
(local vs cloud, latency, budget) and answer directly.
~/.openclaude/settings.json (and any
.openclaude-profile.json) before guessing?CLAUDE_CODE_USE_* flags being set
simultaneously?/v1/responses versus /v1/chat/completions?