Greptile Summary

This PR adds a shared src/media/filename.ts utility for robust Content-Disposition filename decoding (RFC 5987, multi-charset, mojibake recovery), wires fetchRemoteMedia through it, and applies Feishu-specific mojibake recovery to inbound filenames before saveMediaBuffer.

• P1 – missing path-traversal sanitisation in normalizeFeishuFileName: the helper calls recoverLatin1Utf8Mojibake but never basenameFromUntrustedFilename. A Feishu message with file_name: "../../secret" passes through unchanged, while the parallel decodeContentDispositionFilename correctly strips traversal components. Adding basenameFromUntrustedFilename to normalizeFeishuFileName (or its call sites) closes the gap.

Confidence Score: 3/5

Not safe to merge without addressing the missing path-sanitisation in normalizeFeishuFileName.

A P1 security-relevant finding (path traversal not sanitised in Feishu inbound filenames) prevents a high-confidence score. The core filename.ts utility and fetch.ts refactor are clean and well-tested; the gap is isolated to the Feishu integration layer.

extensions/feishu/src/bot-content.ts — normalizeFeishuFileName needs basenameFromUntrustedFilename.

This is a comment left during a code review.
Path: extensions/feishu/src/bot-content.ts
Line: 44-50

Comment:
**`normalizeFeishuFileName` skips path-traversal sanitization**

`recoverLatin1Utf8Mojibake` corrects encoding but does not strip path separators or `..` components. A Feishu message carrying `../../secret.txt` as `file_name` would pass through unchanged and reach `saveMediaBuffer` with the traversal intact. `basenameFromUntrustedFilename` was added in this PR for exactly this purpose and is already used inside `decodeContentDispositionFilename`, but is not called here.

```suggestion
function normalizeFeishuFileName(fileName: unknown): string | undefined {
  if (typeof fileName !== "string") {
    return undefined;
  }
  const trimmed = fileName.trim();
  if (!trimmed) {
    return undefined;
  }
  return basenameFromUntrustedFilename(recoverLatin1Utf8Mojibake(trimmed));
}
```

(Also needs `import { basenameFromUntrustedFilename } from "openclaw/plugin-sdk/feishu"` or a direct import from the media module, whichever the project convention is.)

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: extensions/feishu/src/bot-content.ts
Line: 455-458

Comment:
**Redundant double-normalization of `mediaKeys.fileName`**

`mediaKeys.fileName` is the return value of `parseMediaKeys`, which already calls `normalizeFeishuFileName` on every branch (lines 307–314). Wrapping it again in `normalizeFeishuFileName` at this call site is a no-op (idempotent because `recoverLatin1Utf8Mojibake` short-circuits when no Latin-1 supplement chars remain), but it is misleading and wastes a regex test per call.

```suggestion
      normalizeFeishuFileName(result.fileName) || mediaKeys.fileName,
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "media: add shared filename decoder" | Re-trigger Greptile}

Codex review: needs real behavior proof before merge. Reviewed July 3, 2026, 5:52 AM ET / 09:52 UTC.

Summary
The PR adds a new filename decoder for remote media headers, wires remote media fetch to it, adds Feishu inbound filename normalization, and extends targeted media/Feishu tests.

PR surface: Source +280, Tests +111. Total +391 across 6 files.

Reproducibility: yes. by source inspection: current main's remote media parser cannot decode the PR's multi-charset Content-Disposition cases, and Feishu filename selection still has paths outside the PR's bot-content normalization. I did not run tests because this review is read-only.

Review metrics: 1 noteworthy metric.

• Filename decoder copies: 2 implementations added. The PR adds a core decoder and a Feishu-local recovery copy, which is exactly the drift the shared utility is meant to avoid.

Stored data model
Persistent data-model change detected: vector/embedding metadata: extensions/feishu/src/bot.test.ts. Confirm migration or upgrade compatibility proof before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #48788
Summary: This PR is a partial candidate for the open centralized filename decoding issue; several related Feishu/media filename items cover narrower slices of the same area.

Members:

• canonical: feat: centralized filename encoding utility for multi-encoding Content-Disposition handling #48788 - Open issue tracks the broader centralized filename encoding utility across channel adapters.
• same_root_cause: [Bug]: Feishu file names with Chinese characters are garbled (UTF-8 encoding issue) #48388 - Original Feishu CJK mojibake report is one concrete filename-decoding symptom in this cluster.
• partial_overlap: fix(feishu): recover mojibake filenames from Content-Disposition #72388 - Merged narrower Feishu Content-Disposition mojibake recovery overlaps the Feishu side but not the shared multi-charset utility.
• same_root_cause: [Bug]: Feishu inbound JSON file_name CJK mojibake (distinct from Content-Disposition path) #81103 - Reports the distinct Feishu JSON file_name mojibake path that this PR also tries to address.
• partial_overlap: fix(feishu): recover CJK filenames from JSON file_name field (fixes #81103) #93772 - Related candidate fix for the Feishu JSON file_name path, but it does not replace the broader shared decoder work in this PR.
• 2 more in the report.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🦪 silver shellfish
Proof: 🦪 silver shellfish
Patch quality: 🦐 gold shrimp
Result: blocked until stronger real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Refresh against current main's media-core layout.
• [P1] Add redacted terminal/live output or logs that exercise Feishu inbound filename recovery after the patch.
• Apply one shared decoder at both remote media and Feishu metadata/fallback filename selection points.

Proof guidance:

• [P1] Needs stronger real behavior proof before merge: The terminal proof exercises the core decoder and response-save path, but it does not show the changed Feishu inbound filename path after the fix. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Risk before merge

• [P1] Merging after only resolving conflicts could leave filename decoding split between a new src/media helper, media-core filename primitives, and Feishu-local recovery logic.
• [P1] The change intentionally rewrites user-visible attachment filenames, so Latin-1 and mojibake compatibility needs maintainer-visible coverage before merge.
• [P1] The supplied terminal proof covers the core decoder and response-save path, but not the changed Feishu inbound path.

Maintainer options:

1. Rebase around media-core (recommended)
   Refresh the branch and move the decoder into the current media-core/export boundary before considering merge.
2. Require Feishu-path proof
   Ask the contributor for redacted terminal/live output showing Feishu inbound filename recovery through the changed path after the rebase.
3. Keep the canonical issue open
   If the branch cannot be refreshed cleanly, keep the broader work tracked under the open centralized filename utility issue instead of landing a stale partial branch.

Next step before merge

• [P1] A maintainer should decide the media-core/SDK boundary after rebase, and the contributor needs Feishu-path real behavior proof before merge.

Security
Cleared: No concrete security or supply-chain regression was found; the blockers are compatibility, owner-boundary fit, and proof coverage.

Review findings

• [P1] Move the decoder into media-core — src/media/filename.ts:1
• [P2] Decode the Feishu metadata path too — extensions/feishu/src/bot-content.ts:389

Status update after addressing automated review feedback:

This PR is intended as the first scoped fix for #48788, plus the related #48388 filename decoding behavior. It fixes the shared media download path and Feishu inbound filename handling without trying to migrate every remaining channel-specific filename path in one PR.

What was fixed in the latest pushed head:

• src/media/filename.ts provides the shared filename decoding/sanitization helper used by fetchRemoteMedia.
• extensions/feishu/src/bot-content.ts now applies Feishu mojibake recovery and basename sanitization before saving inbound filenames.
• The Greptile P1 path traversal concern is addressed with basenameFromUntrustedFilename(recoverLatin1Utf8Mojibake(trimmed)).
• The redundant mediaKeys.fileName double-normalization was removed.
• The Codex P1 undefined media.fileName reference in the embedded post image path was fixed.

Verification run locally before push:

• Feishu targeted Vitest coverage passed, including regressions for traversal-style filenames and embedded post media filename fallback.
• Channel import guardrail tests passed.
• Extension prod/test type checks passed.
• Extension package compile boundary check passed.
• Formatting check and git diff --check passed.

Remaining scope:

#48788 should stay open after this PR unless maintainers want to expand this change. Remaining channel filename migrations and any broader SDK/API documentation or baseline alignment can be handled as follow-up work under #48788.

ClawSweeper PR egg

🎁 Pass real behavior proof to wake the egg and unlock a hatchable treat.

Heads up: this PR needs to be updated against current main before the new required Dependency Guard check can pass.

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

@szupzj18 thanks for the PR. ClawSweeper is still waiting on real behavior proof before this can move forward.

Useful proof can be a screenshot, short video, terminal output, copied live output, linked artifact, or redacted logs that show the changed behavior after the fix. Please redact private tokens, phone numbers, private endpoints, customer data, and anything else sensitive.

Once proof is added to the PR body or a comment, ClawSweeper or a maintainer can re-check it.

ClawSweeper status: review started.

I am starting a fresh review of this pull request: media: add shared filename decoder This is item 1/1 in the current shard. Shard 5/22.

This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.