Openclaw Remote Minimax Setup

OpenClaw Remote MiniMax Setup

Set up a remote OpenClaw host in a repeatable, low-surprise way.

Scope

Use this skill for remote Linux deployments where the user provides:

• SSH access
• A MiniMax API key
• A Telegram bot token
• A target model of minimax/MiniMax-M2.1

Prefer the official OpenClaw documentation first, then execute the deployment over SSH.

Read these references when needed

• Read references/workflow.md for the full deployment flow.
• Read references/config-template.md before writing or patching the remote OpenClaw config.
• Read references/failure-modes.md when Telegram does not reply, the gateway exits after install, or the service dies after SSH disconnect.

Core rules

• Do not publish or store user secrets in the skill, repo, or commit history.
• Replace all secrets in examples with environment placeholders.
• Validate the remote config before declaring success.
• Verify both the model path and the Telegram path.
• Treat a successful install as incomplete until the service survives SSH disconnect.

Minimal workflow

1. Read the relevant OpenClaw docs for installation, providers, and Telegram. 2. Inspect the remote host: OS, sudo availability, curl, node, and openclaw. 3. Install OpenClaw safely.

• Prefer fetching the official installer locally, reviewing it, copying it to the remote host, and executing it there.

4. Write a minimal config using the MiniMax China endpoint and Telegram bot token. 5. Run openclaw config validate. 6. Ensure gateway.mode=local before first service start. 7. Install and start the gateway service. 8. Enable persistence for systemctl --user deployments.

• On remote VPS installs, run sudo loginctl enable-linger <user>.

9. Verify with:

• openclaw gateway status
• openclaw status
• a local smoke test against MiniMax-M2.1
• a Telegram send test

10. If outbound Telegram send says chat not found, tell the user to open the bot DM and press Start, then retry.

Completion standard

Only call the deployment complete when all of the following are true:

• openclaw gateway status reports Runtime: running
• openclaw status shows Telegram ON and OK
• A local agent test returns through MiniMax-M2.1
• A Telegram test message can be delivered after the user has started the bot
• The service remains active after SSH disconnect because linger is enabled

Output style

When reporting progress or completion:

• State what was installed
• State the configured model and provider endpoint
• State the Telegram bot username
• State the last blocking issue, if any
• End with the exact next user action if a manual Telegram step is still required

Config template

Use this as a sanitized starting point for a remote OpenClaw host.

{
  gateway: {
    mode: "local",
  },

  env: {
    MINIMAX_API_KEY: "${MINIMAX_API_KEY}",
    TELEGRAM_BOT_TOKEN: "${TELEGRAM_BOT_TOKEN}",
  },

  agents: {
    defaults: {
      workspace: "~/.openclaw/workspace",
      model: {
        primary: "minimax/MiniMax-M2.1",
      },
      models: {
        "minimax/MiniMax-M2.1": { alias: "Minimax" },
      },
    },
  },

  channels: {
    telegram: {
      enabled: true,
      botToken: "${TELEGRAM_BOT_TOKEN}",
      dmPolicy: "allowlist",
      allowFrom: ["<telegram-user-id>"],
    },
  },

  models: {
    mode: "merge",
    providers: {
      minimax: {
        baseUrl: "https://api.minimaxi.com/anthropic",
        apiKey: "${MINIMAX_API_KEY}",
        api: "anthropic-messages",
        models: [
          {
            id: "MiniMax-M2.1",
            name: "MiniMax M2.1",
            reasoning: false,
            input: ["text"],
            cost: { input: 15, output: 60, cacheRead: 2, cacheWrite: 10 },
            contextWindow: 200000,
            maxTokens: 8192,
          },
        ],
      },
    },
  },
}

Notes

• Keep secrets in environment placeholders in examples and public repos.
• The model reference is case-sensitive: minimax/MiniMax-M2.1.
• For a single-user Telegram bot, an allowlist is a good default.
• If the deployment is multi-user or group-oriented, adjust Telegram policy intentionally instead of removing controls blindly.

Failure modes

1. Gateway exits right after install

Symptom

openclaw config validate passes, but openclaw gateway start fails and the service loops.

Common cause

gateway.mode is unset.

Fix

openclaw config set gateway.mode local
openclaw gateway start
openclaw gateway status

Why this matters

A config can be schema-valid and still fail the first runtime gate.

---

2. Telegram send returns chat not found

Symptom

Outbound sendMessage fails with Telegram 400: Bad Request: chat not found.

Common causes

• the user never opened the bot DM and pressed Start
• the target chat ID is wrong
• the bot token is wrong
• the bot was removed from the destination chat

Fix

Tell the user to:

1. open the bot by username 2. press Start 3. send hi

Then retry the outbound send.

---

3. Bot worked during SSH session, then stopped replying later

Symptom

The deployment seemed fine while the SSH session was active, but later the bot did not respond.

Common cause

OpenClaw was installed as a systemctl --user service and lingering was not enabled. The user systemd manager was torn down after the SSH login ended.

Fix

sudo loginctl enable-linger <user>
systemctl --user restart openclaw-gateway.service

Then verify:

loginctl show-user <user> -p Linger
systemctl --user is-active openclaw-gateway.service

Expected: Linger=yes.

---

4. MiniMax silently falls back or does not behave as expected

Symptom

The deployment looks alive, but replies are not coming from MiniMax M2.1.

Common causes

• invalid or expired API key
• provider block missing or malformed
• wrong model casing

Fix

Verify all three:

• provider key is valid
• model path is exactly minimax/MiniMax-M2.1
• a local smoke test reports provider minimax and model MiniMax-M2.1

---

5. Service status is ambiguous

Symptom

openclaw status or gateway status gives mixed signals because the service recently restarted.

Fix

Use all of these together:

openclaw gateway status
openclaw status
journalctl --user -u openclaw-gateway.service -n 100 --no-pager

Do not trust a single success line if the journal shows repeated SIGTERM or start loops.

Workflow

1. Confirm the target outcome

Collect only the inputs that are actually required:

• server host or IP
• SSH username
• authentication method
• MiniMax API key
• Telegram bot token
• desired model: minimax/MiniMax-M2.1

Do not ask for extra preferences unless the user explicitly wants custom routing, multi-agent setup, or public gateway exposure.

2. Read the official docs first

Before touching the remote machine, check the relevant OpenClaw docs:

• getting started / install
• model provider configuration
• MiniMax provider notes
• Telegram channel behavior

Use the docs to confirm the expected config shape and current CLI behavior.

3. Inspect the remote host

Run quick checks first:

whoami
uname -a
command -v curl
command -v node || true
command -v openclaw || true
sudo -n true && echo SUDO_OK || echo SUDO_NEEDS_PASSWORD

This tells you whether you are doing a first install or patching an existing host.

4. Install OpenClaw safely

Prefer this pattern over curl ... | bash directly on the remote host:

1. Download the official installer locally. 2. Review it. 3. Copy it to the remote machine. 4. Execute it remotely.

That keeps the flow auditable and avoids shell-policy blocks in many environments.

5. Write the minimal working config

Use a config with these properties:

• gateway.mode: local
• agents.defaults.model.primary: minimax/MiniMax-M2.1
• models.mode: merge
• MiniMax provider using the China endpoint
• Telegram enabled with the bot token
• optional DM allowlist if the deployment is for one user only

See config-template.md.

6. Validate before first start

Run:

openclaw config validate

Do not assume a syntactically valid config is sufficient for runtime success. First-boot runtime checks can still fail.

7. Install and start the gateway

Recommended sequence:

openclaw gateway install
openclaw gateway start
openclaw gateway status

If the gateway fails immediately, check the journal and file log before changing anything else.

8. Fix persistence for remote systemctl --user services

On remote VPS installs, a user service can disappear after the SSH session ends unless lingering is enabled.

Run:

sudo loginctl enable-linger <user>
systemctl --user daemon-reload
systemctl --user restart openclaw-gateway.service

Then verify:

loginctl show-user <user> -p Linger
systemctl --user is-active openclaw-gateway.service
openclaw gateway status

Expected: Linger=yes and the gateway stays active.

9. Verify the model path

Run a tiny local agent call and confirm the provider/model in output:

openclaw agent --local --agent main --message "Reply with exactly OK." --json

Confirm the returned metadata shows:

• provider: minimax
• model: MiniMax-M2.1

10. Verify the Telegram path

Check:

openclaw status

Look for Telegram ON and OK.

Then test outbound send:

openclaw message send --channel telegram --target <chat_id> --message "test"

If Telegram returns chat not found, the user has not started the bot DM yet, the bot token is wrong, or the chat ID is wrong.

11. Close with a precise next step

If Telegram still needs a manual first-contact step, do not vaguely say "pairing failed".

Say exactly:

• open @bot_username
• press Start
• send hi

Then re-test.