Binary .doc files (OLE2 Compound Binary Format) were not recognized as binary by isBinaryMediaMime(), causing ~70KB of binary garbage to be embedded as text content in conversation prompts. This triggered content filtering rejections from LLM providers, breaking entire conversation sessions.

Add application/x-cfb and application/msword to the binary MIME type allowlist so these files are correctly skipped during text extraction.

Fixes #54176

Summary

• Problem: When a .doc file is sent via Feishu channel, the media pipeline treats it as text-eligible and embeds binary content into the conversation prompt. This triggers "high risk" content filtering rejections from LLM providers.
• Why it matters: The entire conversation session breaks — not just the single message. Users on Feishu (and potentially other channels) cannot send .doc attachments without corrupting their session.
• What changed: Added application/x-cfb (OLE2 Compound Binary Format) and application/msword (Word 97-2003) to the binary MIME type check in isBinaryMediaMime() in src/media-understanding/apply.ts. Added 2 corresponding tests.
• What did NOT change (scope boundary): No other MIME detection logic changed. The function signature, call site (line 363), and overall media pipeline flow are unchanged. No config, no new dependencies.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• 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

• Closes [Bug]: Binary files (.doc) should not be auto-embedded as text content #54176
• Related # N/A
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

• Root cause: isBinaryMediaMime() in src/media-understanding/apply.ts (line 286) checks a hardcoded list of binary MIME types. application/x-cfb and application/msword were missing from this list. These MIME types fall through all checks (archive formats, application/vnd.* vendor prefix) and return false, allowing binary content to proceed to text extraction.
• Missing detection / guardrail: No test verified that legacy Office binary formats (pre-OOXML) were treated as binary. Existing tests covered application/vnd.openxmlformats-* (ZIP-based Office) but not the older OLE2/CFB-based formats.
• Prior context: The isBinaryMediaMime() function was written to cover common binary formats (images, audio, video, archives, application/vnd.*). OLE2 .doc files use application/x-cfb which does not fall under any of those categories.
• Why this regressed now: Likely present since isBinaryMediaMime() was first introduced. Became visible when Feishu users started sending legacy .doc files, which are detected as application/x-cfb by file-type libraries.
• If unknown, what was ruled out: N/A — root cause is clear from reading the function.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/media-understanding/apply.test.ts
• Scenario the test should lock in: (1) A file with MIME application/x-cfb and CFB magic bytes is NOT applied as text content. (2) A file with MIME application/msword and CFB magic bytes is NOT applied as text content.
• Why this is the smallest reliable guardrail: The tests directly exercise the applyMediaUnderstanding pipeline with these MIME types and assert the file is skipped — if someone removes the MIME entries, the tests fail immediately.
• Existing test that already covers this (if any): None — existing "skips binary application/vnd office attachments" test only covers ZIP-based OOXML formats.
• If no new test is added, why not: N/A — 2 new tests added.

User-visible / Behavior Changes

• .doc files sent via any channel are now correctly treated as binary and skipped during text extraction, instead of having their binary content embedded in the conversation prompt.
• No change for .docx or other Office formats (already handled by application/vnd.* check).

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
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS (also reproducible on Linux)
• Runtime/container: Node.js 22+
• Model/provider: Any LLM provider (binary content triggers content filtering)
• Integration/channel (if any): Feishu (primary repro channel)
• Relevant config (redacted): Feishu channel configured with valid credentials

Steps

1. Configure a Feishu channel
2. Send a legacy .doc file (Word 97-2003 format) as an attachment
3. Observe that the binary content is embedded in the conversation prompt and the LLM provider rejects it with a "high risk" content filtering error

Expected

• The .doc file is recognized as binary and skipped during text extraction

Actual

• Before this PR: ~70KB of binary garbage is embedded as text content, triggering content filtering rejections and breaking the conversation session
• After this PR: the file is correctly identified as binary and not embedded

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

2 new tests in src/media-understanding/apply.test.ts: "skips binary OLE2 .doc attachments (application/x-cfb)" and "skips binary .doc attachments (application/msword)". All 34 media understanding tests pass. pnpm check passes cleanly.

Human Verification (required)

• Verified scenarios: Both new MIME types are correctly identified as binary by isBinaryMediaMime(). Files with these MIME types are skipped by applyMediaUnderstanding. All existing tests remain green.
• Edge cases checked: application/vnd.* office formats still handled (existing test). Vendor +json/+xml payloads still eligible for text extraction (existing test). application/octet-stream still binary (existing logic).
• What you did not verify: Manual end-to-end Feishu .doc send with real API. Other OLE2-based formats (.xls, .ppt) which also use application/x-cfb — these are covered by the same fix.

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.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? Yes — binary .doc files were never intended to be text-extracted; this restores correct behavior.
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: Revert this single commit.
• Files/config to restore: src/media-understanding/apply.ts to prior version; remove new tests from src/media-understanding/apply.test.ts.
• Known bad symptoms reviewers should watch for: If a downstream feature relied on text-extracting .doc files (unlikely — the extracted content was binary garbage), that feature would stop receiving content for .doc inputs.

Risks and Mitigations

• Risk: Other OLE2-based formats (.xls, .ppt) also use application/x-cfb and will now be treated as binary.
  • Mitigation: This is intentional and correct. All OLE2 Compound Binary Format files are binary; text extraction produces garbage for all of them.