Feature request: Rotate menu bar display modes periodically

[JAEKWANG97]

Problem

CodexBar currently lets users choose a single menu bar display mode:

• Percent
• Pace
• Both
• Reset Time

Each mode provides useful information, but checking another value requires opening Settings and changing the display mode. The Both mode helps for Percent and Pace, but it makes the menu bar item wider and still does not include Reset Time.

Proposal

Add an optional rotation mode that periodically cycles through the existing display modes in the same menu bar item.

For example:

Percent → Pace → Reset Time → Percent

This would make it possible to monitor different aspects of the selected provider while keeping the menu bar compact.

Suggested behavior

• Disabled by default
• Rotate through Percent, Pace, and Reset Time
• Allow users to select which display modes participate in the rotation
• Provide a configurable interval, such as 5, 10, or 30 seconds
• Keep the currently selected provider and usage window unchanged
• Skip a mode when its data is unavailable, such as Pace or Reset Time
• Pause rotation while the menu is open
• Reset the rotation timer after the user manually changes the display mode

Use case

I want to see the remaining percentage, usage pace, and reset time for the same provider without displaying all values at once or repeatedly changing the Display mode setting.

Would this fit CodexBar’s menu bar UX?

[JAEKWANG97]

If this direction fits the project, I'd be happy to work on the implementation. I'd appreciate any guidance on the preferred UX or scope before I get started.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 13, 2026, 2:46 PM ET / 18:46 UTC.

Summary
This remains a valid but unsponsored product-direction request: current main supports four manually selected static display modes, while automatic cycling, interval settings, unavailable-mode skipping, and menu-open pausing are all new behavior that needs UX approval before implementation.

Reproducibility: not applicable. the issue clearly requests new optional behavior rather than reporting a failure in an established contract.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
A maintainer must choose the acceptable motion, width-stability, and configuration scope before an implementation can be safely specified.

Maintainer decision needed

• Question: Should CodexBar add automatic metric rotation to its core menu-bar UX, and if so should the first version expose full mode and interval customization?
• Rationale: The request introduces autonomous title changes and new persisted settings; source inspection can identify an implementation seam but cannot decide whether the motion, width changes, and settings complexity fit the intended product experience.
• Likely owner: steipete — The repository owner merged the adjacent display-setting features and is best positioned to decide the intended menu-bar UX boundary.
• Options:
  • Sponsor a narrow rotation mode (recommended): Add an opt-in fixed-interval rotation across available percent, pace, and reset-time states, deferring advanced customization until usage validates it.
  • Sponsor full customization: Allow users to select participating modes and an interval from the initial implementation, accepting a larger settings and validation surface.
  • Keep manual modes only: Decline automatic cycling to preserve a stable, predictable menu-bar title and avoid background timing behavior.

Review details

Best possible solution:

If maintainers sponsor the idea, introduce one shared disabled-by-default rotation policy that derives eligible states through the existing display-text seam, pauses during menu tracking, resets after manual selection, and initially keeps interval and mode-selection UX deliberately narrow.

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

Not applicable: the issue clearly requests new optional behavior rather than reporting a failure in an established contract.

Is this the best way to solve the issue?

Unclear pending product direction; if approved, a narrow shared rotation policy is safer than immediately adding independent controller timers and a large settings matrix.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Rotating values with different widths could make the menu-bar item visibly jitter unless the layout reserves stable width or uses a deliberately constrained presentation.
• Timer ownership must account for menu tracking, sleep/wake, settings changes, provider changes, and controller lifetimes to avoid multiple or stale rotations.
• Exposing both a mode-selection set and configurable interval may add disproportionate settings complexity for a compact menu-bar utility.

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

Label changes

Label changes:

• add P3: This is a speculative, disabled-by-default menu-bar ergonomics feature with no broken existing workflow.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This is a speculative, disabled-by-default menu-bar ergonomics feature with no broken existing workflow.

Evidence reviewed

What I checked:

• Current display modes are static: Current main defines percent, pace, both, and reset-time cases only; there is no rotating or timer-driven mode. (Sources/CodexBar/MenuBarDisplayMode.swift:3, c852c135e10c)
• Settings persist one selected mode: The menu-bar preferences pane presents a single display-mode picker backed by SettingsStore, so selectable rotation members and an interval would add new persisted settings and UI. (Sources/CodexBar/PreferencesMenuBarPane.swift:25, c852c135e10c)
• Existing rendering already handles unavailable metrics: MenuBarDisplayText centralizes percent, pace, both, and reset-time formatting and contains fallback behavior, making it the likely reusable seam for filtering unavailable rotation states. (Sources/CodexBar/MenuBarDisplayText.swift:30, c852c135e10c)
• Status controllers independently render the selected mode: Provider status controllers pass the stored display mode into MenuBarDisplayText; rotation would need coordinated state rather than separate timers that could drift between controllers. (Sources/CodexBar/CodexStatusController.swift:785, c852c135e10c)
• Product guidance requires feature sign-off: VISION.md describes CodexBar as a menu-bar control surface and permits small UI tweaks, but explicitly requires sign-off for new features; this request adds settings and autonomous UI behavior. (VISION.md:3, c852c135e10c)
• Adjacent display-setting provenance: The per-provider menu-bar metric preference was merged through PR 185, identifying prior ownership around compact metric-selection settings. (Sources/CodexBar/SettingsStore.swift:1, 9268c07)

Likely related people:

• steipete: Merged the per-provider menu-bar metric preference and pace-mode work and remains the strongest product-direction owner for new menu-bar UX. (role: repository owner and display-settings merger; confidence: high; commits: 9268c07, 9d56dfd; files: Sources/CodexBar/SettingsStore.swift, Sources/CodexBar/MenuBarDisplayMode.swift, Sources/CodexBar/PreferencesMenuBarPane.swift)
• HaukeSchnau: Introduced the per-provider menu-bar metric preference, an adjacent persisted setting for controlling compact menu-bar content. (role: adjacent feature contributor; confidence: medium; commits: 9ae6c5b; files: Sources/CodexBar/SettingsStore.swift, Sources/CodexBar/PreferencesMenuBarPane.swift)
• ratulsarna: Implemented pace display mode and its availability gating, which is directly relevant to deciding when a rotating mode should be skipped. (role: display-mode contributor; confidence: medium; commits: 20eea18; files: Sources/CodexBar/MenuBarDisplayMode.swift, Sources/CodexBar/MenuBarDisplayText.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.