Greptile Summary

This PR wires client-side image resize, JPEG re-encode, and EXIF/GPS metadata stripping into the chat composer attachment path by adapting the existing JPEGTranscoder (used by PhotoCapture) through a new thin ChatImageProcessor shim, moves the heavy encode work off the MainActor via a detached Task, and adds 7 unit tests covering dimensions, metadata stripping, budget compliance, alpha flattening, and a bytes-level privacy needle scan.

• The 5 MB post-check on processed in addImageAttachment is unreachable: processForUpload either throws (caught earlier) or returns data ≤ 3.5 MB, and the accompanying comment incorrectly states the processor returns a best-effort result when over budget (it throws instead).

Confidence Score: 5/5

Safe to merge; the only finding is a dead-code guard with a misleading comment — no runtime behavior is affected.

All findings are P2 (dead code / inaccurate comment). The core logic — resize, alpha flatten, metadata strip, off-MainActor encode, best-effort quality fallback — is sound and well-tested. No P0 or P1 issues found.

apps/shared/OpenClawKit/Sources/OpenClawChatUI/ChatViewModel.swift — dead 5 MB post-check with inaccurate comment at line 1160.

This is a comment left during a code review.
Path: apps/shared/OpenClawKit/Sources/OpenClawChatUI/ChatViewModel.swift
Line: 1160-1166

Comment:
**5 MB post-check is dead code**

`processForUpload` either throws `ProcessError.encodeFailed` (caught by the `do/catch` block above, which returns early) or returns data guaranteed to be ≤ `ChatImageProcessor.maxPayloadBytes` (3.5 MB). There is no code path where it returns data between 3.5 MB and 5 MB, so this guard is unreachable.

The comment "the processor returns its lowest-quality pass even if budget couldn't be met" is also inaccurate — `JPEGTranscoder.transcodeToJPEG` throws `sizeLimitExceeded` when the budget is not met, and that error propagates as `ProcessError.encodeFailed` before this check is ever reached.

Consider either removing the check (since it is provably dead) or updating the comment to accurately describe the control flow, so future maintainers don't assume this gate is active.

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

_{Reviews (2): Last reviewed commit: "feat(chat): inline image resize + EXIF s..." | Re-trigger Greptile}

Codex review: needs real behavior proof before merge.

Summary
The PR adds an iOS/OpenClawKit chat image preprocessing path that resizes and JPEG re-encodes attachments through JPEGTranscoder, strips source metadata, adds tests and a changelog entry, and carries unrelated Settings/Onboarding setup-code changes.

Reproducibility: yes. Source inspection on current main gives a high-confidence path: an iOS chat image Data payload over 5,000,000 bytes is rejected before resize, and accepted attachment bytes are base64-encoded directly from the view model.

Real behavior proof
Needs stronger real behavior proof before merge: Older terminal proof shows real iPhone/exiftool results for head 5ae00595, but latest head c881fc1 has no current-head camera-roll-to-receiver proof in the PR body or comments. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, ask a maintainer to comment @clawsweeper re-review.

Next step before merge
External PR needs contributor current-head real behavior proof plus maintainer review after the Settings parser regression and unrelated drift are cleaned up; automation cannot provide the contributor’s device proof.

Security
Cleared: No concrete security or supply-chain regression was found in the diff; the privacy hardening still needs current-head real behavior proof.

Review findings

• [P2] Keep setup input parsing on the broad parser — apps/ios/Sources/Settings/SettingsTab.swift:829

Thanks for the deep review. Two notes:

1. Heads-up on snapshot freshness. This review was made against 3f780bb27da1 and the current PR head is now a2497a8fe281d4aca2ab1063d6b7a8418a8f8b20. The "test file claimed in PR body but not in files API" finding was a snapshot artifact — Tests/OpenClawKitTests/ChatImageProcessorTests.swift has been in the PR head since the initial filing (1eaeeae782). It's now the third file in gh api repos/openclaw/openclaw/pulls/73710/files. Same story for addImageAttachment wiring — OpenClawChatViewModel.addImageAttachment is modified in this PR to invoke ChatImageProcessor.processForUpload on a detached Task off the MainActor, with the 5 MB hard gate kept as the final safety net.

2. Acted on the consolidation recommendation. You're right that a chat-specific re-implementation of ImageIO logic alongside an existing JPEGTranscoder is wrong shape. As of a2497a8fe281d4aca2ab1063d6b7a8418a8f8b20, ChatImageProcessor is now a ~70-line policy adapter that delegates to JPEGTranscoder.transcodeToJPEG, mapping JPEGTranscodeError to a smaller chat-facing ProcessError surface. Net diff dropped ~180 lines.

While doing the consolidation I added one strictly-additive correctness fix to JPEGTranscoder itself: alpha flattening against opaque white before each encode pass. Without this, JPEG-encoding a source with alpha (PNG screenshot, HEIC with transparent UI overlay) composites against black via ImageIO's default. Sources with no alpha (the camera-capture path) skip the flatten step entirely, so PhotoCapture is unaffected; existing JPEGTranscoderTests (4 tests) continue to pass.

Re: the EXIF/orientation contract — the privacy contract is "no source-derived sensitive values survive into the output bytes," verified by test_outputContainsNoLeakedSensitiveStrings which scans the raw output for planted needle strings ("Leaky Lens", "LeakCorp", "Privacy-Leaker", a date). ImageIO does still emit a minimal format-default APP1 EXIF segment (orientation/version, no source data) on JPEG output regardless of input properties — discovered while writing the bytes-level test. Documented in the encoder doc comment.

PR body updated to match the current shape.

Status update — marking back to Draft

I want to be straight with reviewers: this PR isn't ready yet, and an earlier revision of the PR body overclaimed the verification I'd actually done. Apologies for the noise.

Where it actually stands:

• ✅ Code change is in and unit tests pass on macOS via swift test against apps/shared/OpenClawKit/.
• ✅ Greptile and GitHub Codex review feedback addressed in code.
• ❌ The post-review code (current head) has not yet been verified on a real iPhone. I tried to produce a Debug IPA on the maintainer's local rig tonight; the iOS app archive failed for reasons unrelated to this PR (missing upstream symbols on the feature branch — branch base is stale). No signed IPA, no on-device test.
• 🔄 Plan: rebase the branch onto current main, rebuild the IPA, run the test plan on a physical device, then attach before/after screenshots and re-request review. Will move back to "Ready for review" only after that.

Marking as Draft so this doesn't sit in a maintainer's queue while it's still in flux. Sorry for the back-and-forth.

Codex / Greptile bots — thanks for the read.

Closing the loop with on-device evidence from 2026-04-29 ~04:43 CEST. Built a Debug IPA from the rebased branch (head 5ae00595), installed via OTA on a real iPhone running iOS 26, and sent 4 fresh JPEGs straight from the camera roll through the chat composer to the OpenClaw inbound channel. On the receiving side (so what actually traveled in the attachment bytes, not what the sender thinks it sent):

$ for f in photo-31FF6848*.jpg photo-A68FEFA5*.jpg \
           photo-20D41B15*.jpg photo-F8C37234*.jpg; do
    sips -g pixelWidth -g pixelHeight "$f" | grep pixel | awk '{print $2}'
    exiftool -s -GPS:all -Make -Model -DateTimeOriginal -Software "$f"
  done

photo-31FF6848…jpg  1600×2133   2227 KB   exif=''
photo-A68FEFA5…jpg  1600×2133   2052 KB   exif=''
photo-20D41B15…jpg  1600×2133   2113 KB   exif=''
photo-F8C37234…jpg  1600×2133   1964 KB   exif=''

All four:

• Long edge clamped to 1600 px.
• Payload ≤ 2.3 MB (well under the 3.5 MB cap).
• exiftool -GPS:all -Make -Model -DateTimeOriginal -Software returns empty for every file — none of the source-derived sensitive EXIF made it onto the wire.

That's the privacy promise actually shipping, verified end-to-end on a real device, on real camera-roll photos (not synthetic test fixtures). The 7 unit tests in ChatImageProcessorTests cover the same contract programmatically — including a raw-bytes scan against planted needles ("Leaky Lens", "LeakCorp", "Privacy-Leaker", ISO date string) so the assertion isn't "the EXIF parser sees nothing", it's "those bytes are not in the file at all".

The Codex feedback to consolidate the second ImageIO path onto JPEGTranscoder was the right call — the alpha-flatten step now lives in one place and PhotoCapture's no-alpha source path is unaffected (the flatten branch only runs on inputs with an alpha channel).

Force-push of the rebased branch pending René's morning sign-off (no surprise force-pushes to the fork). Updated PR body covers this evidence; will move to Ready-for-review together with #73711 once René confirms the round-2 device install is good.

Pushed rebased branch onto latest upstream/main (head 5ae00595). Marked Ready-for-review.

End-to-end verified on iPhone (iOS 26) again post-rebase: 16 distinct camera-roll JPEGs across two send sessions, all clamped to ≤1600 px width, all under 600 KB, exiftool -GPS:all -Make -Model -DateTimeOriginal -Software returns empty for every file. SwiftFormat lint via xcodebuild archive path passes (the --unexclude set covering OpenClawKit).

Diff vs the previous PR head: rebase-only conflict resolution + cosmetic SwiftFormat fixes the lint pass surfaced (elseOnSameLine, wrapMultilineStatementBraces, docComments). Zero functional change to the resize / EXIF strip / alpha-flatten logic.

I might soon lose access to corp AI, and wanted this for myself and thought this was great for the community. I haven't been able to test this on android, since I don't have an android phone. So I need to rely on the emulator tests.

Trying to address this further in #67031. The PR works (on my phone), but needs to be configurable.

Closing this as superseded by the focused maintainer replacement that has now landed on main: #81608 (merge commit https://github.com/openclaw/openclaw/commit/faa443a45220ec2df124008cd805e9af99f461eb).\n\nThe landed patch keeps the same core fix direction for #68524: iOS chat PhotosPicker images are processed through before staging/sending, capped to a JPEG upload budget, and covered by focused / tests. It intentionally leaves the unrelated Settings/Onboarding drift from this PR out of the replacement branch.\n\nThanks for the original implementation and device proof; it was useful context for the final scoped fix.

Correction to the close note above: shell interpolation stripped the inline code identifiers.

Closing this as superseded by the focused maintainer replacement that has now landed on main: #81608 (merge commit faa443a).

The landed patch keeps the same core fix direction for #68524: iOS chat PhotosPicker images are processed through JPEGTranscoder before staging/sending, capped to a JPEG upload budget, and covered by focused ChatImageProcessor / ChatViewModelAttachmentTests tests. It intentionally leaves the unrelated Settings/Onboarding drift from this PR out of the replacement branch.

Thanks for the original implementation and device proof; it was useful context for the final scoped fix.