feat: add refresh-on-open setting

[dstier-git]

Fixes #1732

Summary

• Add a General preference to refresh enabled providers whenever the menu opens.
• Persist the new setting with a default of off, preserving the existing stale/missing-only menu refresh behavior unless enabled.
• When enabled, refresh all background-work providers concurrently in the background interaction context while keeping OpenAI
  dashboard refresh deferred until menu close.
• Add localized strings and status menu tests for enabled and disabled refresh-on-open behavior.

Testing

• swift test --filter StatusMenuTests
• make check
• git diff --check
• make test

Screenshots / GIFs

Screenshot of the setting toggle

Video: opening twice with a minute between, both openings refreshed usages displayed (cut out the minute in between for video length). Wasn't able to show the clock since the expanded frame would expose my personal email address.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed June 24, 2026, 7:42 PM ET / 23:42 UTC.

Summary
Adds a default-off General preference to refresh enabled providers when the menu opens, with persisted settings, localized strings, menu scheduling changes, and status-menu tests.

Reproducibility: not applicable. as a feature PR. Current main source and tests show fresh menu opens intentionally do not refresh providers, while the branch adds an opt-in path.

Review metrics: 3 noteworthy metrics.

• Changed Surface: 27 files changed, 205 additions, 5 deletions. Most breadth is localization fan-out, while behavior is concentrated in settings and menu refresh scheduling.
• Localization Fan-Out: 21 Localizable.strings files changed. The new preference copy spans every current localization file and should be checked as part of product acceptance.
• Focused Tests: 2 menu-open behavior tests added. The PR covers both enabled opt-in behavior and the disabled default through the repository's preferred menu test seam.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #1732
Summary: This PR is the candidate implementation for the linked open feature request asking for an opt-in refresh-on-open setting.

Members:

• canonical: Feature request: refresh on-open from menu #1732 - The PR body uses closing syntax and the issue asks for the exact refresh-on-open option implemented here.
• adjacent_distinct: docs: propose predictive refresh policy #1739 - The draft RFC covers broader predictive refresh policy and does not supersede this narrow default-off setting implementation.

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:

• Get maintainer sign-off on the default-off refresh-on-open policy and provider-call tradeoff.

Risk before merge

• [P1] Maintainers still need to accept that users who enable the setting can trigger provider refresh work on every menu open, which may affect provider-call volume, responsiveness, and prompt-safety expectations.
• [P1] Current main has advanced past the PR branch base, so maintainers should review the refreshed merge result before landing even though the submitted commit is focused.

Maintainer options:

1. Accept the Opt-In Refresh Policy
   Maintainers can merge after explicitly accepting the extra refresh work and prompt-safety tradeoff for users who enable this setting.
2. Pause for Refresh Policy Direction
   If maintainers want the broader refresh policy to settle first, keep this PR open or close it in favor of a sponsored policy decision.

Next step before merge

• [P2] Maintainer product approval is needed for the default-off refresh-on-open behavior; there is no narrow automated code repair to queue.

Security
Cleared: No concrete security or supply-chain concern found; the diff changes app settings, menu refresh code, localized strings, and tests without dependency, CI, release, secret-handling, or downloaded-code changes.

Review details

Best possible solution:

Land the default-off setting only if maintainers accept the refresh-on-open policy, while preserving the existing stale/missing-only default and focused menu tests.

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

Not applicable as a feature PR. Current main source and tests show fresh menu opens intentionally do not refresh providers, while the branch adds an opt-in path.

Is this the best way to solve the issue?

Unclear until maintainer sign-off. The implementation reuses existing deferred/background refresh machinery and preserves default-off behavior, so the remaining question is product policy rather than a concrete code defect.

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

• P3: This PR is a low-urgency opt-in UX/product setting rather than an urgent regression or broken core workflow.
• merge-risk: 🚨 other: The new setting changes provider-refresh behavior for users who enable it, and CI cannot decide the product tradeoff around extra refresh work and prompt-safety expectations.
• 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 (recording): The PR body includes after-change media proof: a setting screenshot and an animated CodexBar menu recording showing the menu-open flow after enabling the feature.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes after-change media proof: a setting screenshot and an animated CodexBar menu recording showing the menu-open flow after enabling the feature.
• proof: 🎥 video: Contributor real behavior proof includes video or recording evidence. The PR body includes after-change media proof: a setting screenshot and an animated CodexBar menu recording showing the menu-open flow after enabling the feature.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was present and fully read; its guidance favored small Swift changes, focused menu tests, and avoiding live provider or Keychain-prompt validation for this review. (AGENTS.md:1, ada3660e9d61)
• Linked feature request: The PR body closes the open feature request asking for an option to refresh provider limits immediately when opening the CodexBar menu while preserving the existing refresh clock. (b1b590f6b629)
• Current main behavior: Current main only schedules menu-open refreshes for rendered providers with stale or missing data and documents menu-tracking responsiveness concerns. (Sources/CodexBar/StatusItemController+Menu.swift:1103, ada3660e9d61)
• No existing setting on main: Current main contains menu-open refresh tests and scheduling but no refreshAllProvidersOnMenuOpen or refresh_on_open setting strings, so the PR is still unique work. (ada3660e9d61)
• PR opt-in implementation: The PR reads refreshAllProvidersOnMenuOpen, switches candidates to all enabled background-work providers only when it is true, and keeps the existing stale/missing retry path when false. (Sources/CodexBar/StatusItemController+Menu.swift:1149, b1b590f6b629)
• Persisted default-off setting: The new setting is loaded from UserDefaults with a false default and written through SettingsStore without changing existing users by default. (Sources/CodexBar/SettingsStore.swift:338, b1b590f6b629)

Likely related people:

• hhh2210: Authored the merged PR that avoided redundant menu-open refreshes in the same scheduling area. (role: menu refresh behavior contributor; confidence: high; commits: d06226ec0cf4; files: Sources/CodexBar/StatusItemController+Menu.swift, Tests/CodexBarTests/StatusMenuOpenRefreshTests.swift)
• joshuavial: Authored the merged menu-open refresh delay work and large instant-open test coverage adjacent to this PR. (role: recent menu-open refresh contributor; confidence: high; commits: 3c2d53de57c1; files: Sources/CodexBar/StatusItemController+Menu.swift, Sources/CodexBar/StatusItemController+MenuInteractionRefresh.swift, Tests/CodexBarTests/StatusMenuInstantOpenTests.swift)
• steipete: Authored the older auto-refresh-on-open commit and the release-baseline lines currently blamed for scheduleOpenMenuRefresh. (role: original and release-baseline area contributor; confidence: high; commits: 26fb95b3fcb3, f380287041b8; files: Sources/CodexBar/StatusItemController+Menu.swift)
• elijahfriedman: Authored recent merged work keeping the menu open during refresh and touching adjacent persistent refresh menu behavior. (role: recent adjacent contributor; confidence: medium; commits: fb8473fe6551; files: Sources/CodexBar/StatusItemController+Menu.swift, Sources/CodexBar/StatusItemController+PersistentMenuActions.swift, Tests/CodexBarTests/StatusMenuPersistentRefreshTests.swift)
• Zihao-Qi: Authored the latest current-main refresh menu styling work in the same menu surface. (role: recent adjacent contributor; confidence: medium; commits: ada3660e9d61; files: Sources/CodexBar/StatusItemController+Menu.swift, Tests/CodexBarTests/StatusMenuPersistentRefreshTests.swift)

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.