Reject callbacks when no registered token is present

The token check is currently conditional on commandTokens.size > 0, which means the callback endpoint accepts any token whenever registration yields zero commands (for example, API permission errors or partial startup failures). In that state, a direct HTTP POST to the callback path can still drive command execution with CommandAuthorized: true, so command authorization effectively falls back to unauthenticated input instead of failing closed.

Useful? React with 👍 / 👎.

Keep slash command handler state per Mattermost account

Activation stores tokens, registered command IDs, and the handler in one global singleton, so when multiple Mattermost accounts are enabled, each subsequent account startup overwrites the previous account’s slash-command state. This causes callbacks from earlier accounts to fail validation or be routed with the wrong account context, and makes native commands unreliable in multi-account deployments.

Useful? React with 👍 / 👎.

Enforce sender authorization for native slash commands

The slash-command path unconditionally marks requests as authorized (CommandAuthorized: true) and never applies the DM/group allowlist checks used in the websocket message handler. In deployments that rely on groupPolicy, allowFrom, or access-group command gating, any user who can invoke /oc_* in a channel can run privileged control commands (for example model/session changes), which is a security regression versus normal Mattermost message handling.

Useful? React with 👍 / 👎.

Resolve callback path from the same account config

The HTTP route path is derived only from top-level channels.mattermost.commands, while command registration uses account.config.commands. If an operator sets accounts.<id>.commands.callbackPath (or different per-account paths), Mattermost will post to the account-specific path but the plugin only registers the top-level/default route, so callbacks for that account fail to dispatch.

Useful? React with 👍 / 👎.

Do not schedule pre-existing commands for shutdown deletion

When a matching command already exists, it is still pushed into registered, and shutdown cleanup deletes every entry in that list. That means commands that predated this process (or are shared with another instance using the same callback URL) get removed on abort, causing unexpected command loss outside this instance's lifecycle.

Useful? React with 👍 / 👎.

Normalize callbackPath before constructing callback URL

resolveCallbackUrl concatenates callbackPath directly, but route registration normalizes missing leading slashes via plugin HTTP path normalization. If a user sets commands.callbackPath to a common value like api/channels/mattermost/command (no leading /), the command is registered with Mattermost as http://host:portapi/... while the gateway listens on /api/..., so every slash callback misses the handler.

Useful? React with 👍 / 👎.

Validate required fields for JSON slash payloads

The JSON branch in parseSlashCommandPayload returns parsed data without checking required fields, unlike the form-encoded branch. Downstream, the handler immediately uses payload.command.replace(...), so a JSON callback with a missing or non-string command causes a runtime exception and 500 instead of a clean 400 rejection; this is reproducible with malformed JSON requests that still carry a valid token.

Useful? React with 👍 / 👎.

Require a reachable callback URL before registering commands

When commands.callbackUrl is unset, resolveCallbackUrl falls back to http://localhost:<port>...; in typical deployments where Mattermost is on a different host, that URL is unreachable from the Mattermost server, so slash commands register successfully but invocations never reach this gateway. This makes the feature appear enabled while being non-functional unless users discover and set an override manually.

Useful? React with 👍 / 👎.

Honor nativeSkills when choosing Mattermost commands

The config schema and resolver accept commands.nativeSkills, but registration always passes DEFAULT_COMMAND_SPECS, so enabling nativeSkills has no effect and skill commands are never registered. This creates a silent config mismatch where operators believe a feature is enabled but the command surface does not change.

Useful? React with 👍 / 👎.

Reconcile existing slash commands when callback URL changes

Existing commands are indexed only when their stored url exactly matches the current callbackUrl, so previously created /oc_* commands with an older callback URL are ignored instead of being updated or replaced. During callback URL migrations this leaves stale commands in Mattermost and breaks seamless cutover to the new endpoint.

Useful? React with 👍 / 👎.

Normalize slash allowlists like websocket monitor

This normalization only lowercases raw entries, so slash-command auth no longer matches common allowlist formats that the regular Mattermost monitor accepts (for example "*", "@username", and "mattermost:<id>"). In configs that rely on those forms, authorized users are treated as unauthorized for native slash commands, which blocks command execution despite existing working allowlist/pairing settings.

Useful? React with 👍 / 👎.

Register callback route from explicit callbackUrl path

Route registration is derived only from callbackPath, so when an operator sets commands.callbackUrl with a non-default pathname but leaves callbackPath unset, commands are created to post to that URL while the gateway still listens on the default path. In that configuration (without a proxy rewrite), Mattermost callbacks hit an unregistered endpoint and native slash commands fail at runtime.

Useful? React with 👍 / 👎.

Resolve skill commands without repo-relative imports

When channels.mattermost.commands.nativeSkills is enabled, this code imports ../../../../src/auto-reply/skill-commands.js, which only exists in a source checkout. Plugin installs are copied into a standalone extensions directory and only install package dependencies (npm install --omit=dev in src/plugins/install.ts), so this relative path is missing in normal npm-installed plugins. The import error is swallowed by the catch, causing native skill slash commands to be silently skipped in production installs.

Useful? React with 👍 / 👎.

Preserve oc_ skill names when reconstructing command text

This unconditionally strips the oc_ prefix from incoming triggers, but registration keeps skill names that already start with oc_ unchanged (trigger = name.startsWith("oc_") ? name : ...). A skill command named oc_report is therefore registered as /oc_report yet reconstructed as /report, so invocation no longer matches the configured skill command when native skill commands are enabled.

Useful? React with 👍 / 👎.

Deactivate slash state before awaiting command cleanup

This ties deactivateSlashCommands(account.accountId) to the success path of an async network cleanup, which creates a race during reloads: the old monitor can start cleanupSlashCommands, a new monitor can already call activateSlashCommands for the same account, and then this delayed .then(...) clears the freshly activated handler/tokens from the shared slash state map, causing valid callbacks to start failing with 401/503 until another restart; if cleanup throws, deactivation never happens at all, leaving stale state active.

Useful? React with 👍 / 👎.

Exempt Mattermost slash callback from gateway bearer auth

createGatewayHttpServer now enforces authorizeGatewayConnect for plugin routes under /api/channels/*, but this commit's Mattermost native slash default callback path is /api/channels/mattermost/command (extensions/mattermost/src/mattermost/slash-commands.ts). Mattermost slash callbacks send their command token in the POST payload (not an Authorization bearer token), so requests are rejected with 401 before the plugin slash handler can run, which makes the default native-command configuration non-functional unless users manually move the callback path.

Useful? React with 👍 / 👎.

Don't reject localhost callback URLs via host heuristic

This guard assumes any non-loopback baseUrl means Mattermost runs on a different machine, so it throws when callbackUrl resolves to localhost. That breaks valid co-located deployments where Mattermost is accessed via a public domain but the server process can still reach http://localhost:<port> on the same host; in that setup slash command registration is skipped entirely and native commands never work. The check should avoid hard-failing on this hostname comparison (or make it advisory) because network reachability cannot be inferred from URL hostnames alone.

Useful? React with 👍 / 👎.

Honor commands.allowFrom override for unmatched providers

When commands.allowFrom is present but neither a provider-specific key nor "*" exists, this path returns null and the caller falls back to channel allowlists. That re-enables command access on providers the operator did not include in commands.allowFrom, which contradicts the new “override” semantics and can unintentionally authorize commands. In this case the resolver should return an empty list (deny) rather than “not configured”.

Useful? React with 👍 / 👎.

Bracket IPv6 hosts when deriving Mattermost callback URL

The fallback callback URL is built by raw string interpolation, so an IPv6 gatewayHost (for example ::1 or a tailnet IPv6) produces an invalid URL like http://::1:3015/.... That breaks slash-command registration/callbacks for IPv6 deployments unless users set callbackUrl manually.

Useful? React with 👍 / 👎.

Use runtime gateway port for slash callback URL

Build the Mattermost slash callback from the actual gateway listener settings instead of cfg.gateway?.port: this code registers commands against the config port, but openclaw gateway run --port <port> starts the server on an override port without rewriting config. In that common setup, Mattermost posts to the wrong callback URL and every slash command invocation fails with connection errors even though registration appears successful.

Useful? React with 👍 / 👎.

Exempt all configured slash callback paths from gateway auth

The auth bypass is hardcoded to only "/api/channels/mattermost/command", but this same commit introduces configurable Mattermost callback routing (commands.callbackPath and callbackUrl pathname registration). If an operator sets a different callback path under /api/channels/..., this branch still applies bearer auth (requestPath.startsWith("/api/channels/")), and Mattermost cannot supply that gateway token, so slash invocations will consistently 401 and native commands never execute for that config. The bypass needs to use the registered callback paths rather than one fixed literal.

Useful? React with 👍 / 👎.

Preserve global slash settings when reading account commands

monitorMattermostProvider resolves slash behavior only from account.config.commands, but account configs are shallow-merged ({ ...base, ...account } in mergeMattermostAccountConfig), so any per-account commands object replaces the global one entirely. In practice, if operators set channels.mattermost.commands.native: true globally and only override callbackPath/callbackUrl per account, resolveSlashCommandConfig sees native as "auto" and disables native commands for that account, so registration silently never happens.

Useful? React with 👍 / 👎.

Avoid classifying unknown channels as group/channel in slash auth

When channel lookup fails, channelInfo is left null and the fallback classification defaults to "channel"; this means DM slash invocations can be evaluated under group/channel policy (often denied under default allowlist settings) during transient Mattermost API failures. A valid DM command payload should not be rejected just because /channels/{id} was temporarily unavailable.

Useful? React with 👍 / 👎.

Treat unknown slash channel kind as channel

When channel lookup fails (for example due to a transient API/network error), this branch classifies the slash invocation as direct instead of a non-DM type. That makes authorization follow dmPolicy rather than group/channel policy, so commands from channels can be incorrectly accepted even when channel commands are disabled or restricted by allowlists. Defaulting unknown channels to channel avoids this policy bypass.

Useful? React with 👍 / 👎.