#Minimax image understanding doesnt work on a fresh installed openclaw

1 messages · Page 1 of 1 (latest)

balmy echo
#

help, im using the same model, minimax m2.7 which doesnt support multimodal, my old vps have an image understanding feature while the new one doesnt, why? it's a fresh installed openclaw, it's builtin feature right?

rose baneBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

worn folioBOT
#

Yes — but it’s not M2.7 itself doing vision.

MiniMax M2.7 is text-only. OpenClaw’s “image understanding” for MiniMax is a separate built-in media provider using MiniMax-VL-01, registered by the MiniMax plugin. So your old VPS probably had one of these working:

  • MiniMax auth available to the gateway
  • agents.defaults.imageModel set
  • media understanding not disabled
  • another fallback like Gemini/OpenAI/etc configured

On the fresh VPS, likely the image media provider isn’t being selected/configured yet.

Please paste these outputs first:

openclaw --version
openclaw models status
# 
openclaw models list --provider minimax --all
openclaw models list --provider minimax-portal --all

If you use MiniMax API key, try setting image model explicitly:

openclaw models set-image minimax/MiniMax-VL-01
openclaw gateway restart

If you use MiniMax OAuth/Coding Plan:

openclaw models set-image minimax-portal/MiniMax-VL-01
balmy echo
#

ive run MiniMax OAuth/Coding Plan then my openclaw isnt responding messages from wahtsapp

worn folioBOT
#

MiniMax OAuth shouldn’t break WhatsApp directly — more likely it changed the default model/auth path and the agent is now failing before it can reply.

First do a safe restart, then check status:

openclaw gateway restart
openclaw --version
openclaw gateway status
openclaw models status
openclaw channels status --probe

Then send one WhatsApp test message and immediately run:

openclaw channels logs --channel whatsapp --lines 200
# 
openclaw logs --limit 200 --plain

Please paste the output/errors from those. The key thing I’m looking for is whether WhatsApp is receiving inbound messages but the model run fails, or whether the WhatsApp channel itself disconnected.

Common causes after MiniMax OAuth/Coding Plan setup:

  • gateway wasn’t restarted after auth/model change
  • models status shows MiniMax auth missing/expired
  • default model switched to minimax-portal/MiniMax-M2.7 but the gateway host can’t see that auth profile
  • WhatsApp account is disconnected / needs re-login

Docs: https://docs.openclaw.ai/help/faq https://docs.openclaw.ai/channels/whatsapp

balmy echo
#
  • minimax-portal
    • minimax-portal:default ok expires in 365d

🦞 OpenClaw 2026.4.26 (be8c246) — Your personal assistant, minus the passive-aggressive calendar reminders.

│
â—‡
Gateway not reachable: gateway timeout after 30000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /root/.openclaw/openclaw.json
Bind: loopback
Gateway not reachable; showing config-only status.
Config: /root/.openclaw/openclaw.json
Mode: local

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).
[root@server-9l6wy4 .openclaw]#

worn folioBOT
#

That output means MiniMax OAuth is fine, but the Gateway is not reachable. So WhatsApp won’t respond because the main OpenClaw process is down/hung/unreachable — not because of image understanding yet.

Run this on the VPS:

openclaw gateway restart
sleep 5
openclaw gateway status --deep --require-rpc

If it still says timeout, grab service logs:

systemctl --user status openclaw-gateway.service --no-pager
journalctl --user -u openclaw-gateway.service --no-pager -n 120
openclaw logs --limit 200 --plain
#

If systemctl says the service doesn’t exist, start/install it:

openclaw gateway install --force
openclaw gateway start

Then recheck:

openclaw status
openclaw channels status --probe

Paste the journalctl / openclaw logs error if it still won’t start. Main clue right now: Gateway not reachable: gateway timeout after 30000ms.

Docs: https://docs.openclaw.ai/gateway/troubleshooting

weak stirrup
#

If you are using OpenClaw 2026.4.26 there are serious issues. I couldn't get it to work and had to downgrade to 2026.04.23

worn folioBOT
#

Yeah, that’s plausible. We’ve had a few reports around 2026.4.24–2026.4.26 where the gateway/runtime-deps path looked suspicious.

For kremie specifically: the current blocker is not WhatsApp or MiniMax yet — it’s this:

Gateway not reachable: gateway timeout after 30000ms

If they need a quick recovery, pinning back to 2026.4.23 is reasonable. Use the actual tag 2026.4.23:

cp -a ~/.openclaw ~/.openclaw.backup-$(date +%Y%m%d-%H%M%S)

openclaw update --tag 2026.4.23 --dry-run
openclaw update --tag 2026.4.23
openclaw gateway restart
fresh onyx
#

Same here. My gpt5.4 couldn't read images after upgrading

worn folioBOT
#

That’s useful signal — if an image-capable primary model stopped reading images after upgrade, that points more toward an OpenClaw routing/regression issue than MiniMax specifically.

Quick check:

openclaw --version
openclaw models status
openclaw gateway status --deep --require-rpc
openclaw logs --limit 300 --plain

For image-capable primary models, OpenClaw should pass the original image through natively. agents.defaults.imageModel is mainly for when the primary model is text-only.

If you’re also on 2026.4.26 and need a fast recovery, try pinning back:

# 
cp -a ~/.openclaw ~/.openclaw.backup-$(date +%Y%m%d-%H%M%S)
openclaw update --tag 2026.4.23
openclaw gateway restart

If that fixes images, please file the before/after version + logs here: https://github.com/openclaw/openclaw/issues

balmy echo
#

downgrade error cp -a ~/.openclaw ~/.openclaw.backup-$(date +%Y%m%d-%H%M%S)

openclaw update --tag 2026.4.23 --dry-run
openclaw update --tag 2026.4.23
openclaw gateway restart
cp: cannot stat '/root/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-4eca5026e977/.openclaw-runtime-mirror.lock': No such file or directory
Update dry-run
No changes were applied.

Root: /usr/lib/node_modules/openclaw
Install kind: package
Mode: npm
Channel: stable
Tag/spec: openclaw@2026.4.23
Current version: 2026.4.26
Target version: 2026.4.23
Downgrade confirmation would be required in a real run.

Planned actions:

  • Run global package manager update with spec openclaw@2026.4.23
  • Run plugin update sync after core update
  • Refresh shell completion cache (if needed)
  • Restart gateway service and run doctor checks
    │
    â—‡ Downgrading from 2026.4.26 to 2026.4.23 can break configuration. Continue?
    │ Yes
    Updating OpenClaw...

│
â—‡ âś“ Updating via package manager (64.11s)

Update Result: ERROR
Root: /usr/lib/node_modules/openclaw
Reason: global install verify
Before: 2026.4.26
After: 2026.4.26

Total time: 68.61s

🦞 OpenClaw 2026.4.26 (be8c246) — The only crab in your contacts you actually want to hear from. 🦞

Restarted systemd service: openclaw-gateway.service

worn folioBOT
#

The cp error is probably just the runtime-deps cache changing while you copied it. Don’t worry — that’s not your real config/state.

Do this instead, with the gateway stopped and excluding that cache:

openclaw gateway stop

tar --exclude="$HOME/.openclaw/plugin-runtime-deps" \
  -czf "$HOME/openclaw-state-backup-$(date +%Y%m%d-%H%M%S).tgz" \
  -C "$HOME" .openclaw

Then bypass openclaw update and force the npm package version directly:

npm install -g openclaw@2026.4.23
# 
hash -r
openclaw --version

If it now shows 2026.4.23, refresh the service and start it:

openclaw gateway install --force
openclaw gateway start
openclaw gateway status --deep --require-rpc

If openclaw --version still says 2026.4.26, paste:

# 
which openclaw
npm root -g
npm ls -g openclaw --depth=0
balmy echo
#

it works now

worn folioBOT
#

Glad it’s working now 🎉

If this fixed the thread, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for the next person.

balmy echo
#

by emoji?