Skip to content

fix(line): migrate media storage to saveMediaBuffer for sandbox compatibility#33145

Closed
carrotRakko wants to merge 1 commit into
openclaw:mainfrom
delight-co:fix/line-media-savemediabuffer-v2
Closed

fix(line): migrate media storage to saveMediaBuffer for sandbox compatibility#33145
carrotRakko wants to merge 1 commit into
openclaw:mainfrom
delight-co:fix/line-media-savemediabuffer-v2

Conversation

@carrotRakko

@carrotRakko carrotRakko commented Mar 3, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Problem: LINE media downloads use buildRandomTempFilePath (/tmp/openclaw/) which is outside the sandbox root, making downloaded files inaccessible to sandboxed agents
  • Why it matters: sandboxed agents cannot process LINE media (images, videos, audio, files)
  • What changed: migrated to saveMediaBuffer() (already used by Telegram, Discord, Signal) which stores files in ~/.openclaw/media/inbound/. Also extracts Content-Type from HTTP response headers and passes originalFilename to detectMime for extension-based MIME fallback
  • What did NOT change: streaming size validation remains, no change to media processing pipeline

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 now stored in ~/.openclaw/media/inbound/ instead of /tmp/openclaw/
  • Sandboxed agents can now access LINE media files
  • Better MIME type detection for file-type messages via Content-Type header + filename extension

Security Impact (required)

  • New permissions/capabilities? No
  • Secrets/tokens handling changed? No
  • New/changed network calls? No
  • Command/tool execution surface changed? No
  • Data access scope changed? No

Repro + Verification

Environment

  • Runtime/container: Docker (Linux) with sandbox enabled
  • Integration/channel: LINE
  • Relevant config: sandbox enabled, LINE account configured

Steps

  1. Enable sandbox mode
  2. Send an image/file to the LINE bot
  3. Observe whether the sandboxed agent can access the downloaded media

Expected

  • Media saved to ~/.openclaw/media/inbound/ and accessible within sandbox

Actual

  • Media saved to ~/.openclaw/media/inbound/ and accessible within sandbox

Evidence

  • Failing test/log before + passing after

Tests rewritten to verify saveMediaBuffer integration with correct parameters (buffer, contentType, "inbound" subdir, maxBytes, originalFilename).

Human Verification (required)

  • Verified scenarios: media download with sandbox enabled, Content-Type extraction from HTTP headers, originalFilename passthrough for file-type messages
  • Edge cases checked: oversized media rejection during streaming, missing Content-Type header
  • What you did not verify: production LINE API delivery with sandbox (verified via unit tests and manual testing without sandbox)

Compatibility / Migration

  • Backward compatible? Yes
  • Config/env changes? No
  • Migration needed? No

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly: revert this commit; media will go back to /tmp/openclaw/
  • Known bad symptoms reviewers should watch for: LINE media not appearing in agent context

Risks and Mitigations

None

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

@greptile-apps

greptile-apps Bot commented Mar 3, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR migrates LINE media downloads from ad-hoc /tmp/openclaw/ storage (via buildRandomTempFilePath + fs.writeFile) to the shared saveMediaBuffer utility already used by Telegram, Discord, and Signal integrations. Media is now stored under ~/.openclaw/media/inbound/, making it accessible to sandboxed agents.

Key changes:

  • downloadLineMedia now calls getMessageContentWithHttpInfo instead of getMessageContent to capture the HTTP response headers alongside the body stream.
  • MIME detection is delegated to saveMediaBuffer → detectMime, using the Content-Type response header as a hint. The hand-rolled detectContentType / getExtensionForContentType helpers are removed.
  • For "file"-type LINE messages, message.fileName is forwarded as originalFilename so detectMime can perform extension-based fallback and saveMediaBuffer can embed the sanitized name in the stored filename.
  • src/media/store.ts: single-line addition of filePath: originalFilename to the detectMime call inside saveMediaBuffer.
  • Tests are rewritten to match the new interface. The old path-traversal test is removed — path safety is now a structural guarantee (paths are UUID-based; messageId is never used in path construction).

The migration is correct, security properties are preserved, and existing test coverage is adequate.

Confidence Score: 5/5

  • This PR is safe to merge. The migration is well-scoped, preserves security properties, and uses an existing, proven utility.
  • The PR correctly migrates LINE media storage from /tmp to ~/.openclaw/media/inbound/ using the proven saveMediaBuffer utility. Security is maintained: paths are UUID-based with no messageId-derived components, streaming size validation is intact, and MIME detection is robust. All four files are straightforward and correct. No issues found.
  • No files require special attention.

Last reviewed commit: 53672ac

@delight-ai-agent
delight-ai-agent force-pushed the fix/line-media-savemediabuffer-v2 branch 3 times, most recently from d3b0740 to e3448fe Compare March 5, 2026 11:47
@carrotRakko
fix(line): migrate media storage to saveMediaBuffer for sandbox compa…
68189a3 
…tibility

LINE media downloads use buildRandomTempFilePath (/tmp/openclaw/)
which is outside the sandbox root, making downloaded files
inaccessible to sandboxed agents.  Migrate to the shared
saveMediaBuffer() function (already used by Telegram, Discord,
Signal) which stores files in ~/.openclaw/media/inbound/.

Also extracts Content-Type from the LINE API HTTP response headers
and passes originalFilename through to detectMime for better
extension-based MIME fallback on file-type messages.

Closes openclaw#27722

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)
@delight-ai-agent
delight-ai-agent force-pushed the fix/line-media-savemediabuffer-v2 branch from e3448fe to 68189a3 Compare March 6, 2026 03:37
@thewilloftheshadow thewilloftheshadow added r: too-many-prs Auto-close: author has more than twenty active PRs. and removed trusted-contributor labels Mar 6, 2026
@openclaw-barnacle

openclaw-barnacle Bot commented Mar 6, 2026

Copy link
Copy Markdown

Closing this PR because the author has more than 10 active PRs in this repo. Please reduce the active PR queue and reopen or resubmit once it is back under the limit. You can close your own PRs to get back under the limit.

@openclaw-barnacle openclaw-barnacle Bot closed this Mar 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

r: too-many-prs Auto-close: author has more than twenty active PRs. size: M

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

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

2 participants

@carrotRakko @thewilloftheshadow