Skip to content

fix(line): migrate media downloads to saveMediaBuffer for sandbox access#353

Open
BingqingLyu wants to merge 2 commits into
mainfrom
fork-pr-42010-fix-line-media-sandbox-access
Open

fix(line): migrate media downloads to saveMediaBuffer for sandbox access#353
BingqingLyu wants to merge 2 commits into
mainfrom
fork-pr-42010-fix-line-media-sandbox-access

Conversation

@BingqingLyu

@BingqingLyu BingqingLyu commented Apr 27, 2026

Copy link
Copy Markdown
Owner

Summary

  • Problem: LINE media downloads are saved to /tmp via buildRandomTempFilePath, which is outside the sandbox root (~/.openclaw/media/). Sandboxed agents cannot access downloaded LINE media files (images, videos, audio, documents).
  • Why it matters: Any LINE deployment using sandbox mode silently loses media context — the agent receives <media:...> placeholders but the files are inaccessible.
  • What changed: downloadLineMedia now uses saveMediaBuffer (writes to ~/.openclaw/media/inbound/), captures the Content-Type header from LINE API responses, and passes originalFilename from file messages through to detectMime for extension-based MIME fallback.
  • What did NOT change (scope boundary): No changes to non-LINE media paths. No changes to saveMediaBuffer itself (only the filePath argument to detectMime was missing). No new dependencies.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

User-visible / Behavior Changes

  • LINE media files (image, video, audio, file) are now saved to ~/.openclaw/media/inbound/ instead of /tmp/openclaw/. Sandboxed agents can access these files.
  • Content-Type from LINE API response headers is now used for MIME detection, improving accuracy over buffer-only sniffing.
  • LINE file messages (PDF, DOCX, etc.) now preserve the original filename in the saved file path, enabling extension-based MIME fallback for uncommon file types.

Security Impact (required)

  • New permissions/capabilities? No
  • Secrets/tokens handling changed? No
  • New/changed network calls? No — same LINE API endpoint, switched from getMessageContent to getMessageContentWithHttpInfo (same HTTP call, richer response object)
  • Command/tool execution surface changed? No
  • Data access scope changed? No — files move from /tmp to ~/.openclaw/media/inbound/, both are local storage. saveMediaBuffer applies the same size limits.
  • If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

  • Runtime/container: Node.js in Docker
  • Integration/channel: LINE Messaging API
  • Relevant config: channels.line with sandbox enabled

Steps

  1. Configure a LINE channel with sandbox mode enabled
  2. Send an image or PDF file to the LINE bot
  3. Check ~/.openclaw/media/inbound/ for the downloaded file

Expected

  • Media file appears in ~/.openclaw/media/inbound/ with correct MIME type and extension
  • Agent can access the file within the sandbox

Actual (before fix)

  • Media file saved to /tmp/openclaw/line-media-*.ext
  • Sandboxed agent cannot access the file (outside sandbox root)

Evidence

  • Failing test/log before + passing after
  • All existing tests pass. download.test.ts tests updated to match the new saveMediaBuffer-based flow (mock saveMediaBuffer instead of fs.writeFile).

Human Verification (required)

  • Verified scenarios: Reviewed upstream download.ts, bot-handlers.ts, and store.ts to confirm the changes are still applicable (no upstream changes to these code paths since the original fork implementation).
  • Edge cases checked: originalFilename is undefined for non-file message types (image/video/audio) — saveMediaBuffer handles this gracefully. Oversized media rejection still works (streaming size check before saveMediaBuffer call).
  • What you did not verify: Live LINE API integration test (requires LINE channel credentials and sandbox environment).

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

N/A — fresh PR, no review conversations yet.

Compatibility / Migration

  • Backward compatible? Yes — media files are now saved to a different path, but all consumers use the returned path from downloadLineMedia, not hardcoded paths.
  • Config/env changes? No
  • Migration needed? No

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly: Revert commit, LINE media downloads fall back to /tmp storage (non-sandbox-accessible).
  • Files/config to restore: None
  • Known bad symptoms reviewers should watch for: LINE media files not appearing in ~/.openclaw/media/inbound/ after download.

Risks and Mitigations

  • Risk: getMessageContentWithHttpInfo API may behave differently across @line/bot-sdk versions (response shape).
    • Mitigation: The SDK types guarantee httpResponse.headers exists. The Content-Type header extraction has a ?? undefined fallback for missing headers.

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)

…nd improve MIME detection

Migrate LINE media downloads from buildRandomTempFilePath (/tmp) to
saveMediaBuffer (~/.openclaw/media/inbound/) so files are accessible
inside the sandbox.  Also:

- Switch from getMessageContent to getMessageContentWithHttpInfo to
  capture the Content-Type header from LINE API responses.
- Pass originalFilename (from LINE file messages) through to
  saveMediaBuffer, enabling extension-based MIME fallback in detectMime.
- Remove the local detectContentType/getExtensionForContentType helpers
  (now handled by saveMediaBuffer's detectMime pipeline).

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)
Addresses Greptile review: `httpResponse.httpResponse.headers` was
confusing because the outer variable shadowed the SDK property name.

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature]: Support LINE file message type (PDF, etc.) in inbound media download

2 participants