Summary
After a recent OpenClaw update, Feishu/Lark slash commands sent to Codex/GPT-backed sessions were received and authorized, but no visible response was delivered.
The same Feishu channel and MiniMax-backed agents still delivered command responses normally, so this looks like a runtime/command-dispatch compatibility regression rather than a Feishu transport problem.
Environment
- OpenClaw:
2026.5.12 (f066dd2)
@larksuite/openclaw-lark: 2026.5.13- Channel: Feishu/Lark DM, WebSocket mode
- Affected runtime/provider path: Codex/GPT-backed agents
- Less/not affected path observed locally: MiniMax-backed agents
Symptoms
Slash commands such as:
were accepted by the Feishu plugin, but the user saw no reply.
Representative sanitized logs from the affected path:
[feishu] feishu[zero]: detected system command, using plain-text dispatch
[feishu] feishu[zero]: command context authorized=true nativeFastPath=false message=<redacted>
[feishu] feishu[zero]: system command dispatched (delivered=false)
A MiniMax-backed agent in the same install continued to return visible command responses:
[feishu] feishu[luban]: detected system command, using plain-text dispatch
[feishu] feishu[luban]: command context authorized=true nativeFastPath=false message=<redacted>
[feishu] feishu[luban]: system command dispatched (delivered=true)
After applying a local workaround so the affected slash/system commands used the native fast path, the Codex/GPT-backed sessions recovered:
[feishu] feishu[default]: command context authorized=true nativeFastPath=true message=<redacted>
[feishu] feishu[default]: system command dispatched (delivered=true)
[feishu] feishu[zero]: command context authorized=true nativeFastPath=true message=<redacted>
[feishu] feishu[zero]: system command dispatched (delivered=true)
Expected behavior
Authorized Feishu/Lark slash commands should produce a visible command response consistently across runtime/provider paths.
Actual behavior
For Codex/GPT-backed sessions, the command was recognized and authorized but dispatch completed with delivered=false, leaving the user with no response.
Workaround
Forcing the affected slash/system commands onto the native fast-path restored visible responses locally.
Notes
This seems to expose a protocol boundary issue between the Feishu plugin command path and the core system-command handling path after the update. The current behavior is surprising because command state may be applied, but the acknowledgement/reply is lost.
Summary
After a recent OpenClaw update, Feishu/Lark slash commands sent to Codex/GPT-backed sessions were received and authorized, but no visible response was delivered.
The same Feishu channel and MiniMax-backed agents still delivered command responses normally, so this looks like a runtime/command-dispatch compatibility regression rather than a Feishu transport problem.
Environment
2026.5.12 (f066dd2)@larksuite/openclaw-lark:2026.5.13Symptoms
Slash commands such as:
/status/reasoning onwere accepted by the Feishu plugin, but the user saw no reply.
Representative sanitized logs from the affected path:
A MiniMax-backed agent in the same install continued to return visible command responses:
After applying a local workaround so the affected slash/system commands used the native fast path, the Codex/GPT-backed sessions recovered:
Expected behavior
Authorized Feishu/Lark slash commands should produce a visible command response consistently across runtime/provider paths.
Actual behavior
For Codex/GPT-backed sessions, the command was recognized and authorized but dispatch completed with
delivered=false, leaving the user with no response.Workaround
Forcing the affected slash/system commands onto the native fast-path restored visible responses locally.
Notes
This seems to expose a protocol boundary issue between the Feishu plugin command path and the core system-command handling path after the update. The current behavior is surprising because command state may be applied, but the acknowledgement/reply is lost.