Summary

The iOS Share Extension silently truncates a multi-image share to the first 3 images, and silently discards every shared video, file, and PDF. It counts them, then throws the counts away.

Bug type

Behavior bug (incorrect output/state without crash).

Evidence (source review)

extractSharedContent tallies each attachment class, caps images at 3, and then discards all four counters without ever using them:

apps/ios/ShareExtension/ShareViewController.swift:393

var imageCount = 0
var videoCount = 0
var fileCount = 0
var unknownCount = 0
var attachments: [ShareAttachment] = []
let maxImageAttachments = 3

apps/ios/ShareExtension/ShareViewController.swift:414

if provider.hasItemConformingToTypeIdentifier(UTType.image.identifier) {
    imageCount += 1
    if attachments.count < maxImageAttachments,
       let attachment = await self.loadImageAttachment(from: provider, index: attachments.count)
    {
        attachments.append(attachment)
    }
} else if provider.hasItemConformingToTypeIdentifier(UTType.movie.identifier) {
    videoCount += 1          // counted, never sent
} else if provider.hasItemConformingToTypeIdentifier(UTType.fileURL.identifier) {
    fileCount += 1           // counted, never sent
} else {
    unknownCount += 1        // counted, never sent
}

apps/ios/ShareExtension/ShareViewController.swift:431

_ = imageCount
_ = videoCount
_ = fileCount
_ = unknownCount

Those four _ = discards are the tell: the counts were evidently meant to drive a user-visible summary (the surviving log line at ShareViewController.swift:97 still reports images=), but nothing consumes them. Only attachments — images, at most 3 — reaches AgentRequestPayload at ShareViewController.swift:266, and the extension then reports "Sent to OpenClaw." (ShareViewController.swift:147).

Steps to reproduce

1. In Photos on iOS, select 6 images and share them to the OpenClaw share extension. Tap Send to OpenClaw.
2. Separately, share a video or a PDF (e.g. from Files) to the OpenClaw share extension. Tap Send to OpenClaw.

Expected behavior

Either all selected attachments are delivered, or the user is told what was omitted ("3 of 6 images sent; videos are not supported yet"). Silently succeeding with partial content is the worst of the three options.

Actual behavior

• 6 images → 3 delivered, 3 dropped with no notice.
• Video / PDF / other file → nothing delivered but the accompanying text; no notice.

In both cases the UI shows the success status.

Impact and severity

• Affected: iOS share-extension users sharing more than 3 images, or any non-image attachment.
• Severity: Silent data loss; the agent reasons over a subset of what the user shared without either party knowing.
• Frequency: Deterministic — any share with >3 images, or with a video/file attachment.
• Consequence: Agent answers are quietly based on incomplete input. A user asking "compare these 6 screenshots" gets an answer about 3.

Suggested direction

Consume the existing counters to render an explicit summary in the draft or status label, and decide deliberately whether the 3-image cap is product policy (if so, say so in the UI) or an artifact worth raising.

OpenClaw version

2026.6.11 (source review against main @ 6db586a388)

Operating system

iOS (share extension). Not reproduced on device — see below.

Additional information

Found by source review of apps/ios/ShareExtension/ShareViewController.swift; not observed at runtime, so no device logs or screenshots are attached. The cap and the discards are unconditional in source. Related but distinct from the >5 MB single-image drop, which I filed separately.

Reported with AI assistance (Claude Code); the analysis and line references were verified against the current source by the filer.