Bug Description

LINE channel's inbound message handler does not set CommandAuthorized in the context payload, causing finalizeInboundContext to coerce it to false (undefined === true → false). This silently rejects all slash commands (/new, /model, /status, etc.) on LINE while regular chat messages work fine.

Root Cause

In extensions/line/src/channel.ts, the inbound context construction (around the finalizeInboundContext call) does not include a CommandAuthorized field:

// LINE inbound context — no CommandAuthorized
const ctxPayload = finalizeInboundContext({
    Body: body,
    BodyForAgent: params.rawBody,
    RawBody: params.rawBody,
    CommandBody: params.rawBody,
    From: fromAddress,
    To: toAddress,
    // ... other fields ...
    OriginatingChannel: "line",
    OriginatingTo: originatingTo
    // ← CommandAuthorized is MISSING
});

In inbound-context-*.js line 47:

normalized.CommandAuthorized = normalized.CommandAuthorized === true;
// undefined === true → false

Then in resolveCommandAuthorization:

// When commands.allowFrom is not configured (returns null):
isAuthorizedSender = commandAuthorized && isOwnerForCommands;
// false && anything → false → all commands silently rejected

Every other channel (Telegram, Discord, Slack, iMessage, Signal) correctly sets CommandAuthorized via resolveCommandAuthorizedFromAuthorizers() or equivalent logic. LINE is the only channel missing this.

Comparison with Other Channels

Reproduction Steps

1. Configure LINE channel with a paired user (dmPolicy: "pairing")
2. Do NOT configure commands.allowFrom in config
3. Send /new or /model via LINE DM
4. Expected: Command is processed and responds
5. Actual: Command is silently ignored (no log entry, no response)
6. Send a regular message like "Hello" → works fine, gets a reply

Workaround

Add commands.allowFrom to config, which bypasses the CommandAuthorized check entirely:

"commands": {
    "allowFrom": {
        "line": ["*"]
    }
}

This works because when commands.allowFrom is configured, resolveCommandAuthorization uses a different code path that checks the sender against the allowFrom list directly, without depending on CommandAuthorized.

Suggested Fix

In the LINE inbound message handler, compute CommandAuthorized using the same resolveCommandAuthorizedFromAuthorizers() / resolveControlCommandGate() pattern used by Telegram and other channels, then include it in the context payload passed to finalizeInboundContext().

Environment

• OpenClaw v2026.2.24
• LINE Messaging API (webhook mode)
• macOS / Node.js

Related

• LINE channel crash loop: monitorLineProvider resolves immediately instead of blocking on abortSignal #26978 (LINE crash loop — different bug, same extension)