hoary oasis
連携を行いたいが、405エラーが継続的に発生しています。
▼エラー文
エラー
ボットサーバーから200以外のHTTPステータスコードが返されました。(405 Method Not Allowed)
LINEプラットフォームから送信されたHTTP POSTリクエストに対してボットサーバーがステータスコード200を返すことを確認してください。詳しくは、Messaging APIリファレンスのレスポンスを参照してください。
fervent latchBOT
radiant briarBOT
405 (Method Not Allowed) は、LINE から来ている HTTP POST を、その URL 側が「POST 受け付けないよ」って返してる状態です。
なので原因の切り分けはほぼ「Webhook URL が違う場所に刺さってる / プロキシが別のハンドラに当ててる」になります。
OpenClaw の LINE プラグインを使っている前提だと、Webhook はここです：
https://<gateway-host>/line/webhookchannels.line.webhookPath の値に合わせる）公式ドキュメント: https://docs.openclaw.ai/channels/line
Gateway は LINE の検証 (GET) とイベント (POST) の両方を返す想定です。なので /line/webhook に当たっていれば 405 にはなりにくいです。
/line/webhook まで入ってるかhttps://xxxx/ や https://xxxx/dashboard になってると、POST が 405 になりがちです。openclaw plugins list に @openclaw/line が居るかchannels.line.enabled: true があるか外部から叩ける場所で（もしくは自分のスマホ回線などで）これを試して、結果を教えてください：
curl -i -X POST https://<あなたのWebhookURL>
差し支えない範囲でOK・トークン類は貼らないでください：
openclaw --versionopenclaw plugins list の該当部分openclaw logs --follow を流しながら LINE 側の「検証」押した時に出るログ（数行）その情報で「どこに当たって 405 返してるか」一緒に潰せます。
hoary oasis
$ openclaw plugins list
LINE | line | loaded | stock:line/index.ts | 2026.3.1
ステータス: loaded （正常にロード済み）
$ curl -i -X POST https://macbook-pro-1.tail98d070.ts.net/line/webhook
HTTP/2 405
content-type: text/plain; charset=utf-8
date: Tue, 03 Mar 2026 05:39:02 GMT
referrer-policy: no-referrer
x-content-type-options: nosniff
content-length: 18
Method Not Allowed
$ openclaw logs --follow
→ LINEからのWebhookリクエストは一切記録されず
→ Gateway側には何も到達していない
$ curl -X POST http://127.0.0.1:18789/line/webhook
HTTP/1.1 405 Method Not Allowed
Content-Type: text/plain; charset=utf-8
Method Not Allowed
重要: ローカルでも405エラー
$ curl -X GET http://127.0.0.1:18789/line/webhook
HTTP/1.1 200 OK
（HTMLが返る）
発見: GETは成功、POSTのみ失敗
$ tailscale funnel status
https://macbook-pro-1.tail98d070.ts.net (Funnel on)
|-- / proxy http://127.0.0.1:18789
→ POSTリクエストがGatewayに到達していない
→ 405エラーはGatewayではなく、その手前で返されている
OpenClaw の LINE プラグインが /line/webhook エンドポイントに対してPOSTメソッドを正しく登録していない
または
Tailscale Funnel（起動方法によってはPOSTブロックの可能性も？）
{
"channels": {
"line": {
"enabled": true,
"channelAccessToken": "（設定済み）",
"channelSecret": "（設定済み）",
"dmPolicy": "pairing",
"mode": "webhook",
"webhookPath": "/line/webhook"
}
},
"plugins": {
"entries": {
"line": {
"enabled": true
}
}
}
}
radiant briarBOT
状況かなりハッキリしてて、結論から言うと **「/line/webhook が LINE プラグインの webhook ハンドラに刺さってない」**です。
根拠はこれです：
http://127.0.0.1:18789/line/webhook への POST が 405この挙動は「LINE の webhook ではなく、Gateway の “静的UI/フォールバック” に当たっている」時の典型です。
（OpenClaw 側の LINE webhook 実装は POST を受けて 200/400/401 を返す作りで、405 を返すルートではないです）
さらに重要ポイント：あなたの curl -X POST ... はボディ無しなので、仮に正しいLINEハンドラに当たっていれば 405ではなく 400/200 になります（検証リクエスト相当なら {"events":[]} を投げると 200 が返ります）。
openclaw channels status
ここで line が running になってるか、また configured 扱いになってるかを見たいです（スクショでもOK、トークンは伏せてください）。
plugins listが loaded でも、channels.lineが未設定/無効/secret欠落だと、Webhookルート自体が登録されません。
channels.line が本当に有効か確認（値は貼らなくてOK。enabled が true かどうかだけでも）
openclaw config get channels.line
最低限こういう形が必要です（値はダミー）:
{
channels: {
line: {
enabled: true,
channelAccessToken: "…",
channelSecret: "…",
}
}
}
これで 405 が続くなら、100% ルート未登録です。
curl -i \
-X POST "http://127.0.0.1:18789/line/webhook" \
-H "content-type: application/json" \
--data '{"events":[]}'
期待値（ルートが登録されていれば）:
{"status":"ok"}channels.line.enabled が true になってないopenclaw gateway status で Config (cli) / Config (service) がズレてないか確認したいです（FAQにもあるやつ）openclaw channels status の line 部分と、上の curl (events:[]) の結果を貼ってくれれば、次の指示はかなりピンポイントに出せます。
結論の「LINEプラグインがPOSTを登録してない」はたぶん違っていて、今出てる 405 は OpenClaw の Control UI(ダッシュボード) が返してる 405 です。
根拠：OpenClaw 側で /line/webhook が正しくマウントされている場合、
/line/webhook → 200 OK で本文は OK (text/plain)/line/webhook（署名なし・検証用 {"events":[]}）→ 200 で {"status":"ok"}という実装になってます（Control UI の挙動は “GET/HEAD 以外は 405” ＋ “GET は SPA の HTML を返す” なので、いまの 「GETはHTML / POSTは405」 にピッタリ一致します）。
つまり、/line/webhook が plugin ルートとして登録されていない状態です（POSTが届いてないのではなく、Gateway内で別ハンドラに拾われてる）。
channels.line が設定されてても、Gatewayがその設定を読んでない（= config不一致）とルートは生えません。
openclaw channels list
openclaw channels status
openclaw gateway status
見たいポイント：
channels list/status に line が出ているかchannels status で line の configured/running/lastError がどうなっているかgateway status の Config (cli) と Config (service) がズレてないか（ズレてると “編集した設定” がサービス側に反映されてません）これが 200にならないなら、/line/webhook がマウントされてません。
curl -i \
-X POST "http://127.0.0.1:18789/line/webhook" \
-H "content-type: application/json" \
--data '{"events":[]}'
期待：HTTP/1.1 200 + {"status":"ok"}
gateway status で判明するやつ）channels.line.channelAccessToken が実は空/読み込めてないので、LINEアカウントが “存在しない扱い” になって起動されてないopenclaw channels list/status と openclaw gateway status の該当部分（トークン伏せてOK）を貼ってくれれば、「config不一致」なのか「lineが未起動で lastError が出てる」のか、その場で特定できます。
hoary oasis
───
LINE Webhook 405エラー - 調査レポート（コミュニティ報告用）
環境情報
• OpenClaw バージョン: 2026.3.1
• OS: macOS (Darwin)
• プラグイン: LINE plugin loaded (stock:line/index.ts)
• Gateway: LaunchAgent (ローカルモード)
───
症状
LINEのWebhook URLに対してPOSTリクエストを送信すると、405 Method Not Allowed エラーが返る。
───
診断結果
Warnings:
⚠️ line default: LINE channel access token not configured
⚠️ line default: LINE channel secret not configured
矛盾: ステータスは configured なのに、警告で not configured と表示されている
───
{
"enabled": true,
"channelAccessToken": "（172文字の有効な値が存在）",
"channelSecret": "（32文字の有効な値が存在）",
"dmPolicy": "pairing",
"mode": "webhook",
"webhookPath": "/line/webhook"
}
確認済み: 設定ファイルには token と secret が確実に存在しています
───
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json
結果: Config不一致なし（CLIとサービスで同じ設定ファイル使用）
───
channels status では not configured と警告される───
curl -i -X POST "http://127.0.0.1:18789/line/webhook"
-H "content-type: application/json"
--data '{"events":[]}'
結果:
HTTP/1.1 405 Method Not Allowed
Content-Type: text/plain; charset=utf-8
Method Not Allowed
期待値: HTTP 200 OK + {"status":"ok"}
結論: /line/webhook がLINEハンドラにマウントされていない（Control UIのフォールバックに当たっている）
───
curl -X GET "http://127.0.0.1:18789/line/webhook"
→ HTTP/1.1 200 OK (HTMLが返る)
curl -X POST "http://127.0.0.1:18789/line/webhook"
→ HTTP/1.1 405 Method Not Allowed
コミュニティからの指摘通り: この挙動は「Control UIのSPA」に当たっている証拠
───
問題の核心
矛盾点のまとめ
• POST → 405（LINEハンドラではなくControl UIに当たる）
• 検証POST {"events":[]} も 405
───
試したこと
• ✅ mode: "webhook" 設定追加
• ✅ webhookPath: "/line/webhook" 明示的設定
• ✅ Gateway 再起動（SIGUSR1）
• ✅ Gateway 完全再起動（stop + start）
• ✅ Tailscale Funnel 設定確認（問題なし）
• ✅ Config不一致確認（問題なし）
───
推定される原因
Gatewayが設定ファイルから channelAccessToken と channelSecret を正しく読み込めていない可能性があります。
設定ファイルには値が存在するにもかかわらず、Runtime時に「not configured」と判定され、LINEチャンネルのWebhookハンドラが登録されない状態です。
───
質問
1. *channels status が「not configured」警告を出す条件*は何でしょうか？
2. 設定ファイルに値があるのにGatewayが認識しない場合、*どこを確認すべき*でしょうか？
3. この状況は *OpenClawのバグ*の可能性がありますか？
───
補足情報
• プラグインのロードは成功（`openclaw plugins list` で loaded 確認済み）
• Gatewayは正常動作中（Slack チャンネルは問題なく動作）
• ログに「LINE channel access token not configured」以外のエラーなし
よろしくお願いいたします。いま出てる HTTP/1.1 405 + text/plain; charset=utf-8（GETだとHTML）は、LINEハンドラではなく Control UI（ダッシュボード）が返してる 405 です。
なので「/line/webhook が未マウント」というより、UI がそのパスの POST を先に握って弾いてる系の症状に見えます。
加えて、openclaw channels status の
⚠️ LINE channel access token not configured / secret not configured
でも configured と表示される
これは LINEプラグイン側の collectStatusIssues が “スナップショットに含まれない field（channelAccessToken / channelSecret）” を見に行ってしまう実装なので、常に誤警告になりがちです。
（＝その警告自体は今回の根本原因とは別）
Control UI をルート / ではなく、別prefixに寄せてください。
~/.openclaw/openclaw.json に例えばこれを追加/変更：
{
gateway: {
controlUi: {
enabled: true,
basePath: "/openclaw",
},
},
}
その後：
openclaw gateway restart
http://127.0.0.1:18789/openclaw/ で開けるhttp://127.0.0.1:18789/line/webhook を使えるそして検証POST：
curl -i \
-X POST "http://127.0.0.1:18789/line/webhook" \
-H "content-type: application/json" \
--data '{"events":[]}'
これが 200 + {"status":"ok"} になれば勝ちです（LINE Developers の Verify と同じ想定）。
その場合は「UIが先に握ってる」以外の経路になるので、次にこれだけ見たいです：
openclaw channels status --json
出力のうち channelAccounts.line の running / lastError / lastStartAt / lastStopAt あたり（トークンは不要）を貼ってください。
LINEチャンネルが起動→即死ループしてて webhook route が生えない、みたいなパターンも潰せます。
（再現が固いので、必要ならこの件は GitHub issue に上げるのが良さそうです。こちらからは作れないので、作る場合はこのスレのレポートをそのまま貼るのが一番早いです。）
状況整理ありがとう。これはかなり **「LINEの設定ミス」ではなく、Gateway 側の HTTP ルーティング（Control UI と webhook の取り合い）**っぽいです。
channels status が「not configured」警告を出す条件は？結論：いまの LINE プラグインの channels status 警告は誤警告になり得ます（というか構造上ほぼ常に出ます）。
理由は実装上、channels status が表示する “アカウントスナップショット” に channelAccessToken / channelSecret を載せないのに、警告生成側がそれを見に行って undefined → 未設定扱い にしてしまうためです。
なので、
channels list では token:config と出るchannels status の Warnings では “token/secret not configured” が出るという 見かけの矛盾が起きます。
ここは「警告が出てる＝設定が読めてない」とは限りません。
今回の本丸はここで、あなたの
/line/webhook → HTML/line/webhook → 405 text/plainは、ほぼ確実に Control UI（SPA）がそのパスを握っている挙動です。
Control UI をルート / で配信しないように、basePath を必ず設定してください。
~/.openclaw/openclaw.json に：
{
gateway: {
controlUi: {
enabled: true,
basePath: "/openclaw"
}
}
}
そして再起動：
openclaw gateway restart
http://127.0.0.1:18789/openclaw/ で開けるcurl -i http://127.0.0.1:18789/line/webhook の GET が HTML ではなく（本来は OK みたいな素朴なレスポンス）検証POST（あなたのやり方でOK）：
curl -i \
-X POST "http://127.0.0.1:18789/line/webhook" \
-H "content-type: application/json" \
--data '{"events":[]}'
これが 200 + {"status":"ok"} になれば、LINE Developers の Verify も通るはずです。
誤警告に惑わされず、probe で実際に LINE API を叩かせるのが一番確実です：
openclaw channels status --probe
ここで LINE bot probe が works 側になるなら、token/secret は実際に使えています。
あります。少なくとも2点：
channels status の token/secret 未設定警告が誤警告になり得る（表示ロジック側の問題）なので、gateway.controlUi.basePath を設定しても直らない場合は、かなりバグ線が濃いです。
その場合は GitHub issue にすると良さそうで、その時は今まとめてくれたレポート（再現手順・curl結果・openclaw --version・openclaw channels status --json）がほぼそのまま武器になります。
まずは gateway.controlUi.basePath: "/openclaw" 設定 → restart → もう一回 curl の結果を教えてください。ここで挙動がガラッと変わるはずです。
hoary oasis
LINE Webhook URL (/line/webhook) に対する POST リクエストのみが 405 Method Not Allowed を返します。
GET リクエストは正常に LINE プラグインに到達しています。
~/.openclaw/openclaw.json:json
{
"gateway": {
"controlUi": {
"enabled": true,
"basePath": "/openclaw"
}
}
}
結果: Control UI は /openclaw/ に正常に移動しました。
$ curl -i http://127.0.0.1:18789/line/webhook
HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
{"error":{"message":"Unauthorized","type":"unauthorized"}}
→ LINE プラグインに到達している（JSON レスポンス）
$ curl -i -X POST "http://127.0.0.1:18789/line/webhook"
-H "content-type: application/json"
--data '{"events":[]}'
HTTP/1.1 405 Method Not Allowed
Content-Type: text/plain; charset=utf-8
Method Not Allowed
→ LINE プラグインに到達していない（text/plain レスポンス）
bash
$ openclaw channels status --probe
Warnings:
注: 警告は誤警告であることをコミュニティから確認済み。実際には token/secret は正しく設定されており、probe で works が返っています。
{
"line": {
"configured": true,
"running": true,
"lastStartAt": 1772523760437,
"lastStopAt": null,
"lastError": null,
"tokenSource": "config",
"mode": "webhook"
}
}
コミュニティからの指示によると、以下のレスポンスが期待されます：
bash
$ curl -i -X POST "http://127.0.0.1:18789/line/webhook"
-H "content-type: application/json"
--data '{"events":[]}'
HTTP/1.1 200 OK
Content-Type: application/json
{"status":"ok"}
$ curl -i http://127.0.0.1:18789/openclaw/
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
（HTML が返る）
→ Control UI は正しく /openclaw/ に移動しています。
$ curl -i http://127.0.0.1:18789/non-existent-path
HTTP/1.1 404 Not Found
Content-Type: text/plain; charset=utf-8
Not Found
json
{
"channels": {
"line": {
"enabled": true,
"channelAccessToken": "（172文字、設定済み）",
"channelSecret": "（32文字、設定済み）",
"dmPolicy": "pairing"
}
},
"gateway": {
"port": 18789,
"mode": "local",
"bind": "loopback",
"controlUi": {
"enabled": true,
"basePath": "/openclaw"
}
},
"plugins": {
"entries": {
"line": {
"enabled": true
}
}
}
}
───
LINE Webhook POST 405 エラー - 調査レポート（コミュニティ報告用）
環境情報
• OpenClaw バージョン: 2026.3.1
• OS: macOS (Darwin)
• Gateway モード: local (loopback bind)
• LINE プラグイン: loaded (stock:line/index.ts v2026.3.1)
───
問題の概要
LINE Webhook URL (/line/webhook) に対する POST リクエストのみが 405 Method Not Allowed を返します。
GET リクエストは正常に LINE プラグインに到達しています。
───
実施した対策
~/.openclaw/openclaw.json:
{
"gateway": {
"controlUi": {
"enabled": true,
"basePath": "/openclaw"
}
}
}
結果: Control UI は /openclaw/ に正常に移動しました。
───
現在の挙動
GET リクエスト（正常）
$ curl -i http://127.0.0.1:18789/line/webhook
HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
{"error":{"message":"Unauthorized","type":"unauthorized"}}
→ LINE プラグインに到達している（JSON レスポンス）
POST リクエスト（異常）
$ curl -i -X POST "http://127.0.0.1:18789/line/webhook"
-H "content-type: application/json"
--data '{"events":[]}'
HTTP/1.1 405 Method Not Allowed
Content-Type: text/plain; charset=utf-8
Method Not Allowed
→ LINE プラグインに到達していない（text/plain レスポンス）
───
channels status 詳細
$ openclaw channels status --probe
Warnings:
probe で works が返っています。channels status --json（抜粋）
{
"line": {
"configured": true,
"running": true,
"lastStartAt": 1772523760437,
"lastStopAt": null,
"lastError": null,
"tokenSource": "config",
"mode": "webhook"
}
}
───
期待される挙動
コミュニティからの指示によると、以下のレスポンスが期待されます：
$ curl -i -X POST "http://127.0.0.1:18789/line/webhook"
-H "content-type: application/json"
--data '{"events":[]}'
HTTP/1.1 200 OK
Content-Type: application/json
{"status":"ok"}
───
その他の確認事項
Control UI の動作確認
$ curl -i http://127.0.0.1:18789/openclaw/
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
（HTML が返る）
→ Control UI は正しく /openclaw/ に移動しています。
存在しないパスの動作
$ curl -i http://127.0.0.1:18789/non-existent-path
HTTP/1.1 404 Not Found
Content-Type: text/plain; charset=utf-8
Not Found
───
設定ファイル（関連部分のみ）
{
"channels": {
"line": {
"enabled": true,
"channelAccessToken": "（172文字、設定済み）",
"channelSecret": "（32文字、設定済み）",
"dmPolicy": "pairing"
}
},
"gateway": {
"port": 18789,
"mode": "local",
"bind": "loopback",
"controlUi": {
"enabled": true,
"basePath": "/openclaw"
}
},
"plugins": {
"entries": {
"line": {
"enabled": true
}
}
}
}
───
試したこと
• ✅ gateway.controlUi.basePath: "/openclaw" 設定
• ✅ Gateway 再起動（SIGUSR1）
• ✅ Gateway 完全再起動（stop + start）
• ✅ mode: "webhook" 明示的設定
• ✅ webhookPath: "/line/webhook" 明示的設定（後に削除）
• ✅ openclaw channels status --probe で疎通確認
───
質問
───
補足情報
• Slack チャンネルは正常に動作中
• Gateway のログに POST リクエストの痕跡が記録されていない（HTTPレイヤーのログが出ていない）
• LINE Developers での「検証」ボタンも同様に失敗（当然ながら405）
よろしくお願いいたします。
radiant briarBOT
かなり核心まで来てます。今のログ/レスポンスを見る限り、ポイントはこの2つです。
POST /line/webhook の 405 は、まだ Control UI の 405 ですあなたの POST の返り値が
405 Method Not AllowedContent-Type: text/plainなのは、OpenClaw の Control UI ハンドラが「POST を全部 405 にする」挙動に一致します（※パス判定より先に method 判定して 405 を返してしまう実装）。
なので gateway.controlUi.basePath を /openclaw にしても、/line/webhook が他で処理されなかった場合は、最後に Control UI が拾って POST は 405 になります。
（今回 basePath 設定で “GET でHTMLが返る” 問題が消えたのは大きいですが、POST 405 そのものはまだマスクとして残ります）
curl -i のヘッダで Allow: を確認してください。
Allow: GET, POST が付きがち & application/json が返るAllow が無いことが多い & text/plain（あなたの結果は後者に見えます）
GET /line/webhook が 401 なのは「LINEに到達してる」ではないですLINE側の実装だと GET /line/webhook は本来 200 OK + OK (text/plain) になります。
なので 401 Unauthorized (application/json) は LINEハンドラではなく、別の“認可が必要な何か”に落ちている状態です。
channels status が「not configured」警告を出す条件これはほぼ **LINEプラグイン側の表示バグ（誤警告）**です。
channels status の Warnings は、各プラグインの collectStatusIssues() が “スナップショットに含まれてない token/secret” を見に行って未設定扱いにしてしまう構造になっていて、--probe が works でも警告だけ出る、が起きます。
なので 今回の 405 の直接原因ではないです（probe が works なのが証拠）。
今回見るべきは **「token/secret を認識したか」より「webhook route が登録されたか」**です。
おすすめはこれ：
logging.level を一時的に上げて、Gateway再起動 → openclaw logs --follow で起動直後のログを見てください。
探したいログ（だいたいこんな文言）：
line: registered webhook handler at /line/webhookこれが 出ていないなら、LINEチャンネル側が route 登録まで到達してません（起動途中で落ちてる等）。
Control UI があると POST が 405 にマスクされるので、切り分けにめちゃ有効です。
一時的に：
{
gateway: {
controlUi: { enabled: false }
}
}
→ openclaw gateway restart
その後もう一回：
curl -i -X POST "http://127.0.0.1:18789/line/webhook" \
-H "content-type: application/json" \
--data '{"events":[]}'
{"status":"ok"} → LINE webhook 自体は生きてる（= Control UI の 405 マスクが原因）この結果で次の打ち手が確定します。
高いです。少なくとも：
channels status の token/secret 警告が誤警告になり得る点この2つはバグ寄りです。
curl -i の POST 405 のレスポンスヘッダ全文（Allow: があるか見たい。token類は不要）POST {"events":[]} の ステータスコードlogging.level=debug にした上で Gateway 再起動直後のログに line: registered webhook handler... が出るかここまで揃えば、「UIの405マスク問題」なのか「route未登録」なのか「認可境界の回帰」なのか確定できます。
レポートめちゃくちゃ助かります。ここまで情報が揃ってると、かなりはっきり言えます。
OpenClaw の LINE webhook ハンドラの仕様だと、本来はこうです：
GET /line/webhook → 200 text/plain で OKPOST /line/webhook（署名なし {"events":[]}）→ 200 application/json で {"status":"ok"}なので、
は、どちらも LINEハンドラの挙動ではありません。
これはほぼ確定で Control UI の既知の挙動/バグです。
実装上、Control UI の HTTP ハンドラが「パスを確認する前に POST/PUT/... を全部 405 で返す」ため、controlUi.enabled: true だと どんなパスでも（basePath外でも）「他で処理されなかったPOST」は最後に 405 になります。
確認用にこれを叩くと分かりやすいです：
curl -i -X POST http://127.0.0.1:18789/non-existent-path
これも 405 になるなら、あなたの /line/webhook の 405 は LINEではなく Control UI 起因で確定です。
channels status --probe が works なので、token/secret 自体は実際に使えてます（少なくとも bot probe は成功している）。
いま確認すべきは **「webhook route が登録されているか」**です。これが一番確実。
Control UI が ON だと POST が 405 にマスクされて切り分けが地獄なので、短時間だけ OFF にしてテストするのが最短です。
{
gateway: { controlUi: { enabled: false } }
}
→ openclaw gateway restart
その後：
curl -i -X POST "http://127.0.0.1:18789/line/webhook" \
-H "content-type: application/json" \
--data '{"events":[]}'
期待値：
logging.level=debug で route 登録ログを見るlogVerbose() は file log level が debug 以上だと記録されます。LINE側は起動時に
line: registered webhook handler at /line/webhookを出すので、これが出るかで「登録された/されてない」が分かります。
~/.openclaw/openclaw.json に一時的に：
{ logging: { level: "debug" } }
→ openclaw gateway restart
→ openclaw logs --follow で起動直後を確認
channels status の “not configured” 警告は何条件で出る？これは今回の状況だと LINEプラグインの誤警告の可能性が高いです。
理由：channels status の warnings はプラグインが “スナップショット” だけ見て判定しますが、そこに token/secret の生値は載らないため、「undefined → 未設定」と誤判定しやすい構造です。
--probe が works なのが、実態としては設定OKの証拠です。
少なくとも：
なので、上の「Control UI 一時OFFでの POST 結果」と「debugログの route 登録ログ」が揃ったら、GitHub issue に出す価値があります。
Issue に貼ると強い材料：
openclaw --versionopenclaw channels status --json（LINE部分）logging.level=debug での起動ログ（line: registered webhook handler ... が出る/出ない）curl -i -X POST /line/webhook の結果GitHub issues: https://github.com/openclaw/openclaw/issues
次の一手としては、「Control UI を一時的に OFF にした状態での POST {"events":[]} の結果」が一番知りたいです。これで原因がほぼ1発で確定します。
hoary oasis
LINE Webhook POST 405 エラー - 最終調査レポート（コミュニティ報告用）
環境情報
• OpenClaw バージョン: 2026.3.1
• OS: macOS (Darwin)
• Gateway モード: local (loopback bind)
• LINE プラグイン: loaded (stock:line/index.ts v2026.3.1)
───
問題の概要
LINE Webhook URL (/line/webhook) に対する POST リクエストのみが 405 Method Not Allowed を返します。
───
実施した対策と調査
~/.openclaw/openclaw.json:
{
"gateway": {
"controlUi": {
"enabled": true,
"basePath": "/openclaw"
}
}
}
結果: Control UI は /openclaw/ に正常に移動しましたが、POST 405 は継続。
───
テスト A: POST 405 の Allow: ヘッダー確認
$ curl -i -X POST "http://127.0.0.1:18789/line/webhook"
-H "content-type: application/json"
--data '{"events":[]}'
HTTP/1.1 405 Method Not Allowed
Content-Type: text/plain; charset=utf-8
（Allow: ヘッダーなし）
Method Not Allowed
分析: Allow: ヘッダーがなく、text/plain であることから、Control UI 由来の 405 と判明。
───
テスト B: Control UI を完全に無効化してテスト
{
"gateway": {
"controlUi": {
"enabled": false
}
}
}
結果:
$ curl -i -X POST "http://127.0.0.1:18789/line/webhook"
-H "content-type: application/json" --data '{"events":[]}'
HTTP/1.1 405 Method Not Allowed ← まだ 405
$ curl -i http://127.0.0.1:18789/line/webhook
HTTP/1.1 401 Unauthorized
Content-Type: application/json
{"error":{"message":"Unauthorized","type":"unauthorized"}}
重要な発見: Control UI を無効化しても 405 が継続。これは Control UI の問題ではなく、LINE Webhook の route 自体が登録されていないことを示しています。
───
テスト C: logging.level=debug で route 登録ログ確認
{
"logging": {
"level": "debug"
}
}
Gateway 再起動後、起動ログを確認：
結果: line: registered webhook handler at /line/webhook のようなログが一切存在しない
比較として、Slack などの他のチャンネルは正常にログが出力されていますが、LINE 関連の route 登録ログは皆無でした。
───
現在の挙動まとめ
GET リクエスト
$ curl -i http://127.0.0.1:18789/line/webhook
HTTP/1.1 401 Unauthorized
Content-Type: application/json
{"error":{"message":"Unauthorized","type":"unauthorized"}}
→ LINE プラグインではなく、別の認可層に落ちている
（コミュニティによると、LINE ハンドラなら 200 OK + OK (text/plain) が正しい）
POST リクエスト
$ curl -i -X POST "http://127.0.0.1:18789/line/webhook"
-H "content-type: application/json" --data '{"events":[]}'
HTTP/1.1 405 Method Not Allowed
Content-Type: text/plain; charset=utf-8
Method Not Allowed
→ LINE ハンドラに到達していない（route 未登録）
───
channels status 詳細
$ openclaw channels status --probe
Warnings:
• works = LINE API への疎通は成功（token/secret は正しい）
• 警告は誤警告（コミュニティから確認済み）
• しかし HTTP route は登録されていない
channels status --json（抜粋）
{
"line": {
"configured": true,
"running": true,
"lastStartAt": 1772523760437,
"lastStopAt": null,
"lastError": null,
"tokenSource": "config",
"mode": "webhook"
}
}
───
設定ファイル（関連部分のみ）
{
"channels": {
"line": {
"enabled": true,
"channelAccessToken": "（172文字、設定済み）",
"channelSecret": "（32文字、設定済み）",
"dmPolicy": "pairing"
}
},
"gateway": {
"port": 18789,
"mode": "local",
"bind": "loopback",
"controlUi": {
"enabled": false,
"basePath": "/openclaw"
}
},
"plugins": {
"entries": {
"line": {
"enabled": true
}
}
}
}
───
試したこと
• ✅ gateway.controlUi.basePath: "/openclaw" 設定
• ✅ gateway.controlUi.enabled: false 設定
• ✅ Gateway 再起動（SIGUSR1）
• ✅ Gateway 完全再起動（stop + start）
• ✅ mode: "webhook" 明示的設定
• ✅ webhookPath: "/line/webhook" 明示的設定（後に削除）
• ✅ logging.level: "debug" で詳細ログ確認
• ✅ openclaw channels status --probe で疎通確認
───
最終結論
問題の核心
OpenClaw の LINE プラグインが、Webhook Handler の HTTP route を Gateway に登録していない
証拠
推定される原因
[17:04]• LINE プラグインが webhook モードで起動する際の route 登録処理に不具合がある
• または特定の条件下（例: bind: "loopback", mode: "local" 等）で route 登録がスキップされている
• プラグインは loaded でチャンネルは running だが、HTTP ハンドラの登録フェーズが実行されていない
───
質問
───
補足情報
• Slack チャンネルは正常に動作中（socket モード）
• Gateway は正常稼働中
• Tailscale Funnel 経由でも同じ結果
• macOS 環境、ローカルモード、loopback bind
───
radiant briarBOT
ここまで切り分けできてるの、かなり強いです。結論から言うと 「LINEのWebhookが405」ではなく、GatewayのHTTPルーティング側で /line/webhook の POST が LINE ハンドラに届いてない状況です。
その上で、今回のログの解釈で1点だけ重要な訂正があります：
GET /line/webhook -> 401 Unauthorized (JSON) は LINEプラグインの挙動ではないですGET は通常 200 OK + OK(text/plain) になります。POST /line/webhook -> 405 (text/plain, Allowなし) も LINEハンドラの挙動ではないですAllow: GET, POST が付いて JSON が返ります。つまり GETもPOSTも、別のHTTPハンドラに吸われています。
gateway.controlUi.enabled=false を入れて再起動したあとに、これを試してください：
curl -i -X POST http://127.0.0.1:18789/non-existent-path
期待値：
もしここが 405 になるなら、controlUi.enabled=false が実際のGatewayに反映されていません（＝POSTが全部405にマスクされ続けます）。
curl -i http://127.0.0.1:18789/openclaw/
期待値（control ui disabledなら）：
logVerbose() はファイルに debug で出ていても、openclaw logs の整形表示だと見落としやすい形で出ることがあります。
確認はこれが確実です：
openclaw logs --follow --json | grep -i \"registered webhook\" -n
# もしくは
openclaw logs --follow --json | grep -i \"\\\"message\\\":\\\"line:\" -n
（--json で “生ログ” を見るのがポイント）
/line/webhook が 200 にならない場合その場合は OpenClaw側のバグの可能性がかなり高いです（少なくとも “webhookがあるはずのパスにハンドラが刺さらない” ので）。
GitHub issue に上げるなら、貼るべき材料はこれで十分強いです：
openclaw --versionopenclaw channels status --json（LINE部分）openclaw gateway statusPOST /non-existent-path（404か405か）GET /line/webhookPOST /line/webhook（{"events":[]}）Issues: https://github.com/openclaw/openclaw/issues
もしこれが既知回帰（Telegram webhookの405と類似）なら、最新版（beta/dev含む）で直っている可能性があります。
openclaw update → openclaw gateway restart を試す価値あります。次の返信では、まず **「controlUi無効化後の POST /non-existent-path が 404 か 405 か」**だけ教えてください。そこが分かると、原因が「まだUIが握ってる」なのか「本当に別の何かに吸われてる」なのか即決できます。
ここまでの最終レポート、内容がかなり「上流に渡せる品質」になってます。いま出ている挙動から判断すると、**ほぼバグ（少なくとも既存仕様とは不整合）**です。
ただし一点だけ、次の2つの追加テストで「原因がどちら系か」を確定できて、Issueがさらに強くなります。
GET /line/webhook -> 401 (JSON) は LINEハンドラの挙動ではありませんGET は 200 OK + OK (text/plain) のはず。POST /line/webhook -> 405 (Allowなし, text/plain) も LINEハンドラの 405 ではありませんAllow: GET, POST が付く実装です。→ つまり /line/webhook が plugin HTTP route として処理されていないのはほぼ確実です。
Control UI 無効化後に：
curl -i -X POST http://127.0.0.1:18789/non-existent-path
（※トークンは貼らないでOK）
TOKEN="$(openclaw config get gateway.auth.token)"
curl -i -H "Authorization: Bearer $TOKEN" http://127.0.0.1:18789/line/webhook
curl -i -X POST -H "Authorization: Bearer $TOKEN" -H "content-type: application/json" \
--data '{"events":[]}' http://127.0.0.1:18789/line/webhook
仕様上はざっくりこれだけです：
OPENCLAW_SKIP_CHANNELS=1 等）あなたのケースは channels status --probe が works なので、token/secret は実際に使えています。ここまで来ると「条件」より「回帰/バグ」側が自然です。
はい、現状の情報だけでも バグとしてIssueを立ててOKです。
GitHub issue: https://github.com/openclaw/openclaw/issues
貼ると強い添付はこれ：
openclaw --versionopenclaw gateway statusopenclaw channels status --json（line部分）この2テストが入ると、メンテ側が「どこで握ってるか」を一気に追いやすくなります。
hoary oasis
LINE Webhook URL (/line/webhook) に対する GET および POST リクエストが、LINE ハンドラに到達していない。
コミュニティからの診断により、両方とも LINE ハンドラではなく、別の HTTP ハンドラに吸われていることが判明。
───
再現手順
設定ファイル
~/.openclaw/openclaw.json:
{
"channels": {
"line": {
"enabled": true,
"channelAccessToken": "（172文字、有効な値）",
"channelSecret": "（32文字、有効な値）",
"dmPolicy": "pairing"
}
},
"gateway": {
"port": 18789,
"mode": "local",
"bind": "loopback",
"controlUi": {
"enabled": false
}
},
"plugins": {
"entries": {
"line": {
"enabled": true
}
}
}
}
テストコマンド
curl -i http://127.0.0.1:18789/line/webhook
curl -i -X POST "http://127.0.0.1:18789/line/webhook"
-H "content-type: application/json"
--data '{"events":[]}'
───
実際の挙動
GET /line/webhook
HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
{"error":{"message":"Unauthorized","type":"unauthorized"}}
問題: LINE ハンドラなら 200 OK + OK (text/plain) が返るはずだが、JSON で 401 が返る。
POST /line/webhook
HTTP/1.1 405 Method Not Allowed
Content-Type: text/plain; charset=utf-8
（Allow: ヘッダーなし）
Method Not Allowed
問題: LINE ハンドラなら 200 OK + {"status":"ok"} が返るはずだが、405 が返る。
比較: 存在しないパス
$ curl -i -X POST http://127.0.0.1:18789/non-existent-path
HTTP/1.1 404 Not Found
→ 404 が正しく返るため、Control UI の問題ではない。
───
診断結果
$ openclaw channels status --probe
Warnings:
• ✅ running: チャンネルは起動している
• ✅ works: LINE API への疎通は成功している（token/secret は正しい）
• ⚠️ 警告は誤警告（コミュニティから確認済み）
{
"line": {
"configured": true,
"running": true,
"lastStartAt": 1772523760437,
"lastStopAt": null,
"lastError": null,
"tokenSource": "config",
"mode": "webhook"
}
}
3. route 登録ログの確認
$ openclaw logs --json | grep -i "registered webhook"
（出力なし）
$ openclaw logs --json | grep -i ""message":"line:"
（出力なし）
結論: LINE Webhook の route 登録ログが存在しない
───
実施した対策
A. Control UI の basePath 設定
{
"gateway": {
"controlUi": {
"basePath": "/openclaw"
}
}
}
→ 効果なし（405 継続）
B. Control UI の完全無効化
{
"gateway": {
"controlUi": {
"enabled": false
}
}
}
確認テスト:
$ curl -i -X POST http://127.0.0.1:18789/non-existent-path
HTTP/1.1 404 Not Found ← 正常
→ Control UI は完全に無効化されているが、/line/webhook は依然として 405
C. logging.level=debug で詳細ログ確認
{
"logging": {
"level": "debug"
}
}
→ LINE の route 登録ログは一切出力されず
D. その他
• ✅ Gateway 再起動（SIGUSR1）
• ✅ Gateway 完全再起動（stop + start）
• ✅ mode: "webhook" 明示的設定
• ✅ webhookPath: "/line/webhook" 明示的設定
───
結論
問題の核心
OpenClaw の LINE プラグインが、Webhook Handler の HTTP route を Gateway に登録していない
証拠
推定される原因
• LINE プラグインが webhook モードで起動する際の route 登録処理に不具合がある
[17:26]• または特定の条件下（例: bind: "loopback", mode: "local" 等）で route 登録がスキップされている
• プラグインは loaded でチャンネルは running だが、HTTP ハンドラの登録フェーズが実行されていない
───
類似問題
コミュニティから、Telegram webhook でも類似の 405 報告があったとの情報あり。
最新版で修正されている可能性がある。
───
期待される動作
GET /line/webhook
HTTP/1.1 200 OK
Content-Type: text/plain
OK[17:26]POST /line/webhook (検証用)
HTTP/1.1 200 OK
Content-Type: application/json
{"status":"ok"}
───
環境詳細
$ openclaw --version
2026.3.1
$ openclaw gateway status
Service: LaunchAgent (loaded)
Gateway: bind=loopback (127.0.0.1), port=18789
Runtime: running (pid 12298, state active)
RPC probe: ok
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json
$ openclaw plugins list | grep LINE
LINE | line | loaded | stock:line/index.ts | 2026.3.1
───
再現性
• ✅ 100% 再現: すべてのテストで同じ結果
• ✅ 環境独立: ローカル、Tailscale Funnel 経由でも同じ
• ✅ 設定確認済み: token/secret は有効（probe で works）
───
追加情報
• Slack チャンネルは正常に動作中（socket モード）
• Gateway は正常稼働中
• 他のエンドポイント（404）は正常に動作
• Control UI は完全に無効化されている（404 で確認）
───
期待される対応
radiant briarBOT
このレポート、Issue に貼るには十分強いです。いま出てる症状は 2つの既知系統（401系・405系）が混ざってる可能性が高いです。
GET /line/webhook = 401 (JSON) は “Gateway の auth で弾かれてる” 形です{"error":{"message":"Unauthorized","type":"unauthorized"}} という JSON は、OpenClaw 側の Gateway auth failure の固定フォーマットです（LINEハンドラはこう返しません）。
つまり現状は：
…という回帰の匂いが濃いです。
実際、これとほぼ同じ内容の既存Issueがあります：
https://github.com/openclaw/openclaw/issues/31653
（要旨：/line/webhook が gateway auth の対象になってしまい 401 になる／LINEはBearer tokenを送れないので詰む、という話）
なので 新規Issueを立てるより、まず #31653 にあなたの macOS + 405 の追加状況をコメントで追記するのが一番メンテ側が助かります（重複管理が減る）。
POST /line/webhook = 405 (Allowなし) は “別ハンドラが最後に 405 を返してる” サインあなたの整理どおり、Allow: が無い 405 は LINEハンドラ由来ではありません。
ただ、ここで一点だけ **「Control UIを無効化しても405が継続＝UIではない」**は、まだ確定しません。
なぜなら、UIが本当に外れてるかは **“存在しないパスへのPOSTが404になるか”**でしか確定できないからです。
Control UI を enabled:false にした状態で：
curl -i -X POST http://127.0.0.1:18789/non-existent-path
この結果は Issue にめちゃ重要です。
logging.level=debug にしてても、openclaw logs の整形表示だと “verbose系ログ” が見つけにくいことがあります。
探すならこれが確実です：
openclaw logs --follow --json | grep -i "line: registered webhook"
（もしくは /tmp/openclaw/openclaw-YYYY-MM-DD.log を直接 grep）
すでに書けてる内容に加えて、これが入るとメンテが即デバッグできます：
gateway.auth の設定（modeが token/password/trusted-proxy どれかだけでも）POST /non-existent-path の結果（404 or 405）TOKEN="$(openclaw config get gateway.auth.token)"
curl -i -H "Authorization: Bearer $TOKEN" http://127.0.0.1:18789/line/webhook
curl -i -X POST -H "Authorization: Bearer $TOKEN" -H "content-type: application/json" \
--data '{"events":[]}' http://127.0.0.1:18789/line/webhook
（LINE本番ではBearerを付けられないので、これで通っても「回避」にはならないですが、原因特定には決定打になります）
必要なら、あなたのレポートを #31653 にコメントする用の短縮版（コピペ1発の文章）に整形して返します。まずは POST /non-existent-path が 404/405 のどっちだったかだけ教えてください。
POST /non-existent-path が 404 になってるので、これはもう Control UI が握ってる405ではないのが確定ですね。切り分け完璧です。
この状態での
GET /line/webhook → 401 Unauthorized (JSON)POST /line/webhook → 405 (text/plain, Allowなし)はどちらも LINE webhook ハンドラ本来の挙動ではないので、結論として「/line/webhook が LINE の handler に到達していない」は正しいです。
ただし、現状のパターンは **既知の回帰（LINE webhook が gateway auth に巻き込まれて 401 になる）**とかなり一致します。すでに近い Issue があります：
なので 新規 Issue を立てるより、まず #31653 にあなたの macOS + 405 併発の情報を追記コメントするのが一番良いと思います（重複整理が減る）。
/line/webhook が「gateway auth で弾かれてるだけ」なのか「そもそも route が無い」のかを判定できます。
TOKEN="$(openclaw config get gateway.auth.token)"
# GET with gateway token
curl -i -H "Authorization: Bearer $TOKEN" \
http://127.0.0.1:18789/line/webhook
# POST verification payload with gateway token
curl -i -X POST \
-H "Authorization: Bearer $TOKEN" \
-H "content-type: application/json" \
--data '{"events":[]}' \
http://127.0.0.1:18789/line/webhook
結果の見方：
openclaw logs --json の message フィールドは抽出形式の都合で空になり得るので、grep するなら .raw 側を見るのが確実です。
例（jqがあれば）：
openclaw logs --follow --json | jq -r 'select(.type=="log") | .raw' | grep -i "line:"
controlUi.enabled=false でも GET /line/webhook = 401(JSON), POST /line/webhook = 405(text/plain, Allowなし)POST /non-existent-path = 404（＝UIの405マスクではない証拠）これでメンテ側が「auth境界の回帰」か「route登録/ルーティングの問題」かを一気に特定できます。
hoary oasis
先ほど（17:16）のコミュニティ診断で既に実施しておりましたが、改めて確認いたします：
[17:32]## ✅ 重要: Control UI は完全に外れています
HTTP/1.1 404 Not Found
→ Control UI は正常に無効化されており、405 は別の原因です
[17:32]## gateway.auth 設定
json
{
"mode": "password"
}
[17:33]---
→ Control UI は外れている。405 は別原因。
{
"mode": "password"
}
$ curl -i -H "Authorization: Bearer $TOKEN" http://127.0.0.1:18789/line/webhook
HTTP/1.1 401 Unauthorized
Content-Type: application/json
{"error":{"message":"Unauthorized","type":"unauthorized"}}
$ curl -i -X POST -H "Authorization: Bearer $TOKEN"
-H "content-type: application/json"
--data '{"events":[]}'
http://127.0.0.1:18789/line/webhook
HTTP/1.1 401 Unauthorized
Content-Type: application/json
{"error":{"message":"Unauthorized","type":"unauthorized"}}
→ Bearer token を付けても 401 が返る
コミュニティの診断通り：
radiant briarBOT
POST /non-existent-path = 404 まで出ているので、Control UI が原因ではないのはこれで確定です。ナイス切り分けです。
その上で、いまの追加テスト結果の解釈はこうなります。
gateway.auth.mode: "password" の場合、Bearer に入れるべきは token ではなく password ですOpenClaw の HTTP 側は Authorization: Bearer ... を「token も password も同じ文字列として」検証します。
なので mode:"password" のときに
Authorization: Bearer $TOKEN（= gateway.auth.token）を入れても 必ず 401 になりますつまり今回の
Authorization を付けても 401 → route 登録に問題
は まだ断定できません（単に “ヘッダに入れた値が違う” 可能性が残っています）。
PASS="$(openclaw config get gateway.auth.password)" # もしくは OPENCLAW_GATEWAY_PASSWORD の値
curl -i -H "Authorization: Bearer $PASS" http://127.0.0.1:18789/line/webhook
curl -i -X POST -H "Authorization: Bearer $PASS" -H "content-type: application/json" \
--data '{"events":[]}' http://127.0.0.1:18789/line/webhook
たとえ上のテストで “password 付きなら通る” となっても、LINE プラットフォームは Gateway の password/token を付けられないので、現状の挙動だと LINE は動きません。
そしてまさにその回帰は既存 Issue #31653 が扱っています：
https://github.com/openclaw/openclaw/issues/31653
あなたの macOS 2026.3.1 のログと「POST が 405 になるケースもある」点は、#31653 に追記価値が高いです。
gateway.auth.mode=password（重要）POST /non-existent-path = 404GET /line/webhook = 401 (JSON)（Gateway auth failure 形式）POST /line/webhook = 405 (Allowなし, text/plain)（LINEハンドラの405形式ではない）必要なら、#31653 へのコメント文（英語）をコピペ用に整形して作ります。まずは上の password を使った Bearer テスト結果だけ教えてください。
hoary oasis
コメント文を作成してください
radiant briarBOT
以下、**#31653 に追記コメントする用（コピペ1発）**の文章です。
トークン/パスワード類は貼らない前提で書いてあります。
Comment (for issue #31653)
Hi! I can reproduce a related LINE webhook auth/routing issue on macOS with OpenClaw 2026.3.1.
mode=local, bind=loopback, port=18789gateway.auth.mode = "password"LINE | line | loaded | stock:line/index.ts | 2026.3.1gateway.controlUi.enabled=false)LINE webhook should accept:
GET /line/webhook → 200 OK (text/plain OK)POST /line/webhook with verification body {"events":[]} → 200 OK (JSON {"status":"ok"})Even with Control UI fully disabled, /line/webhook does not reach the LINE webhook handler:
GET /line/webhook
curl -i http://127.0.0.1:18789/line/webhook
→ HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
{"error":{"message":"Unauthorized","type":"unauthorized"}}
POST /line/webhook (LINE verification payload)
curl -i -X POST http://127.0.0.1:18789/line/webhook \
-H "content-type: application/json" \
--data '{"events":[]}'
→ HTTP/1.1 405 Method Not Allowed
Content-Type: text/plain; charset=utf-8
(no Allow: header)
With Control UI disabled:
curl -i -X POST http://127.0.0.1:18789/non-existent-path
→ HTTP/1.1 404 Not Found
So the 405 on /line/webhook is not coming from Control UI’s generic POST handling.
openclaw channels status --probe shows LINE as enabled, configured, running, token:config, works (so access token/secret appear valid), but inbound webhook traffic still fails as above.Authorization: Bearer <gateway token> and still got 401 (note: gateway is in password mode).This looks consistent with the regression described here (gateway auth enforced for LINE webhook), but I’m also seeing a persistent 405 on POST to /line/webhook even when Control UI is off.
Happy to run any extra diagnostics you’d like (e.g., testing with gateway password in the Authorization header, log grep for webhook route registration, etc.).
必要なら、あなたの最後の「Authorizationテスト」部分を password mode に合わせた形に書き換えた追記行（テストコマンド付き）も作れます。
hoary oasis
githubは利用していないので、あなたが代理でコメントしてもらえますか？
radiant briarBOT
できません。こちらから GitHub にログインして **代理でコメント投稿（第三者への送信/外部アクション）**はできない運用になっています。ごめんね。
代わりに、現実的な選択肢はこのどれかです：
GitHub はコメント/Issue投稿にアカウントが必要です。作ったら、さっき作った英語コメントを #31653 にそのまま貼るだけでOKです。
このスレに、僕が作ったコメント文を貼って「誰か #31653 に転記してもらえませんか？」とお願いする形です。
（トークン/パスワードは絶対に貼らないでください）
あなたの gateway.auth.mode が password なので、もし可能ならこの結果も添えるとメンテが一発で原因確定できます：
PASS="$(openclaw config get gateway.auth.password)" # 値は絶対貼らない
curl -i -H "Authorization: Bearer $PASS" http://127.0.0.1:18789/line/webhook
curl -i -X POST -H "Authorization: Bearer $PASS" -H "content-type: application/json" \
--data '{"events":[]}' http://127.0.0.1:18789/line/webhook
この“password付きでも401/405か？”が分かると、#31653 の回帰（gateway auth巻き込み）か、別のルーティング問題かを切り分けできます。
必要なら、Discordに貼る用の日本語版（「#31653 に転記してください」まで含む）も作ります。どっちで行きたい？（A: アカウント作る / B: Discordで転記依頼）