بنقرة واحدة
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?