fix(ios): keep While Using selected after approval by steipete · Pull Request #100512 · openclaw/openclaw

steipete · 2026-07-06T00:55:05Z

Regression from #99247.

What Problem This Solves

Fixes an issue where users selecting Location → While Using on iOS would approve the system location prompt, but the OpenClaw setting would snap back to Off while the prompt was still resolving.

Why This Change Was Made

The initial Core Location request now installs its waiter before showing the system prompt and refuses to complete while authorization remains .notDetermined. The existing bounded fallback remains for the separate Always-upgrade flow, where iOS can legitimately suppress a second prompt.

User Impact

After approving the first While Using prompt, the setting remains selected immediately and after relaunch instead of reverting to Off.

Evidence

Added a unit regression test for pending .notDetermined callbacks.
Added an iOS UI regression test that holds the system alert open for three seconds, approves While Using, and verifies the selection immediately and after relaunch.
xcodebuild build-for-testing -project apps/ios/OpenClaw.xcodeproj -scheme OpenClawUITests -destination 'platform=iOS Simulator,id=10B67EA9-8307-421B-8E49-C2778B3BB9E0' -derivedDataPath /tmp/openclaw-ios-location-derived-local -disableAutomaticPackageResolution — passed; app and UI test targets compile.
pnpm check:changed on Blacksmith Testbox tbx_01kwtbye96qq4x8g11tyt37v98 — passed.
Fresh local autoreview — clean.
Live XCTest execution was attempted on three simulators, but this host's Xcode runner never materialized its install/launch workers; the test build itself succeeds.

clawsweeper · 2026-07-06T01:09:04Z

Codex review: needs real behavior proof before merge. Reviewed July 5, 2026, 10:02 PM ET / 02:02 UTC.

Summary
The branch changes iOS Core Location authorization waiting so the initial While Using request installs its continuation before prompting, filters .notDetermined, and adds unit/UI regression coverage.

PR surface: Other +94. Total +94 across 3 files.

Reproducibility: yes. source-reproducible: current main can complete the authorization wait with .notDetermined, which requestLocationPermissions treats as false and the Settings picker then reverts. I did not establish a live simulator/device reproduction.

Review metrics: none identified.

Merge readiness
Overall: 🦪 silver shellfish
Proof: 🦪 silver shellfish
Patch quality: 🐚 platinum hermit
Result: blocked until real behavior proof from a real setup is added.

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

Rank-up moves:

Attach redacted exact-head simulator or device proof showing While Using stays selected during prompt approval and after relaunch.

Proof guidance:

[P1] Needs real behavior proof before merge: Only unit/UI test, build, and check evidence is present; add redacted exact-head simulator/device screenshots, recording, xcresult screenshots, terminal output, or logs showing the real prompt path, then update the PR body to trigger re-review.

Risk before merge

[P1] No exact-head real simulator/device proof is attached for the iOS permission prompt path; the PR body says live XCTest execution was attempted but did not run.

Maintainer options:

Decide the mitigation before merge
Land the iOS waiter fix only after redacted exact-head simulator or device proof shows While Using stays selected during prompt approval and after relaunch, or after a maintainer explicitly overrides that proof gap.
Pause or close
Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

[P1] Protected maintainer labeling plus the missing exact-head iOS prompt proof make this a human merge-review or proof-override decision; no automated code repair is identified.

Maintainer decision needed

Question: Should this PR wait for exact-head iOS simulator/device proof of the While Using permission prompt path, or should a maintainer explicitly override the proof gap?
Rationale: The source path and tests support the fix, but this external PR changes a real iOS permission flow and the attached evidence does not show the exact-head prompt behavior running in a real setup.
Likely owner: steipete — He has the strongest current-main history on the iOS location permission path and merged the related permission-flow PR.
Options:
- Require exact-head prompt proof (recommended): Wait for redacted simulator/device screenshots, recording, xcresult screenshots, terminal output, or logs showing While Using stays selected through approval and relaunch.
- Override the proof gap: A maintainer can explicitly accept the source and test evidence without live prompt execution if they are comfortable owning the release risk.

Security
Cleared: Cleared: the current diff only changes iOS authorization waiting and tests, with no new dependencies, secrets, workflows, package sources, or permission declarations.

Review details

Best possible solution:

Land the iOS waiter fix only after redacted exact-head simulator or device proof shows While Using stays selected during prompt approval and after relaunch, or after a maintainer explicitly overrides that proof gap.

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

Yes, source-reproducible: current main can complete the authorization wait with .notDetermined, which requestLocationPermissions treats as false and the Settings picker then reverts. I did not establish a live simulator/device reproduction.

Is this the best way to solve the issue?

Yes for the code shape: installing the waiter before requesting and filtering .notDetermined only for the initial request is the narrow owner-boundary fix. Merge readiness still depends on real prompt proof or an explicit maintainer override.

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

P1: This is a recent user-facing iOS permission regression where approving While Using can leave the OpenClaw setting reverted to Off.
rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🐚 platinum hermit.
status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: Only unit/UI test, build, and check evidence is present; add redacted exact-head simulator/device screenshots, recording, xcresult screenshots, terminal output, or logs showing the real prompt path, then update the PR body to trigger re-review.

Evidence reviewed

PR surface:

Other +94. Total +94 across 3 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	3	100	6	+94
Total	3	100	6	+94

What I checked:

Root policy read: Root AGENTS.md was read in full and applied to the PR review, especially the proof, protected-label, changelog, and security-review requirements. (AGENTS.md:1, d095f4755339)
Scoped iOS policy read: The iOS scoped AGENTS.md was read in full; it adds iOS release guardrails and did not conflict with the proof-focused review result. (apps/ios/AGENTS.md:1, d095f4755339)
Current-main regression path: On current origin/main, ensureAuthorization(mode:) requests When In Use before awaiting and later finishes the wait with the manager's current status, so .notDetermined can flow back to the caller. (apps/ios/Sources/Location/LocationService.swift:40, d095f4755339)
Settings revert path: The Settings action reverts locationModeRaw to the previous mode when requestLocationPermissions returns false. (apps/ios/Sources/Design/SettingsProTabActions.swift:544, d095f4755339)
Authorization result contract: NodeAppModel.requestLocationPermissions returns false for default statuses, so a .notDetermined result drives the Settings revert branch. (apps/ios/Sources/Model/NodeAppModel.swift:952, d095f4755339)
PR fix shape: The PR head installs the authorization waiter before calling requestWhenInUseAuthorization() and requires a determined status for the initial request path. (apps/ios/Sources/Location/LocationService.swift:41, 290c6812b7c5)

Likely related people:

steipete: Symbol history shows Peter Steinberger added the original iOS node location service, current blame/history routes the waiter path through his commits, and he merged the related iOS permission-flow PR. (role: introduced behavior and recent area merger; confidence: high; commits: e1dd764504b1, 671c31507242, 65aec9644069; files: apps/ios/Sources/Location/LocationService.swift, apps/ios/Sources/Design/SettingsProTabActions.swift, apps/ios/UITests/OpenClawSnapshotUITests.swift)
PollyBot13: PollyBot13 authored the merged iOS Location Always permission-flow PR that added the adjacent permission summary and waiter behavior this PR narrows. (role: recent feature contributor; confidence: medium; commits: 671c31507242; files: apps/ios/Sources/Location/LocationService.swift, apps/ios/Sources/Design/SettingsProTabActions.swift, apps/ios/Tests/LocationPermissionSummaryTests.swift)
ngutman: History shows Nimrod Gutman restored the significant-location monitor and touched the same iOS location service area, making him an adjacent routing candidate if the fix interacts with background location behavior. (role: adjacent location contributor; confidence: medium; commits: 5a39e13c929c; files: apps/ios/Sources/Location/LocationService.swift, apps/ios/Sources/Location/SignificantLocationMonitor.swift, apps/ios/Sources/Info.plist)

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-06T01:14:32.507Z sha 963cc7e :: needs real behavior proof before merge. :: [P3] Remove the normal-PR changelog entry
reviewed 2026-07-06T01:38:44.437Z sha c359f89 :: needs real behavior proof before merge. :: none

steipete · 2026-07-06T02:05:33Z

Merged via squash.

Prepared head SHA: 290c6812b7c58973c0e79cc6c30706c7914099d0
Landed commit: d2d5911c3296dfa3cf368eff1acdd1f1ede844d7

* fix(ios): preserve initial location permission selection * chore: keep iOS location fix independent

openclaw-barnacle Bot added app: ios App: ios size: S maintainer Maintainer-authored PR gateway Gateway runtime size: M and removed size: S labels Jul 6, 2026

steipete force-pushed the codex/ios-location-authorization branch from d9c00b9 to c359f89 Compare July 6, 2026 01:26

openclaw-barnacle Bot removed docs Improvements or additions to documentation channel: discord Channel integration: discord channel: imessage Channel integration: imessage channel: mattermost Channel integration: mattermost labels Jul 6, 2026

openclaw-barnacle Bot added the size: S label Jul 6, 2026

steipete added 2 commits July 5, 2026 18:45

fix(ios): preserve initial location permission selection

6814734

chore: keep iOS location fix independent

290c681

steipete force-pushed the codex/ios-location-authorization branch from 2a5e13b to 290c681 Compare July 6, 2026 01:47

steipete merged commit d2d5911 into main Jul 6, 2026
47 of 51 checks passed

steipete deleted the codex/ios-location-authorization branch July 6, 2026 02:05

Haderach-Ram mentioned this pull request Jul 6, 2026

Ecosystem Digest — 2026-07-06 Haderach-Ram/openclaw-radar#70

Open

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

📡 Upstream Digest — 2026-07-06 02:26 UTC curtismercier/openclaw-mods#1220

Open

github-actions Bot pushed a commit to Desicool/openclaw that referenced this pull request Jul 6, 2026

fix(ios): keep While Using selected after approval (openclaw#100512)

b041aa4

* fix(ios): preserve initial location permission selection * chore: keep iOS location fix independent

giodl73-repo pushed a commit to giodl73-repo/openclaw that referenced this pull request Jul 8, 2026

fix(ios): keep While Using selected after approval (openclaw#100512)

793070f

* fix(ios): preserve initial location permission selection * chore: keep iOS location fix independent

clawsweeper Bot mentioned this pull request Jul 9, 2026

fix: coalesce iOS location requests safely #103023

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(ios): keep While Using selected after approval#100512

fix(ios): keep While Using selected after approval#100512
steipete merged 2 commits into
mainfrom
codex/ios-location-authorization

steipete commented Jul 6, 2026

Uh oh!

clawsweeper Bot commented Jul 6, 2026 •

edited

Loading

Uh oh!

Uh oh!

steipete commented Jul 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

steipete commented Jul 6, 2026

What Problem This Solves

Why This Change Was Made

User Impact

Evidence

Uh oh!

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

Uh oh!

Uh oh!

Uh oh!

steipete commented Jul 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

clawsweeper Bot commented Jul 6, 2026 •

edited

Loading