Feishu image webhook messages lose imageKey before reaching the agent

[MicroMilo]

Summary

Feishu webhook image messages are parsed into structured content with imageKey, but the message router only consumes imageUrl. The parsed image therefore produces no agent content block and falls back to the generic prompt 请处理上述内容.

The repository already has a downloadImage(imageKey) capability, but the current router path does not use it because imageKey is not consumed.

Minimal Reproduction

Use this Feishu image webhook payload shape:

{
  "message_type": "image",
  "content": {
    "image_key": "img_v2_repro"
  }
}

Current source path:

1. parseMessageContent() creates { type: "image", imageKey: "img_v2_repro" }.
2. convertToContentBlocks() checks only message.content.imageUrl.
3. Because imageUrl is absent, it emits no image/content block.
4. extractPromptAndCwd() uses the generic non-text prompt 请处理上述内容.

Actual result: the agent receives no image content and only receives the generic prompt.

Evidence

• src/main/remote/channels/feishu/feishu-channel.ts:409-426 parses image webhooks into imageKey.
• src/main/remote/types.ts:320-329 allows image content to carry either imageUrl or imageKey.
• src/main/remote/message-router.ts:385-407 only checks message.content.imageUrl.
• src/main/remote/message-router.ts:441-469 falls back to the generic prompt for non-text content.
• src/main/remote/message-router.ts:272-329 still calls the agent even when content blocks are empty.
• src/main/remote/channels/feishu/feishu-api.ts:293-296 provides downloadImage(imageKey), but the router does not reach it for webhook images.
• src/main/remote/channels/feishu/feishu-ws-client.ts:309-318 and src/main/remote/channels/feishu/feishu-channel.ts:266-285 use a different non-text path for WebSocket messages, so webhook and WebSocket semantics differ.

Actual Behavior

A Feishu webhook image with image_key is parsed successfully, then dropped before reaching the agent content blocks.

Expected Behavior

Webhook images represented by imageKey should be converted into agent-consumable image content, or should return an explicit unsupported/download-failed message. They should not silently become empty content plus a generic prompt.

Webhook and WebSocket Feishu non-text messages should share the same content contract.

Existing Issue / PR Coverage

Checked open and closed issues/PRs with:

• Feishu image_key imageKey imageUrl message-router attachment
• Feishu file voice image webhook websocket content

No direct issue or PR coverage was found.

Proposed Fix

• Share one Feishu content parser between webhook and WebSocket paths.
• In the router, handle imageKey by using the existing Feishu image download API and producing an agent-consumable image block.
• Preserve file and voice keys, and return explicit feedback when those attachments are not supported.
• Avoid the successful path where non-text content produces empty content blocks and only the generic prompt.

Suggested Tests

• A webhook image message with image_key produces a non-empty agent content block or a clear error.
• Webhook and WebSocket image messages follow the same semantics.
• File messages preserve file.key.
• Voice messages do not degrade to only an opaque placeholder.

[github-actions]

Thank you for the detailed bug report! I can confirm the issue based on your analysis of the codebase. The evidence you provided aligns with the current implementation:

• src/main/remote/feishu/feishu-channel.ts:409-426 parses webhook images into imageKey.
• src/main/remote/types.ts:320-329 defines image content with both imageUrl and imageKey fields.
• src/main/remote/message-router.ts:385-407 only checks message.content.imageUrl, so the imageKey is ignored.
• src/main/remote/message-router.ts:441-469 falls back to generic prompt when no text content is produced.
• src/main/remote/feishu/feishu-api.ts:293-296 provides downloadImage(imageKey), but the router never calls it for webhook messages.

Root cause: message-router.ts's convertToContentBlocks() lacks handling for imageKey. It should call downloadImage(imageKey) to obtain a URL and produce an agent-consumable image content block.

Suggested fix:

1. In convertToContentBlocks(), add a condition for message.content.imageKey that calls downloadImage(imageKey) (via a provided Feishu API instance) to convert it to a URL, then create an image content block.
2. Unify the parsing between webhook and WebSocket paths (as you noted in feishu-ws-client.ts vs feishu-channel.ts) to avoid duplicated logic.
3. For unsupported attachments (e.g., voice, file), return an explicit error message instead of silently using the generic prompt.

Would you like to submit a pull request with these changes, or should we open this for community contribution? Let me know if you need any further assistance.

---

Open Cowork Bot

[MicroMilo]

I opened PR #260 to address the confirmed routing contract drift.

The fix keeps key-only remote attachments from being dropped before they reach the agent. Feishu image messages with imageKey, file messages with file.key, and voice messages with voice.key are now converted into explicit agent content blocks that preserve the platform reference instead of producing an empty content array with only the generic prompt.

Regression coverage is included in tests/remote-contract-drift.test.ts.

---

Submitted with Codex.
Co-authored-by: Codex codex@openai.com