Summary
OpenClaw can report anthropic:claude-cli as expired / expiring in model auth status even though Claude CLI local credentials are fresh enough for successful runtime use.
In my case:
claude --print -p "say hello" worked
- an OpenClaw ACP Claude session also worked
- but
openclaw models status still reported stale/incorrect claude-cli auth state until I manually rewrote the OpenClaw auth profile
This looks like a mismatch between:
- runtime credential loading for Claude CLI
- and the stored/profile-based auth health/status path
Environment
- OpenClaw version:
2026.4.22
- Install path:
/usr/lib/node_modules/openclaw
- Host: Linux (Debian 13 in LXC)
What I observed
Before repair:
openclaw models status showed anthropic:claude-cli expired / expiring
- local Claude CLI invocation still worked
- OpenClaw ACP Claude spawn also succeeded
Relevant files:
- OpenClaw stored auth profile:
/root/.openclaw/agents/main/agent/auth-profiles.json
- Claude local credentials:
/root/.claude/.credentials.json
After running:
openclaw models auth login --provider anthropic --method cli --set-default
…the status changed from stale expired to expiring, and runtime continued to work.
Why this seems like a bug
The runtime path appears able to use fresh Claude CLI credentials, while auth health/status can still rely on stale stored profile data.
From code inspection, likely relevant files are:
/usr/lib/node_modules/openclaw/dist/auth-health-C2llzDPf.js
/usr/lib/node_modules/openclaw/dist/auth-profiles-BdVv03AU.js
/usr/lib/node_modules/openclaw/dist/store-DvC8xs3S.js
/usr/lib/node_modules/openclaw/dist/prepare.runtime-uR-bHnQr.js
Expected behavior
If Claude CLI local credentials are valid enough for runtime use, openclaw models status / auth health should reflect that consistently, or at least clearly distinguish:
- stored OpenClaw auth profile state
- live external CLI credential state
Actual behavior
Status/health can show expired / expiring for claude-cli even while:
- direct Claude CLI calls work
- OpenClaw Claude ACP sessions work
Repro idea
- Have working Claude CLI local auth
- Let OpenClaw stored auth profile become stale or drift from Claude CLI local credentials
- Run
openclaw models status
- Compare with:
claude --print -p "say hello"
- a real OpenClaw Claude ACP run
Workaround
Re-run:
openclaw models auth login --provider anthropic --method cli --set-default
…but this only refreshes the OpenClaw-side stored profile; it does not seem to solve the underlying status/runtime mismatch.
Summary
OpenClaw can report
anthropic:claude-cliasexpired/expiringin model auth status even though Claude CLI local credentials are fresh enough for successful runtime use.In my case:
claude --print -p "say hello"workedopenclaw models statusstill reported stale/incorrectclaude-cliauth state until I manually rewrote the OpenClaw auth profileThis looks like a mismatch between:
Environment
2026.4.22/usr/lib/node_modules/openclawWhat I observed
Before repair:
openclaw models statusshowedanthropic:claude-cli expired/expiringRelevant files:
/root/.openclaw/agents/main/agent/auth-profiles.json/root/.claude/.credentials.jsonAfter running:
openclaw models auth login --provider anthropic --method cli --set-default…the status changed from stale
expiredtoexpiring, and runtime continued to work.Why this seems like a bug
The runtime path appears able to use fresh Claude CLI credentials, while auth health/status can still rely on stale stored profile data.
From code inspection, likely relevant files are:
/usr/lib/node_modules/openclaw/dist/auth-health-C2llzDPf.js/usr/lib/node_modules/openclaw/dist/auth-profiles-BdVv03AU.js/usr/lib/node_modules/openclaw/dist/store-DvC8xs3S.js/usr/lib/node_modules/openclaw/dist/prepare.runtime-uR-bHnQr.jsExpected behavior
If Claude CLI local credentials are valid enough for runtime use,
openclaw models status/ auth health should reflect that consistently, or at least clearly distinguish:Actual behavior
Status/health can show
expired/expiringforclaude-clieven while:Repro idea
openclaw models statusclaude --print -p "say hello"Workaround
Re-run:
…but this only refreshes the OpenClaw-side stored profile; it does not seem to solve the underlying status/runtime mismatch.