Custom menu-bar reset tokens do not schedule their own refreshes

[vincent-peng]

Summary

Custom menu-bar layouts can render Reset Countdown and Reset Time, but their refresh scheduling is still derived from legacy display-mode settings. With a custom reset layout and the default legacy Percent mode, the displayed reset value can stop updating.

Source path

• MenuBarLayoutRenderer renders both reset tokens from the active provider reset date.
• StatusItemController+CountdownRefresh schedules refresh work only when legacy brand/percent display settings select reset-time behavior.
• The custom-layout path recognises Reset Countdown for displayed dates, but the surrounding legacy-mode gate prevents scheduling; Reset Time is not included in that displayed-reset-token check.

Reproduction

1. Save a custom menu-bar layout containing Reset Countdown or Reset Time.
2. Leave the legacy menu-bar display mode at its default Percent value.
3. Observe the label across a minute boundary, or until the reset boundary is crossed.

Expected behavior

A reset token in the active custom layout should refresh independently of unused legacy display-mode settings.

Suggested acceptance criteria

• Derive reset refresh scheduling from active custom-layout tokens when a custom layout is in use.
• Cover custom Reset Countdown and Reset Time layouts while the legacy display mode remains Percent.
• Cover the absolute-reset boundary refresh as well as countdown updates.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 18, 2026, 10:04 AM ET / 14:04 UTC.

Summary
This is a well-scoped menu-bar correctness report with a concrete source-level explanation and no linked fix in the supplied discussion. It should remain open for a focused repair that makes custom reset-token scheduling depend on the active layout rather than unused legacy display settings.

Reproducibility: yes. at source level with medium confidence: configure a custom layout containing either reset token while legacy display mode remains Percent, then cross a minute or reset boundary. A focused scheduler/layout test should confirm the behavior without live provider or Keychain access.

Next step
The report names a narrow scheduler/layout consistency bug with likely implementation files and a stable non-AppKit validation path; no product or security decision is needed.

Review details

Best possible solution:

Unify the decision that a custom layout displays a reset-derived value with refresh scheduling, so active Reset Countdown and Reset Time tokens schedule required minute and reset-boundary refreshes regardless of legacy display mode; add focused non-AppKit regression coverage.

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

Yes, at source level with medium confidence: configure a custom layout containing either reset token while legacy display mode remains Percent, then cross a minute or reset boundary. A focused scheduler/layout test should confirm the behavior without live provider or Keychain access.

Is this the best way to solve the issue?

Yes. Sharing or extending the active-layout reset-token predicate into refresh scheduling is the narrowest maintainable fix; changing legacy display defaults would retain conflicting sources of truth instead of fixing them.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The reported predicate and test seam need a direct current-main source check before implementation because this review environment could not execute read-only checkout commands.

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

Label changes

Label changes:

• add P2: A stale menu-bar reset value is a bounded correctness defect without evidence of crash, data loss, or authentication impact.
• add impact:ux-friction: Users who choose a custom reset layout can receive stale countdown or reset-time information and must work around the mismatch through unrelated legacy settings.
• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: Current issue advisory state selects this label.

Label justifications:

• P2: A stale menu-bar reset value is a bounded correctness defect without evidence of crash, data loss, or authentication impact.
• impact:ux-friction: Users who choose a custom reset layout can receive stale countdown or reset-time information and must work around the mismatch through unrelated legacy settings.

Evidence reviewed

Acceptance criteria:

• swift test --filter MenuBarLayout
• make test
• make check

What I checked:

• Issue source trace: The report identifies a mismatch: MenuBarLayoutRenderer renders custom reset tokens from the active provider reset date, while StatusItemController+CountdownRefresh derives scheduling from legacy display settings and reportedly omits Reset Time from the custom displayed-reset check. (Sources/CodexBar/StatusItemController+CountdownRefresh.swift, 412c01edfb97)
• Focused test policy: The repository AGENTS.md calls for focused XCTest coverage for new logic and prefers stable state/model seams over live AppKit menu tests, which fits a scheduler/layout regression test. (AGENTS.md, 2ccb4525687c)
• No linked implementation: The supplied issue timeline contains only the ClawSweeper comment and no closing or referenced pull request, so there is no open implementation candidate to supersede this report.

Likely related people:

• steipete: Repository ownership is the best available routing signal for this menu-bar behavior; file-level git history could not be collected because the read-only shell did not start. (role: likely routing owner; confidence: low; files: Sources/CodexBar/StatusItemController+CountdownRefresh.swift, Sources/CodexBar/MenuBarLayoutRenderer.swift)

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.

[clawsweeper]

🦞🔧
ClawSweeper is automatically building this issue.

The issue review finished and no active implementation pull request was found.

Automatic implementation progress:

• State: Queued
• Detail: Review complete; no active implementation PR was found. The Codex implementation worker is queued.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/29649522337
• Updated: 2026-07-18T15:13:01.639Z
• Opt out: add clawsweeper:manual-only or clawsweeper:human-review.

[steipete]

Fixed by #2303, merged as 61b9948f1e36d12a8fa32a9ac4a9b566c7569057.

Custom countdown tokens now schedule existing minute-boundary refreshes, while absolute-reset tokens schedule only local-midnight/reset boundaries. The implementation keeps one cancel-and-replace refresh task, so there is no per-second timer. Focused coverage passed 12/12 tests, make check passed, final autoreview found no issues, and exact-head CI run 29658773085 is fully green on its first attempt.