Summary

• Problem: oversized /v1/responses input_file text used text.slice(0, maxChars), so an emoji at the default 60_000 character cap could be split into a dangling UTF-16 surrogate in the model-visible file context.
• Solution: reuse truncateUtf16Safe from @openclaw/normalization-core/utf16-slice in src/media/input-files.ts::clampText.
• What changed: one truncation helper call and one live HTTP regression test covering base64 input_file content through /v1/responses.
• What was not changed: MIME sniffing, byte limits, URL/SSRF guards, PDF extraction, schemas, public API, config, and the untrusted <file> wrapper.
• Fixes #N/A — follow-up gap-fill PR with no closing issue.

What Problem This Solves

Oversized text extracted from an OpenResponses input_file can land exactly inside an emoji surrogate pair. The current clampText() implementation slices by UTF-16 code unit, so a payload like "a".repeat(59_999) + "😀tail" is truncated to a file-context string ending in the lone high surrogate \uD83D. That malformed model-visible text can then be forwarded in extraSystemPrompt instead of a valid UTF-16 boundary-aligned prefix.

User Impact

Users attaching large local text files through /v1/responses can get corrupted file context at the truncation boundary when the boundary falls inside emoji or another astral Unicode character. After this patch, the same oversized file is still capped, but the capped text never ends with a split surrogate pair.

Origin / follow-up

• Follows / completes: fix(codex): use truncateUtf16Safe for tool transcript output truncation #102522 (fix(codex): use truncateUtf16Safe for tool transcript output truncation).
• Gap this fills: that merged UTF-16 truncation sweep fixed another user-visible truncation path, while src/media/input-files.ts::clampText still used text.slice(0, maxChars) on the canonical /v1/responses input_file path.
• Consistency: this PR uses the same shared truncateUtf16Safe helper rather than adding a local surrogate check.

Competition / linked PR analysis

• Linked PR(s): N/A — no linked open PR for src/media/input-files.ts.
• Gap in linked PR(s): N/A.
• Why this patch is better/canonical: the patch changes the sole input_file text clamp before the file text is wrapped and passed into agentCommand({ extraSystemPrompt }).
• Local real behavior proof advantage: the added regression starts the real OpenResponses HTTP server, posts an actual /v1/responses request, runs real base64 input_file extraction, and asserts on the model-visible extraSystemPrompt.

Related scan:

gh search prs --repo openclaw/openclaw --state open "input_file"
#97166 feat(media): allow host-read vCard (.vcf) files
#80418 fix(/v1/responses): accept text field on requests for OpenAI SDK 6.x parity

Neither open PR touches src/media/input-files.ts::clampText or the UTF-16 truncation path.
Recently merged UTF-16 PRs checked: #102522, #102539, #102542, #102560, #102565, #102573.
None modifies src/media/input-files.ts or src/gateway/openresponses-http.test.ts.

Merge risk

• Why it matters / User impact: the model should receive valid text for attached files even when the file is capped at the maximum context size.
• Risk labels considered: compatibility, message-delivery, session-state, security-boundary, auth-provider, availability, automation.
• Risk explanation: compatibility is the only relevant consideration. The public request shape, schema, config, MIME handling, byte guard, and file wrapper are unchanged; only an oversized capped prefix may become one UTF-16 code unit shorter when the cap would otherwise split a surrogate pair. The other risk categories are not touched.
• Why acceptable: the diff is two files and changes one truncation call to an existing shared helper already used across the repo for this exact invariant. Focused E2E coverage proves the canonical HTTP path.
• Maintainer-ready confidence: High — the patch is minimal, reuses the repo standard helper, and the proof crosses the real /v1/responses HTTP boundary.
• Patch quality notes: The as never in the test only satisfies the existing typed agentCommand mock return shape and does not construct the malformed runtime state; the malformed state comes from a real HTTP request payload and real input_file extraction. No fallback, broad catch, default shim, or unrelated cleanup was added.
• Target test file: src/gateway/openresponses-http.test.ts.
• Root cause: src/media/input-files.ts::clampText used text.slice(0, maxChars), which can split UTF-16 surrogate pairs because JavaScript string indices are code-unit based.
• Why this is root-cause fix: the clamp now calls truncateUtf16Safe, whose source-of-truth implementation backs up before a split surrogate pair instead of masking the corrupted value downstream.
• What did NOT change: Public API / schema / protocol / defaults; MIME allowlist; byte limits; URL/SSRF guards; PDF extraction; unrelated channel/provider/session/security behavior; unrelated cleanup/docs/formatting/lockfiles.
• Architecture / source-of-truth check: src/media/input-files.ts::extractFileContentFromSource owns model-visible text extraction for input_file; this changes the text before downstream prompt wrapping and before agentCommand, not a mirrored or persisted projection.
• Scenario locked in: a base64 input_file whose default cap lands between the two UTF-16 code units of 😀.
• Why this is the smallest reliable guardrail: it tests the shipped /v1/responses server path and checks the final model-visible prompt payload, while the production change is a one-line replacement of the unsafe clamp.

Real behavior proof

• Behavior or issue addressed: /v1/responses input_file text truncation could split emoji at the default maxChars boundary and forward a dangling surrogate in extraSystemPrompt.
• Canonical reachability path: user POSTs /v1/responses → OpenResponses HTTP input parsing in src/gateway/openresponses-http.ts → input_file source passed to extractFileContentFromSource() → src/media/input-files.ts::clampText → renderFileContextBlock({ content: wrapUntrustedFileContent(rawText) }) → agentCommand({ extraSystemPrompt }).
• Boundary crossed: full config-to-request local gateway path: real HTTP server, real /v1/responses request parsing, real base64 input_file extraction, and assertion on agentCommand model prompt input.
• Shared helper / provider constraint check: shared helper reused: truncateUtf16Safe from @openclaw/normalization-core/utf16-slice. Provider constraint check is N/A because this is not a provider range/parser change.
• Real environment tested: local OpenClaw worktree /media/vdb/code/ai/aispace/openclaw-worktrees/followup-102478 after rebase onto current origin/main, Node/Vitest through pnpm -C "$TASK_WORKTREE" exec vitest.
• Exact steps or command run after this patch:

  pnpm -C "$TASK_WORKTREE" exec vitest run src/gateway/openresponses-http.test.ts
  pnpm -C "$TASK_WORKTREE" exec vitest run src/media/input-files.fetch-guard.test.ts
  node "$EVIDENCE_DIR/before-after-input-file.mjs"

• Evidence after fix:

  src/gateway/openresponses-http.test.ts
    ✔ OpenResponses HTTP API (e2e) > keeps base64 input_file text truncation UTF-16 safe
  Test Files  2 passed (2)
       Tests  64 passed (64)
  

  input length: 60005
  BEFORE last 8 codeUnits: "aaaaaaa\ud83d"
  BEFORE ends with lone high surrogate? true
  AFTER  last 8 codeUnits: "aaaaaaaa"
  AFTER  ends with lone high surrogate? false
  AFTER  contains lone low surrogate? false
  AFTER  contains 😀? false
  

• Observed result after fix: the live HTTP regression confirms the generated extraSystemPrompt contains <file name="emoji-boundary.txt">, does not include the split emoji, and does not match the lone high-surrogate regex /[\uD800-\uDBFF](?![\uDC00-\uDFFF])/u.
• What was not tested: no live external model/provider call was made; the proof stops at the OpenClaw gateway's model-facing agentCommand boundary, which is the source boundary for this local prompt-construction bug. URL input_file fetching and PDF image extraction were not separately exercised because they converge on the same clampText helper after extraction.
• Fix classification: Root cause fix.

Evidence

Focused command output from the rebased fix worktree:

RUN  v4.1.9 /media/vdb/code/ai/aispace/openclaw-worktrees/followup-102478

Test Files  2 passed (2)
     Tests  64 passed (64)
Start at  17:39:29
Duration  80.50s (transform 67.00s, setup 1.80s, import 27.47s, tests 50.66s, environment 0ms)

Additional focused extraction guard suite:

RUN  v4.1.9 /media/vdb/code/ai/aispace/openclaw-worktrees/followup-102478

Test Files  1 passed (1)
     Tests  17 passed (17)

Before/after repro for the exact boundary:

input length: 60005
BEFORE last 8 codeUnits: "aaaaaaa\ud83d"
BEFORE ends with lone high surrogate? true
AFTER  last 8 codeUnits: "aaaaaaaa"
AFTER  ends with lone high surrogate? false
AFTER  contains lone low surrogate? false
AFTER  contains 😀? false

Review findings addressed

• RF-001: N/A — this is a new follow-up PR, not an existing review-fix PR.

Regression Test Plan

pnpm -C "$TASK_WORKTREE" exec vitest run src/gateway/openresponses-http.test.ts
pnpm -C "$TASK_WORKTREE" exec vitest run src/media/input-files.fetch-guard.test.ts
node "$EVIDENCE_DIR/before-after-input-file.mjs"

Risk / Compatibility

Low risk. The request schema, endpoint behavior, MIME and byte validation, URL fetch guards, PDF extraction, and config defaults are unchanged. The only observable difference is for oversized extracted file text whose cap would otherwise land inside a surrogate pair; that output now drops the incomplete pair instead of forwarding a lone surrogate.

What was not changed

• Public API / schema / protocol / defaults: unchanged.
• Channel/provider/session/security behavior outside the fixed path: unchanged.
• Unrelated cleanup, docs, formatting, lockfiles: unchanged.

Root Cause

• Root cause: src/media/input-files.ts::clampText used text.slice(0, maxChars) and could cut between UTF-16 surrogate halves.
• Why this is root-cause fix: replacing the unsafe slice with the repo's shared truncateUtf16Safe enforces the boundary invariant at the only input_file text clamp before downstream prompt construction.
• Maintainer-ready confidence: High.
• Patch quality notes: Minimal source change; no fallback masking; no schema/config/provider behavior change; focused HTTP regression covers the shipped path.
• Architecture / source-of-truth check: extractFileContentFromSource is the owner of normalized input_file text before it is wrapped for the model. The patch changes the source-of-truth text before feedback/model input, not only a mirror/projection/persistence record.