fix(ios): block incomplete shares when attachments are omitted by steipete · Pull Request #106513 · openclaw/openclaw

steipete · 2026-07-13T15:36:23Z

Closes #103363
Supersedes #104842 while preserving @jincheng-xydt's contribution and co-author credit.

What Problem This Solves

Fixes an issue where users sharing more than three images, videos, files, unsupported items, or unloadable text representations from the iOS Share Extension could send an incomplete message while the omitted content was silently discarded.

Why This Change Was Made

The Share Extension now summarizes every selected attachment, blocks both the compose UI and the send path whenever content would be omitted, and loads generic text representations before deciding whether a provider is unsupported. Image-processing failures remain authoritative, and the existing three-image upload limit stays unchanged.

User Impact

Users now see a specific recovery message and cannot accidentally send a partial share. Supported one-to-three-image and text/URL shares continue normally.

Evidence

Fresh autoreview --mode uncommitted: clean, no accepted or actionable findings.
git diff --cached --check: pass before the squashed replacement commit.
Focused Swift logic coverage added for image truncation, unsupported item grammar, failed provider loads, and image-processing precedence.
Real iPhone 17 Pro / iOS 26.2 Photos → Share Sheet proof on the contributor implementation: six images showed the omission warning with Send disabled; the one-image control remained sendable. See fix(ios): block omitted share attachments #104842 (comment).
Fresh exact-head hosted CI will run on this replacement PR.

Co-authored-by: jincheng-xydt <[email protected]>

clawsweeper · 2026-07-13T17:30:47Z

Codex review: needs maintainer review before merge. Reviewed July 13, 2026, 2:11 PM ET / 18:11 UTC.

Summary
The PR adds iOS Share Extension attachment accounting, blocks compose and send when selected content would be omitted, improves generic text loading, and adds focused Swift tests.

PR surface: Other +185. Total +185 across 5 files.

Reproducibility: yes. Current main deterministically caps accepted images at three and sends only that array, while linked native Photos share-sheet proof demonstrates the six-image omission path and normal one-image control.

Review metrics: none identified.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #103363
Summary: This PR is the live replacement candidate for the canonical iOS silent-omission issue and supersedes the closed predecessor branch.

Members:

canonical: [Bug]: iOS Share Extension silently truncates shares to 3 images and discards videos/files #103363 - The issue documents the same deterministic image truncation and unsupported-attachment omission addressed by this PR.
superseded: fix(ios): block omitted share attachments #104842 - The current PR explicitly replaces this closed, unmerged predecessor while preserving its contribution and native proof.

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

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster ✨ media proof bonus
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

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

Rank-up moves:

[P1] Obtain iOS owner approval for unconditional fail-closed behavior.
Refresh from current main and rerun exact-head native over-limit and normal-share proof.

Risk before merge

[P1] Existing over-limit or mixed-content shares that previously delivered a supported subset will instead be blocked until the user removes omitted items and retries.
[P1] The branch is behind current main, so exact-head iOS build and native share-sheet validation should be refreshed after updating it; stale base alone is not a patch defect.

Maintainer options:

Approve and validate fail-closed delivery (recommended)
Have an iOS owner confirm the blocking policy, refresh the branch, and rerun exact-head native proof for over-limit and normal shares.
Add explicit partial-send confirmation
Replace unconditional blocking with a clear omitted-item summary and user confirmation before sending the supported subset.
Pause the behavior change
Keep current delivery semantics until product ownership selects the permanent partial-share policy.

Next step before merge

[P1] An iOS owner should approve the released-surface fail-closed delivery policy and review refreshed exact-head native proof; no narrow automated repair is established.

Maintainer decision needed

Question: Should the iOS Share Extension reject the entire share whenever any selected attachment cannot be delivered, rather than allow an explicitly disclosed partial send?
Rationale: Both choices avoid silent omission, but unconditional blocking establishes a new user workflow for a released native surface, and tests cannot determine that product policy.
Likely owner: mbelinky — Repository contribution guidance identifies this person with the iOS app, and the decision changes native share-extension delivery semantics.
Options:
- Approve fail-closed blocking (recommended): Keep this PR’s behavior so any omitted attachment disables Send until the user removes unsupported or over-limit items and shares again.
- Allow confirmed partial sends: Add a confirmation flow that lists omitted items and lets the user deliberately send the supported subset.

Security
Cleared: The Swift logic, tests, i18n source-location adjustment, and Xcode project entry add no concrete security or supply-chain concern.

Review details

Best possible solution:

Land the controller-owned omission guard after an iOS owner confirms fail-closed behavior, preserving supported one-to-three-image and text/URL shares while preventing every partial-send path.

Do we have a high-confidence way to reproduce the issue?

Yes. Current main deterministically caps accepted images at three and sends only that array, while linked native Photos share-sheet proof demonstrates the six-image omission path and normal one-image control.

Is this the best way to solve the issue?

Yes for the implementation shape: centralized accounting plus a send-path guard is narrower and safer than UI-only disabling. The product choice between unconditional blocking and confirmed partial delivery still requires iOS owner approval.

AGENTS.md: unclear because the file could not be read completely.

Codex review notes: model internal, reasoning high; reviewed against 171fabef24cf.

Label changes

Label changes:

add proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. Native Photos → Share Sheet proof shows the after-fix six-image warning with Send disabled and a one-image control that remains sendable.

Label justifications:

P1: The PR fixes deterministic silent omission in a user-facing iOS sharing workflow where the agent can receive materially incomplete input.
merge-risk: 🚨 compatibility: Existing over-limit or mixed-content shares that previously sent a supported subset will instead be blocked and require user action.
merge-risk: 🚨 message-delivery: The selected policy directly controls whether a share is delivered at all when any selected attachment is unsupported or omitted.
rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (screenshot): Native Photos → Share Sheet proof shows the after-fix six-image warning with Send disabled and a one-image control that remains sendable.
proof: sufficient: Contributor real behavior proof is sufficient. Native Photos → Share Sheet proof shows the after-fix six-image warning with Send disabled and a one-image control that remains sendable.
proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. Native Photos → Share Sheet proof shows the after-fix six-image warning with Send disabled and a one-image control that remains sendable.

Evidence reviewed

PR surface:

Other +185. Total +185 across 5 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	0	0	0	0
Tests	0	0	0	0
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	5	199	14	+185
Total	5	199	14	+185

What I checked:

Current-main omission path: Current main caps accepted image attachments at three and sends only that accepted array, so additional selected images do not reach the gateway payload. citeturn1view0. (apps/ios/ShareExtension/ShareViewController.swift:393, 171fabef24cf)
Send-path boundary: Current main proceeds with pendingAttachments and success handling without guarding against over-limit or unsupported selected items; this branch adds a controller-owned block reason checked by the UI and send path. (apps/ios/ShareExtension/ShareViewController.swift:266, 171fabef24cf)
Proposed classification logic: The branch adds a summary type that distinguishes selected and accepted images plus unsupported video, file, and unknown-provider counts, while retaining image-processing failure precedence. (apps/ios/ShareExtension/ShareAttachmentSummary.swift:1, bb622b830ac3)
Focused regression coverage: The added tests cover the normal no-omission case, six-to-three image truncation, unsupported-item messaging, failed provider loads, and image-processing precedence. (apps/ios/Tests/Logic/ShareAttachmentSummaryTests.swift:1, bb622b830ac3)
Real behavior proof: The linked predecessor proof used the native Photos → Share Sheet path: six selected images displayed the omission warning with Send disabled, while a one-image control remained sendable; this PR explicitly preserves that implementation and proof. (bb622b830ac3)
Owner routing: Repository contribution guidance identifies Mariano Belinky and Nimrod Gutman with the iOS app, making them the strongest reviewers for the delivery-policy choice. citeturn9search0. (CONTRIBUTING.md, 171fabef24cf)

Likely related people:

mbelinky: Repository contribution guidance assigns Mariano Belinky to the iOS app, making him the strongest route for native share-extension delivery semantics. (role: iOS feature owner; confidence: high; files: apps/ios/ShareExtension/ShareViewController.swift, apps/ios/ShareExtension/ShareAttachmentSummary.swift)
ngutman: Repository contribution guidance assigns Nimrod Gutman to the iOS and macOS apps, making him a strong secondary reviewer for native behavior and release impact. (role: adjacent iOS owner; confidence: high; files: apps/ios/ShareExtension/ShareViewController.swift, apps/ios/project.yml)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Review history (2 earlier review cycles)

reviewed 2026-07-13T17:28:41.347Z sha bb622b8 :: needs maintainer review before merge. :: none
reviewed 2026-07-13T17:52:11.692Z sha bb622b8 :: needs maintainer review before merge. :: none

steipete · 2026-07-13T18:14:16Z

Land-ready verification for bb622b830ac30af23fef1c577cc334015ab50b9a:

Repo-native review artifacts validate with zero findings; fresh autoreview reports no accepted/actionable findings.
Real-device proof: iPhone 17 Pro / iOS 26.2 Photos share sheet blocks a six-image partial share and keeps a one-image control sendable: fix(ios): block omitted share attachments #104842 (comment)
Exact-head CI: https://github.com/openclaw/openclaw/actions/runs/29263278311 — macos-swift and the relevant Node/Linux lanes passed.
check-dependencies is unrelated baseline dead-export drift introduced by refactor(ui): unified settings design language across all Control UI settings surfaces #106470. ios-build and the iOS scan jobs remain queued on Apple runner capacity.

Landing override: CI completion explicitly waived. Known proof gap: no completed hosted ios-build for this exact head.

steipete · 2026-07-13T18:14:47Z

Merged via maintainer CI waiver.

Prepared head: bb622b830ac30af23fef1c577cc334015ab50b9a
Landed commit: 6e8df6c0457fc347e9b68a2f7505b953af52082b

…law#106513) * fix(ios): block omitted share attachments Co-authored-by: jincheng-xydt <[email protected]> * chore: keep release note in PR body --------- Co-authored-by: jincheng-xydt <[email protected]>

openclaw-barnacle Bot added app: ios App: ios size: M maintainer Maintainer-authored PR labels Jul 13, 2026

steipete force-pushed the codex/ios-share-omission-104842 branch from f2a3cec to c7bc3df Compare July 13, 2026 15:39

steipete and others added 2 commits July 13, 2026 08:41

fix(ios): block omitted share attachments

bad9e02

Co-authored-by: jincheng-xydt <[email protected]>

chore: keep release note in PR body

bb622b8

steipete force-pushed the codex/ios-share-omission-104842 branch from c7bc3df to bb622b8 Compare July 13, 2026 15:41

clawsweeper Bot added proof: 📸 screenshot Contributor real behavior proof includes screenshot evidence. and removed proof: 📸 screenshot Contributor real behavior proof includes screenshot evidence. labels Jul 13, 2026

steipete merged commit 6e8df6c into main Jul 13, 2026
141 of 148 checks passed

steipete deleted the codex/ios-share-omission-104842 branch July 13, 2026 18:14

steipete mentioned this pull request Jul 13, 2026

fix(ios): block omitted share attachments #104842

Closed

github-actions Bot mentioned this pull request Jul 13, 2026

📡 Upstream Digest — 2026-07-13 19:14 UTC curtismercier/openclaw-mods#1283

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(ios): block incomplete shares when attachments are omitted#106513

fix(ios): block incomplete shares when attachments are omitted#106513
steipete merged 2 commits into
mainfrom
codex/ios-share-omission-104842

steipete commented Jul 13, 2026

Uh oh!

clawsweeper Bot commented Jul 13, 2026 •

edited

Loading

Uh oh!

steipete commented Jul 13, 2026

Uh oh!

Uh oh!

steipete commented Jul 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

steipete commented Jul 13, 2026

What Problem This Solves

Why This Change Was Made

User Impact

Evidence

Uh oh!

clawsweeper Bot commented Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

steipete commented Jul 13, 2026

Uh oh!

Uh oh!

steipete commented Jul 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

clawsweeper Bot commented Jul 13, 2026 •

edited

Loading