Summary
When using BitFun's built-in WeChat gateway with Claw, an inbound image is downloaded successfully but cannot be inspected by a text-only primary model through the analyze_image tool.
The image is present as an inline data URL in the turn payload, but no local attachment path is created. Claw receives only the remote_img_<uuid> identifier and the tool treats it as a workspace-relative path.
Environment
- BitFun: 0.2.17 (macOS Apple Silicon)
- Channel: built-in WeChat gateway / Claw
- Primary model: GLM-5.3 (text-only; image inputs disabled)
- Reproduced: 2026-08-18
Steps to reproduce
- Configure a Claw session with a text-only primary model.
- Send a JPEG image to the Claw bot through WeChat.
- Let Claw try to inspect or describe the image.
Actual behavior
The image is received and displayed in the BitFun transcript, but Claw calls:
analyze_image(path="remote_img_<uuid>")
and fails with:
unable to locate image at <workspace>/remote_img_<uuid>: No such file or directory
The gateway logs show a successful CDN request immediately before the turn starts. The turn payload contains a valid data:image/jpeg;base64,... value, so the media download itself is not the failing step.
Expected behavior
One of these should happen:
- Save the downloaded/decoded image in a session-scoped temporary directory and expose its real
image_path; or
- Make
analyze_image accept the attachment ID / inline data URL directly; or
- Route the attachment directly to a configured vision-capable primary model when available.
The current prompt says to use analyze_image when a path is available, but the WeChat adapter only supplies a data URL.
Upstream references
The current implementation still follows this path in 0.2.18:
I have not tested outbound file delivery in this report; this issue is specifically about inbound image inspection from WeChat.
Summary
When using BitFun's built-in WeChat gateway with Claw, an inbound image is downloaded successfully but cannot be inspected by a text-only primary model through the
analyze_imagetool.The image is present as an inline data URL in the turn payload, but no local attachment path is created. Claw receives only the
remote_img_<uuid>identifier and the tool treats it as a workspace-relative path.Environment
Steps to reproduce
Actual behavior
The image is received and displayed in the BitFun transcript, but Claw calls:
analyze_image(path="remote_img_<uuid>")and fails with:
unable to locate image at <workspace>/remote_img_<uuid>: No such file or directoryThe gateway logs show a successful CDN request immediately before the turn starts. The turn payload contains a valid
data:image/jpeg;base64,...value, so the media download itself is not the failing step.Expected behavior
One of these should happen:
image_path; oranalyze_imageaccept the attachment ID / inline data URL directly; orThe current prompt says to use
analyze_imagewhen a path is available, but the WeChat adapter only supplies a data URL.Upstream references
The current implementation still follows this path in 0.2.18:
I have not tested outbound file delivery in this report; this issue is specifically about inbound image inspection from WeChat.