#Error: Unknown model: minimax/MiniMax-M2.1

1 messages · Page 1 of 1 (latest)

daring wolfBOT
#

Hey ninuz! The MiniMax model needs to be configured through OpenRouter since Clawdbot doesn't have a native MiniMax provider. The model ID would be something like openrouter/minimax/minimax-m2.1 (lowercase usually matters).

A few things to check:

  1. Make sure you have OpenRouter configured with an API key in your config
  2. The model ID format for OpenRouter models is typically openrouter/<provider>/<model>

Want me to look up the exact model ID from OpenRouter's model list? Or if you share what you put in your config (without the API key!), I can spot what might be off.

sleek silo
#

Providers via models.providers (custom/base URL)
Use models.providers (or models.json) to add custom providers or OpenAI/Anthropic‑compatible proxies.

MiniMax
MiniMax is configured via models.providers because it uses custom endpoints:
MiniMax Cloud (OpenAI‑compatible): --auth-choice minimax-cloud

do i understand this part of the docs wrong?

daring wolfBOT
#

Ah, let me check the actual config schema to see how MiniMax should be set up:

#

Ah, you're reading the docs correctly! The error Unknown model: minimax/MiniMax-M2.1 means you've got the model ID right, but the provider isn't configured yet.

You need to add MiniMax to models.providers in your config. Something like:

models:
  providers:
    minimax:
      baseUrl: "https://api.minimax.chat/v1"  # or whatever their OpenAI-compatible endpoint is
      apiKey: "your-minimax-api-key"
      api: openai-completions
      models:
        - id: MiniMax-M2.1
          name: MiniMax M2.1
          reasoning: false
          input: ["text", "image"]
#
          contextWindow: 128000
          maxTokens: 16384
          cost:
            input: 0.0001
            output: 0.0003
            cacheRead: 0
            cacheWrite: 0

Then reference it as minimax/MiniMax-M2.1.

The --auth-choice minimax-cloud thing in the docs is for the wizard setup flow — it handles creating this config for you. Did you run the wizard with that option, or are you editing config manually?

sleek silo
#

i used the clawdbot configure and went to the models config

daring wolfBOT
#

Got it. Can you share what you've got in your models.providers section? (Minus the API key obviously)

Either paste the relevant bit from your config file, or run:

clawdbot config get models.providers

That'll help me spot what's off — might be a typo in the model ID, missing required fields, or the provider name not matching what you're referencing.

sleek silo
#

"agents": {
"defaults": {
"models": {
"minimax/MiniMax-M2.1": {
"alias": "Minimax"
}
},
"model": {
"primary": "minimax/MiniMax-M2.1"
}
}
},
"models": {
"mode": "merge",
"providers": {
"minimax": {
"baseUrl": "https://api.minimax.io/v1",
"apiKey": "minimax",
"api": "openai-completions",
"models": [
{
"id": "MiniMax-M2.1",
"name": "MiniMax M2.1",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 200000,
"maxTokens": 8192
}
]
}
}
}

daring wolfBOT
#

Config looks correct to me! The provider and model are properly defined.

Two things to check:

  1. Did the config get applied? After saving, Clawdbot should hot-reload, but sometimes a restart helps:

    /restart
    

    or just restart the gateway process

  2. Is the apiKey actually set? You've got "apiKey": "minimax" — is that a placeholder or did you mean to put your actual MiniMax API key there?

If you've already restarted and the key is real, can you check what the gateway actually loaded?

clawdbot config get models.providers.minimax
#

That'll confirm whether the provider config made it in.

sleek silo
#

its a placeholder, but it seems to be using anthropic model by default and whne switching to minmax it print that asme error

daring wolfBOT
#

Ah okay, so the config is there but the gateway isn't recognizing the model when you try to switch. That suggests the provider config might not have been loaded properly.

Try a restart first:

/restart

If that doesn't fix it, check what the running gateway actually has:

clawdbot config get models.providers.minimax

If that comes back empty or different from what you saved, the config file might not have been written to the right place, or there's a syntax issue earlier in the file that's causing it to fail to parse.

Also worth checking the logs right after startup — if there's a config error it should show up there:

#
journalctl -u clawdbot -n 50

(or however you're running it)

sleek silo
#

clawdbot@sleek hinge:~/clawd$ clawdbot config get models.providers.minimax
error: too many arguments for 'configure'. Expected 0 arguments but got 2.
clawdbot@sleek hinge:~/clawd$

daring wolfBOT
#

Ah, different CLI syntax than I assumed. Let's just check the config file directly:

cat ~/.config/clawdbot/config.json | jq '.models.providers'

Or if you don't have jq:

cat ~/.config/clawdbot/config.json

And for the restart, try:

sudo systemctl restart clawdbot

(or however you're running it — pm2, docker, etc.)

sleek silo
#

my config isnt there btw, its located in ~/.clawdbot/clawdbot.json

daring wolfBOT
#

Got it, non-standard location. Let's verify the config is actually there:

cat ~/.clawdbot/clawdbot.json | jq '.models.providers'

And then restart the gateway to make sure it picks it up:

systemctl --user restart clawdbot

or if it's running as a system service:

sudo systemctl restart clawdbot
#

or just kill and rerun however you started it.

After restart, try /model minimax/MiniMax-M2.1 again and let me know if same error.

sleek silo
#

right the model command worked, how do i set that model as default?

daring wolfBOT
#

Nice! You actually already have it set as default in your config:

"agents": {
  "defaults": {
    "model": {
      "primary": "minimax/MiniMax-M2.1"
    }
  }
}

After that restart it should already be the default for new sessions. Existing sessions might still be on the old model — you can either /model minimax/MiniMax-M2.1 in those, or /reset to start fresh.

If it's still not defaulting, double-check the config was saved and restart once more. The agents.defaults.model.primary is the key field.

sleek silo
#

aight seems to work now, i just remove all the other providers and restart and seems to work.
On a side note, sessions how do they work?
It seems that i have one session only called agent:main:main, if i text from whatsapp for example everything is dumped there, where before i used to have multiple sessions

daring wolfBOT
#

Glad it's working!

Sessions are controlled by session.scope in your config:

  • per-sender — separate session per conversation/user (WhatsApp DM = one session, Telegram chat = another, etc.)
  • global — everything goes to one session (agent:main:main)

Sounds like you've got global set. If you want separate sessions per chat like before:

"session": {
  "scope": "per-sender"
}

Or via clawdbot configure → Session settings.

#

With per-sender, you'll get session keys like whatsapp:+1234567890 or discord:dm:userid — each with their own conversation history.

sleek silo
#

got it, whats the default?

daring wolfBOT
#

Default is per-sender — so you (or the setup wizard) must have set it to global at some point.

If you didn't explicitly want global, just remove the session.scope line or set it back to per-sender and restart.

sleek silo
#

i dont have any sessions entry in my config?

daring wolfBOT
#

Huh, weird — without a session entry it should default to per-sender.

Try adding it explicitly and restart:

"session": {
  "scope": "per-sender"
}

If it's still behaving as global after that, something else might be routing everything to main. Can you share your full config (minus API keys)? Might be something in agents or bindings causing it.

sleek silo
#

aight cna i check wiht the cli?

daring wolfBOT
#

Yeah, just grep or jq your config:

cat ~/.clawdbot/clawdbot.json | jq '.session'

If that returns null or nothing, then there's no session config and it should be defaulting to per-sender.

You can also check active sessions with:

clawdbot sessions

That'll show what sessions exist and their keys — should help see if new messages are creating separate sessions or all going to one.

sleek silo
#

nah it just use one session for both the chat on the ui and my whatsapp for example

Session store: /home/clawdbot/.clawdbot/agents/main/sessions/sessions.json
Sessions listed: 1
Kind Key Age Model Tokens (ctx %) Flags
direct agent:main:main 1m ago MiniMax-M2.1 7.4k/200k (4%) system id:9dc0117b-597d-412f-8d2c-5b535e46f491

daring wolfBOT
#

That's definitely not default behavior. Something's routing everything to agent:main:main.

Can you share your full config? Just redact API keys:

cat ~/.clawdbot/clawdbot.json | sed 's/"apiKey": "[^"]*"/"apiKey": "REDACTED"/g; s/"token": "[^"]*"/"token": "REDACTED"/g; s/"botToken": "[^"]*"/"botToken": "REDACTED"/g'

There's probably a session.mainKey set, or something in bindings/agents forcing everything to main.

sleek silo
#

{
"wizard": {
"lastRunAt": "2026-01-11T07:43:11.418Z",
"lastRunVersion": "2026.1.10",
"lastRunCommand": "configure",
"lastRunMode": "local"
},
"browser": {
"enabled": true,
"executablePath": "/usr/bin/google-chrome-stable",
"headless": true,
"noSandbox": true
},
"auth": {
"profiles": {
"anthropic:default": {
"provider": "anthropic",
"mode": "oauth"
},
"openai-codex:default": {
"provider": "openai-codex",
"mode": "oauth"
},
"minimax:default": {
"provider": "minimax",
"mode": "api_key"
}
}
},
"models": {
"mode": "merge",
"providers": {
"minimax": {
"baseUrl": "https://api.minimax.io/v1",
"apiKey": "REDACTED",
"api": "openai-completions",
"models": [
{
"id": "MiniMax-M2.1",
"name": "MiniMax M2.1",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 200000,
"maxTokens": 8192
}
]
}
}
},
"agents": {
"defaults": {
"model": {
"primary": "minimax/MiniMax-M2.1"
},
"models": {
"minimax/MiniMax-M2.1": {
"alias": "Minimax"
}
},
"workspace": "/home/clawdbot/clawd"
}
},
"tools": {},
"messages": {
"groupChat": {
"mentionPatterns": [
"\b@?The\s+Intern\b",
"\b@?Deez\s+Scientist\b"
]
},
"ackReaction": "👀",
"ackReactionScope": "group-mentions"
},
"commands": {
"restart": true
},
"whatsapp": {
"dmPolicy": "pairing",
"allowFrom": [
"redacted",
"redacted"
],
"groupPolicy": "open",
"mediaMaxMb": 50
},
"discord": {
"token": "REDACTED",
"groupPolicy": "open",
"dm": {
"enabled": false,
"policy": "pairing"
},
"guilds": {
"646049745906696237": {
"slug": "rust",
"requireMention": true,
"reactionNotifications": "own",
"users": [
"205035034158170112"
],
"channels": {
"1458936141167202336": {
"requireMention": true
},
"646344122776420362": {
"requireMention": true
}
}
}
}
},
"gateway": {
"port": 18789,
"mode": "local",
"bind": "loopback",
"auth": {
"mode": "token",
"token": "REDACTED"
},
"tailscale": {
"mode": "serve",
"resetOnExit": false
}
},
"skills": {
"install": {
"nodeManager": "pnpm"
},
"entries": {
"bird": {
"enabled": true
}
}
}
}

daring wolfBOT
#

Config looks clean — no session block at all, so it should default to per-sender. This might be a bug or a recent default change.

Just add this explicitly and restart:

"session": {
  "scope": "per-sender"
}

Add it at the top level (same level as "agents", "discord", etc), then:

sudo systemctl restart clawdbot

After that, new messages from WhatsApp should create their own session separate from web UI. Existing agent:main:main session will stick around — you can /reset it or just let it be.

sleek silo
#

session: {
scope: "per-sender",
idleMinutes: 60,
heartbeatIdleMinutes: 120,
resetTriggers: ["/new", "/reset"],
store: "~/.clawdbot/agents/default/sessions/sessions.json",
typingIntervalSeconds: 5,
sendPolicy: {
default: "allow",
rules: [
{ action: "deny", match: { provider: "discord", chatType: "group" } }
]
}
},

this is the recommended from your docs, what it does?

daring wolfBOT
#

Here's the breakdown:

Field What it does
scope: "per-sender" Separate session per conversation (WhatsApp DM ≠ Discord DM ≠ web UI)
idleMinutes: 60 Session goes "idle" after 60min of no activity (affects heartbeat behavior)
heartbeatIdleMinutes: 120 Heartbeat polling stops after 2hrs idle
resetTriggers Commands that wipe session history and start fresh
store Where session state is persisted (path to JSON file)
typingIntervalSeconds: 5 How often to send "typing..." indicator during long responses
sendPolicy Controls where bot can proactively send messages

That last sendPolicy rule is interesting — it blocks the bot from sending unprompted messages to Discord group chats (but still allows replies to mentions). Keeps it from being noisy in servers.

Use that config as-is or trim what you don't need. The key one for your issue is scope: "per-sender".

sleek silo
#

aight if i create another agent will the sessions get merged in the same folder tho?

daring wolfBOT
#

Nope, each agent gets its own session store. The path pattern is:

~/.clawdbot/agents/<agent-id>/sessions/sessions.json

So if you create an agent called assistant and another called coder, they'd have:

  • ~/.clawdbot/agents/assistant/sessions/sessions.json
  • ~/.clawdbot/agents/coder/sessions/sessions.json

Sessions are namespaced by agent — completely separate histories, contexts, and workspaces. The session key format is agent:<agentId>:<sender>, so you'd see things like:

  • agent:assistant:whatsapp:+123...
  • agent:coder:discord:dm:456...

No cross-contamination.

sleek silo
#

aihgt so since my agent the main one is in
store: "~/.clawdbot/agents/main/sessions/sessions.json",

should i use that one instead of
store: "~/.clawdbot/agents/default/sessions/sessions.json",

default?

daring wolfBOT
#

Yeah, match it to your agent name. Since your agent is main, use:

"store": "~/.clawdbot/agents/main/sessions/sessions.json"

Or honestly, just omit the store field entirely — it should auto-default to the right path based on your agent ID. Less config to maintain.

sleek silo
#

The current session ID is agent:main:main 🧑‍💼

just started a new chat and still using the same single session

daring wolfBOT
#

Did you restart after adding the session config? And can you confirm it's actually in the config now:

cat ~/.clawdbot/clawdbot.json | jq '.session'

Should show your scope: "per-sender" etc. If it does and you've restarted, try messaging from WhatsApp specifically — the web UI might still hit the main session, but WhatsApp should create a new one like agent:main:whatsapp:+xxx.

sleek silo
#

well everyhting foes into one single session for some reason

daring wolfBOT
#

That's weird. Let's debug:

  1. Confirm the config is actually there:
cat ~/.clawdbot/clawdbot.json | jq '.session.scope'
  1. Check the logs for any session-related messages after restart:
journalctl -u clawdbot --since "10 minutes ago" | grep -i session
  1. What's your current session list look like?
clawdbot sessions
#

If .session.scope returns "per-sender" and it's still not working after a restart, this might be a bug. What version are you on?

clawdbot --version
sleek silo
#

Session store: /home/clawdbot/.clawdbot/agents/main/sessions/sessions.json
Sessions listed: 2
Kind Key Age Model Tokens (ctx %) Flags
direct agent:main:main just now MiniMax-M2.1 7.8k/200k (4%) system id:c4120aa0-dc26-4771-8aed-03c42318c451
direct main 8m ago MiniMax-M2.1 16k/200k (8%) id:b29536c1-d313-42de-b3d9-ccd31f25cba0

defo something off

daring wolfBOT
#

Yeah that's definitely wrong. Session key main by itself doesn't follow the agent:<id>:<sender> pattern at all.

Can you show me:

  1. Your full session config as it is now:
cat ~/.clawdbot/clawdbot.json | jq '.session'
  1. Version:
clawdbot --version

Something's misconfigured or there's a bug. Those session keys should look like agent:main:whatsapp:+123... or agent:main:discord:dm:205035034158170112, not just main.

sleek silo
#

{
"scope": "per-sender",
"resetTriggers": [
"/new",
"/reset"
],
"idleMinutes": 60,
"heartbeatIdleMinutes": 120,
"typingIntervalSeconds": 5,
"sendPolicy": {
"default": "allow",
"rules": [
{
"action": "deny",
"match": {
"provider": "discord",
"chatType": "group"
}
}
]
}
}

daring wolfBOT
#

Config looks right. What's the version?

clawdbot --version

Also try nuking the existing sessions and starting fresh:

rm ~/.clawdbot/agents/main/sessions/sessions.json
sudo systemctl restart clawdbot

Then message from WhatsApp and check clawdbot sessions again — see if it creates a properly-named session this time.

sleek silo
#

2026.1.10
this is the version
niope everything still get in the agent:main:main

daring wolfBOT
#

That's bizarre. Same version I'm on and it should work.

Let's check the logs when a message actually comes in:

journalctl -u clawdbot -f

Then send a message from WhatsApp (not the web UI) and see what it logs about session routing.

Also — when you say "started a new chat", are you testing from the web UI or from WhatsApp/Discord? The web UI might behave differently and use the main session regardless. Try specifically from WhatsApp to see if that creates a proper per-sender session.

sleek silo
#

i tried from whats up anyway this is the command resutls

clawdbot@sleek hinge:~/clawdbot$ journalctl -u clawdbot -f
Hint: You are currently not seeing messages from other users and the system.
Users in groups 'adm', 'systemd-journal' can see all messages.
Pass -q to turn off this notice.

daring wolfBOT
#

Try with sudo:

sudo journalctl -u clawdbot -f

Or if Clawdbot logs to a file, check there:

ls -la ~/.clawdbot/logs/

or

tail -f ~/.clawdbot/*.log
sleek silo
daring wolfBOT
#

The logs show the message coming in from WhatsApp (+34698254145) and being processed, but I don't see it logging which session key it's routing to. The internal sessionId (b7f316fe-...) is a UUID, not the session key.

The fact that it's going to agent:main:main despite scope: "per-sender" looks like a bug to me. Your config is correct.

Try enabling more verbose logging to see session routing:

# In your config, add:
"logging": {
  "level": "debug"
}

Then restart and send another WhatsApp message — should show more detail about how the session key is being determined.

If it still routes wrong, I'd file a bug on GitHub. Config says per-sender, version is current, but it's ignoring the scope. That's a defect.

#
# Quick workaround to test — you could try explicitly setting mainKey to something invalid:
"session": {
  "scope": "per-sender",
  "mainKey": null
}

See if that changes anything.

sleek silo
#

with the "mainKey": null it print invalid config, ia dded logging

daring wolfBOT
#

Yeah, skip the mainKey thing — bad suggestion.

With debug logging enabled, restart and send a WhatsApp message:

sudo systemctl restart clawdbot

Then check logs again after sending from WhatsApp. Look for anything about "session" or "scope" — should show how it's deciding which session to use.

sleek silo
#

not seeing anything partoculary helpful, just the message bneing sent and revceived honestly

daring wolfBOT
#

Alright, at this point I think you've hit a bug. Your config is correct:

  • session.scope: "per-sender"
  • Version is current (2026.1.10) ✓
  • Restarted multiple times ✓
  • Deleted old sessions ✓

But it's still routing everything to agent:main:main.

I'd file an issue on GitHub:

Title: session.scope "per-sender" not creating separate sessions

Config has session.scope: "per-sender" but all messages 
(WhatsApp, web UI) route to agent:main:main instead of 
creating per-sender sessions like agent:main:whatsapp:+xxx
#

Version: 2026.1.10

Include your config (redacted) and the logs you shared.

In the meantime — does it actually break anything for you, or is it just not what you expected? If you're the only user, one session might work fine. If you need separate contexts per chat, then yeah it's blocking.

sleek silo
#

yeah i need separate context, whats the default main key by default?

daring wolfBOT
#

The default mainKey is "main" — that's why you're seeing agent:main:main.

The session key format is agent:<agentId>:<sessionKey>, so:

  • agent:main:main = agent "main", session "main"

With per-sender, it should be creating keys like:

  • agent:main:whatsapp:+34698254145
  • agent:main:discord:dm:205035034158170112

But something's making it fall back to main for the session key part instead of using the sender identifier.

Wild guess — do you have any bindings in your config? Or anything in agents.main specifically (not just agents.defaults)?

cat ~/.clawdbot/clawdbot.json | jq '.agents'
sleek silo
#

clawdbot@sleek hinge:~/clawdbot$ cat ~/.clawdbot/clawdbot.json | jq '.agents'
{
"defaults": {
"model": {
"primary": "minimax/MiniMax-M2.1"
},
"models": {
"minimax/MiniMax-M2.1": {
"alias": "Minimax"
}
},
"workspace": "/home/clawdbot/clawd"
}
}

daring wolfBOT
#

Clean — no weird agent overrides.

Check bindings too:

cat ~/.clawdbot/clawdbot.json | jq '.bindings'

If that's empty/null, then there's nothing routing explicitly. Which means the per-sender scope should just work...

At this point I'm out of ideas for quick fixes. Definitely file the bug. You could also try asking in the Discord/GitHub discussions if anyone else has hit this — might be a known issue with a workaround I'm not aware of.

sleek silo
#

right lets try to restart clean ig uess any idea?

daring wolfBOT
#

Yeah, let's try a full clean slate:

# Backup your config first
cp ~/.clawdbot/clawdbot.json ~/.clawdbot/clawdbot.json.backup

# Nuke all session state
rm -rf ~/.clawdbot/agents/

# Restart
sudo systemctl restart clawdbot

Then send a message from WhatsApp (not web UI) and immediately check:

#
clawdbot sessions

If it still creates agent:main:main instead of agent:main:whatsapp:+34..., then the bug is definitely in the code path, not leftover state.

sleek silo
#

still the same, if i want to start fresh complelely?

daring wolfBOT
#

Full nuke and reinstall:

# Stop the service
sudo systemctl stop clawdbot

# Backup config just in case
cp ~/.clawdbot/clawdbot.json ~/clawdbot-config-backup.json

# Remove all clawdbot state
rm -rf ~/.clawdbot

# Re-run setup wizard
clawdbot configure

The wizard will walk you through everything again — model setup, WhatsApp linking, Discord token, etc.

#

When you get to session settings, explicitly pick per-sender and see if a fresh setup behaves differently.

If it still routes everything to one session after a completely fresh install, that's 100% a bug and you should definitely report it.

sleek silo
#

Clawdbot treats one direct-chat session per agent as primary. Direct chats collapse to agent:<agentId>:<mainKey> (default main), while group/channel chats get their own keys. session.mainKey is honored.

Gateway is the source of truth
All session state is owned by the gateway (the “master” Clawdbot). UI clients (macOS app, WebChat, etc.) must query the gateway for session lists and token counts instead of reading local files.
In remote mode, the session store you care about lives on the remote gateway host, not your Mac.
Token counts shown in UIs come from the gateway’s store fields (inputTokens, outputTokens, totalTokens, contextTokens). Clients do not parse JSONL

just so i uinderstand, expolain this like im retarded

daring wolfBOT
#

OH. That's the answer right there.

Direct chats (DMs) all go to ONE session per agent. That's by design, not a bug.

Here's the breakdown:

Chat Type Session Key
WhatsApp DM agent:main:main
Telegram DM agent:main:main
Discord DM agent:main:main
Discord server channel agent:main:discord:guild:646049745906696237:channel:1459801335645077566
WhatsApp group agent:main:whatsapp:group:xyz

So all your DMs share one brain, but each group chat gets its own.

The per-sender scope gives separate sessions for different group chats, not different DM contacts.

#

If you want separate sessions per WhatsApp contact, you'd need multiple agents with bindings routing specific numbers to specific agents. That's more complex.

TL;DR: You're not hitting a bug. DMs collapsing to one session is intentional. The bot has "one direct conversation" with you across all DM surfaces.

frosty tartan
#

is there a workaround for this:

"errorMessage": "400 {"type":"error","error":{"type":"invalid_request_error","message":"This credential is only authorized for use with Claude Code and cannot be used for other API requests."},"request_id":"req_011CX2okn64Ti5hkwAv53B7P"}"

daring wolfBOT
#

429 {"type":"error","error":{"type":"rate_limit_error","message":"This request would exceed your account's rate limit. Please try again later."},"request_id":"req_011CX2oq4AZYk928tTEBbVRg"}

mystic jolt
#

what's the latest on fixing 'This credential is only authorized for use with Claude Code' @daring wolf is this a solved issue or is it onging? comiing back to clawdbot after a week away so i'm out of loop and seeing this error

daring wolfBOT
#

Hey! 👋 This error is documented behavior, not a bug. Here's the deal:

The error: This credential is only authorized for use with Claude Code means you're using a Claude CLI setup-token that's restricted to Claude Code itself.

The solution: Use an Anthropic API key instead. From the docs:

"If you see this error, use an Anthropic API key instead."

How to fix:

  1. Create an API key in the Anthropic Console
  2. Either:
    • Set export ANTHROPIC_API_KEY="..." on your gateway host, or
    • Add it to ~/.clawdbot/.env for daemon use
    • Or run clawdbot onboard to store it via wizard

Then verify with:

#
clawdbot models status
clawdbot doctor

The docs recommend API keys over the Claude CLI token for this exact reason — API keys don't have this restriction.

So this is a known limitation/workaround, not something actively being "fixed" — it's by design on Anthropic's side. The recommended path is simply to use API keys. 🦐

mystic jolt
#

(sorry wrong channel)