Title: Inbound image processing hangs silently in WSL2 due to GNOME Keyring blocking

Body

Environment

• OS: Ubuntu 24.04 on WSL2 (Windows 11, WSLg enabled)
• OpenClaw: v2026.3.31 (213a704)
• Node.js: v24.14.0
• Service manager: systemd user service
• Channel: Feishu (websocket), but likely affects all channels

Description

Sending any image to OpenClaw causes the gateway to hang silently. The image downloads successfully, dispatch begins, but then produces zero output — no API request logged, no error, no session JSONL write. The gateway process also becomes unresponsive to SIGTERM, requiring systemd SIGKILL after timeout. Queued messages are lost on restart.

This issue was introduced in v2026.3.31 (specifically by PR #55513). It does not occur on v2026.3.28.

Root Cause

The hang is caused by GNOME Keyring blocking synchronously in WSL2.

When OpenClaw's new attachment processing path (introduced by PR #55513) processes inbound images, it appears to trigger Chromium (via puppeteer/playwright, cached at ~/.cache/puppeteer/chrome or ~/.cache/ms-playwright). Chromium attempts to access GNOME Keyring via D-Bus/libsecret for credential storage.

In WSL2, this keyring access blocks synchronously with no timeout:

• No error is thrown
• No logs are written after the block occurs
• The process thread is stuck indefinitely
• SIGTERM cannot interrupt the blocked thread

The key breakthrough was observing a Windows GUI popup titled "Choose password for new keyring" (from WSLg's D-Bus bridge). After dismissing this popup, subsequent image dispatches completed successfully without hanging.

Evidence

Reproducible steps:

1. Run OpenClaw v2026.3.31 in WSL2 as a systemd user service
2. Send any image (<2MB, tested with 244KB and 385KB JPEGs) via any channel
3. Gateway hangs silently

Debug log sequence (reproduced 3 times with identical signature):

[INFO] media resolved: 1 attachment(s)
[INFO] dispatching to agent
(zero output for 3.5+ minutes)
SIGTERM → no response → systemd SIGKILL after 30s

What does NOT help:

• Changing the model (reproduces on text-only glm-5-turbo AND vision-capable glm-4.6v)
• Configuring imageModel (only affects the agent-exposed image tool, not dispatch path)
• Adding vision models to fallbacks (hang occurs before any model API call)

What DOES fix it temporarily:

• Dismissing the GNOME Keyring popup allows subsequent images to process
• Adding GNOME_KEYRING_CONTROL= and KEYRING_DISABLED=1 to the service environment prevents the popup and allows normal image processing

Expected Behavior

Either:

1. The attachment processing should not trigger Chromium/keyring access, OR
2. If keyring access is needed, it should have a timeout and fall back gracefully instead of blocking indefinitely, OR
3. A clear error should be logged instead of silent hang

Workaround

Add these environment variables to the OpenClaw gateway service:

Environment="GNOME_KEYRING_CONTROL=" "KEYRING_DISABLED=1"

Additional Notes

• OpenClaw's node_modules has no direct keyring/keytar/libsecret dependencies — the trigger comes purely from bundled Chromium
• This may affect other non-WSL Linux environments where GNOME Keyring is installed but not properly initialized (e.g., headless servers)
• PR fix(gateway): prevent OOM and socket hang up via Claim Check pattern for large attachments [media://inbound/<id> contract] #55513 introduced media://inbound/<id> opaque URI offloading for attachments 2-5MB and inline base64 for <2MB. Both paths appear to trigger the Chromium dependency

Related

• The SIGTERM unresponsiveness during this hang is a secondary issue — a stuck task should not block graceful shutdown