Harden live inventory results

[jmcte]

Summary

• Bound expensive live filesystem inventory scans so Drive, Photos, and tagged-item commands return useful results instead of hanging on large local trees.
• Avoid recursive iCloud Drive container stats unless sorting by size or modified date needs them.
• Convert macOS privacy failures for SQLite-backed stores, Safari plists, and Shortcuts into explicit Full Disk Access guidance.

Governing Issue

No GitHub issue was provided; this follows the direct operator request to use live tests to make the CLI produce useful local results.

Validation

• Relevant local checks passed
  • swift test passed: 75 tests
  • /bin/zsh /private/tmp/icloud-cli-live-pass-small.zsh passed for previously hanging Drive/Photos/Tags commands and reported actionable Full Disk Access errors for protected stores
• Required PR checks are expected to satisfy CI Gate
• Skipped checks are explained below

Sensitive payload output was intentionally suppressed during the live pass. Commands that require macOS privacy access were validated by exit status and first-line stderr only.

Bootstrap Governance

• Changes are scoped to the direct operator request
• Contributor or PR guidance changes are reflected in CONTRIBUTING.md, .github/PULL_REQUEST_TEMPLATE.md, and docs/bootstrap/onboarding.md when applicable
• PR author enabled auto-merge where GitHub allows it, or GitHub plan-limit evidence/unavailable reason is recorded and the fallback merge-readiness policy applies
• No real secrets, runtime auth, or machine-local env files are committed

Flow Contract

• Owner lane: operator-requested CLI quality
• Repair owner: Codex
• Autonomy class: scoped implementation with local and live validation
• Risk class: medium-low; changes bound scan scope and improve error reporting, but Drive status counts are now intentionally capped by --limit

Flow Merge Readiness

• Every blocker has a next actor and next action
• No active blocking requested changes remain
• Non-author approval is present when required
• PR author enabled auto-merge where GitHub allows it, or recorded why it is unavailable/unsafe

Merge Automation

• PR author enabled auto-merge with gh pr merge --auto --squash, or the reason it is unavailable/unsafe is noted below

Auto-merge has not been enabled yet; this PR needs live required-check and review-state evaluation after creation.

Notes

• Focused live pass after the fix:
  • Passing: drive containers, drive status, drive errors, drive shared, drive recents, photos list, tags items
  • Still blocked by macOS privacy access: Notes, Contacts, Mail, Messages, Shortcuts, and Safari local plist reads
• The blocked commands now say to grant Full Disk Access to the calling terminal or agent process.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 09d993683e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[pheidon]

Approving as code owner requested by pheidon.

[Hermes-omt]

Requesting changes for one Drive hardening regression.

drive errors and drive shared still call listFiles(path:depth:) without passing any scan limit in ICloudDriveInventoryReader.errorFiles and sharedItems (Sources/ICloudCLICore/DriveInventory.swift:104 and Sources/ICloudCLICore/DriveInventory.swift:124). CommandRunner passes options.limit into both commands, but that limit is only applied after the recursive Int.max traversal has already completed. On a large iCloud Drive tree, these commands can still hang before returning the capped result set, which undercuts the PR's main goal of bounding expensive live inventory scans.

This is related to the earlier connector feedback, but it is not just a duplicate: the follow-up fixed the false-negative behavior by filtering before prefixing, while leaving the traversal unbounded again. drive shared has the same issue and was not covered by the original inline comments. Please add a separate scan budget or pass a bounded traversal limit before filtering, while preserving result-set limiting semantics.

Validation note: source inspection was performed at PR head 98c65bb. I could not run swift test in the local shell because swift is unavailable there, and the Hermes macOS node has Swift 6.3.2 but could not prepare the required /openclaw-data/src checkout because /openclaw-data is read-only.

[Hermes-omt]

I confirm the existing Drive blocker is still present at current PR head 98c65bb.

ICloudDriveInventoryReader.errorFiles and sharedItems still call listFiles(path:depth:) without passing a scan limit (Sources/ICloudCLICore/DriveInventory.swift:104 and Sources/ICloudCLICore/DriveInventory.swift:124). That means --limit still caps only the returned filtered result after the recursive Int.max traversal completes, so drive errors and drive shared can still hang on large iCloud Drive trees before producing the capped output.

The current tests cover listFiles(..., limit:) and the output prefix behavior for errorFiles, but they do not verify that these two commands bound the traversal before filtering. CI Gate is green, but I could not run local Swift/Xcode checks from this assigned shell because it is Linux and swift is unavailable.

Review result: existing blocker confirmed; I am not adding a separate duplicate request-changes review.

[Hermes-omt]

I confirm the existing Drive blocker is still present at current PR head 98c65bb.

ICloudDriveInventoryReader.errorFiles and sharedItems still call listFiles(path:depth:) without passing a scan limit (Sources/ICloudCLICore/DriveInventory.swift:104 and Sources/ICloudCLICore/DriveInventory.swift:124). --limit therefore caps only the filtered output after the recursive Int.max traversal has completed, so drive errors and drive shared can still hang on large iCloud Drive trees before returning useful capped results.

I did not find a separate new blocker in this pass. I also could not run local Swift/Xcode validation because the assigned shell reports Linux and swift is unavailable.

[Hermes-omt]

I confirm the existing Drive blocker remains at PR head 98c65bb.

ICloudDriveInventoryReader.errorFiles and sharedItems still call listFiles(path:depth:) without passing a traversal limit (Sources/ICloudCLICore/DriveInventory.swift:104 and Sources/ICloudCLICore/DriveInventory.swift:124). The --limit value is therefore applied only by prefix(...) after the recursive Int.max walk completes, so drive errors and drive shared can still hang on large iCloud Drive trees before returning capped output.

This is the same substantive blocker already covered by the existing Hermes request-changes review, so I am leaving this as a confirmation comment rather than adding another duplicate request-changes review. CI Gate is passing. I could not run macOS Swift validation: the macOS node has Swift 6.3.2, but the required checkout is absent there and /openclaw-data is read-only, so I could not prepare the mandated review worktree.

Review result: not ready until the existing Drive traversal blocker is fixed; I did not find a separate new blocker in this pass.

[pheidon]

Blocking on one remaining Drive status regression.

drive status now passes MetadataOptions.limit into syncStatus, and MetadataOptions defaults that value to 50. So the normal CLI path (icloud-cli drive status with no explicit --limit) only traverses the first 50 files, then renders the counts as a complete sync summary. The reader-level regression test calls syncStatus(path: nil) directly, so it does not exercise the shipped command path.

That reintroduces the earlier connector concern in a slightly different form: users can get a partial prefix count with no indication that it is sampled. Please either keep drive status uncapped by default, track whether --limit was explicitly supplied and surface sampled/truncated semantics in the output, or remove --limit from status while keeping bounded traversal for the row-returning commands (drive errors, drive shared, drive recents).

I verified at PR head 19f2ae07: CI Gate is green, the older Hermes blocker for drive errors/drive shared appears fixed by the new scanLimit/filteredDriveScanLimit path, but I could not run local Swift tests on Pheidon because Swift is not installed here.

Superseded at PR head 19f2ae0: the old Hermes blocker for drive errors and drive shared is fixed. Both paths now apply a bounded traversal limit (scanLimit / filteredDriveScanLimit) before filtering, then apply the requested result limit afterward. This dismissal is only for the stale Hermes review from 98c65bb and is not an approval of the PR; Pheidon’s separate drive status sampled-summary blocker remains active.

[Hermes-omt]

I confirm the existing Drive status blocker is still present at PR head 19f2ae07.

The shipped drive status path still uses MetadataOptions.limit, which defaults to 50, and passes it into reader.syncStatus(...). syncStatus then passes that value to listFiles(..., limit:), so the normal CLI path can still render a partial 50-file walk as a complete sync summary. The added status regression test calls reader.syncStatus(path: nil) directly, so it bypasses the shipped default-limit path and does not cover this behavior.

This is the same substantive blocker already covered by the active Pheidon requested-changes review, so I am leaving a confirmation comment rather than duplicating the full request-changes review. gitcrawl sync completed for PR #86, CI Gate is green, and the older drive errors / drive shared traversal issue appears fixed by the new scan-limit path. I could not run Swift/Xcode validation from this assigned shell because it is Linux and swift is not installed.

Review result: not ready until the existing drive status summary/truncation semantics are fixed; no separate new blocker found in this pass.

[Hermes-omt]

I confirm the existing Drive status blocker is still present at PR head 19f2ae07.

The shipped drive status path still passes MetadataOptions.limit into reader.syncStatus(...), and MetadataOptions defaults that value to 50. syncStatus then passes that limit into listFiles, so the normal CLI path can still render a partial 50-file walk as a complete sync summary. The reader-level regression test calls syncStatus(path: nil) directly, so it does not cover the shipped default-limit command path.

This is the same substantive blocker already covered by the active requested-changes review, so I am leaving a confirmation comment rather than duplicating the full request. gitcrawl sync completed for PR #86, CI Gate is green, git diff --check main...HEAD passed, and the older drive errors / drive shared traversal issue appears addressed by the separate scan-limit path. I could not run Swift/Xcode validation because the assigned shell reports Linux and has no swift or xcodebuild installed.

Review result: not ready until the existing drive status summary/truncation semantics are fixed; no separate new blocker found in this pass.

[Hermes-omt]

I confirm the existing drive status blocker is still present at PR head 19f2ae07.

Fresh source inspection shows the shipped path still defaults MetadataOptions.limit to 50 (Sources/ICloudCLICore/CommandLine.swift:469), passes that value through CommandRunner.driveStatus (Sources/ICloudCLICore/CommandRunner.swift:201), and then syncStatus forwards it into listFiles(..., limit:) before rendering aggregate counts (Sources/ICloudCLICore/DriveInventory.swift:91). That means a normal icloud-cli drive status can still report a partial 50-file traversal as a complete sync summary.

This is the same substantive blocker already covered by the active requested-changes review, so I am not duplicating it with another request-changes review. gitcrawl sync completed for PR #86, CI Gate is green, git diff --check origin/main...HEAD passed, and the older drive errors / drive shared traversal issue appears addressed by the new scanLimit / filteredDriveScanLimit path. I could not run Swift/Xcode validation because the assigned shell is Linux and has no swift or xcodebuild installed.

Review result: not ready until the existing drive status summary/truncation semantics are fixed; no separate new blocker found in this pass.

[pheidon]

Approving after re-checking the active Drive status blocker at PR head a365834.

The shipped drive status path now calls reader.syncStatus(path: options.path) without forwarding MetadataOptions.limit, and syncStatus defaults its traversal limit to nil, so the normal CLI path no longer reports a default 50-file prefix as a complete aggregate summary. The new harness coverage also exercises icloud-cli drive status --limit 1 and still expects full downloaded/error counts, which covers the command path that the previous reader-level test missed.

CI Gate is green, git diff --check origin/main...HEAD passes, and the older drive errors / drive shared traversal blocker remains addressed by the separate scan-limit path. I could not run local Swift tests on Pheidon because Swift is not installed here, so this approval is based on source inspection plus the passing GitHub CI run.

[pheidon]

Approving after re-checking the active blocker. The drive status path now avoids the default 50-file traversal cap, the older bounded-scan regressions are addressed, and CI is green.