Reduce gap between multiple providers in menu bar

[IlyaSemenov]

Currently, CodexBar looks like this:

This wastes precious menu bar space with large gaps and rarely-used providers (which #1167 partially addresses).

For comparison, here's how a different (now-abandoned) indie project handles it — clearly a better approach:

• It takes up less space, which is especially helpful on smaller screens (such as 14" Macbooks).
• More importantly, it visually groups the icons into a single cohesive unit, rather than displaying them as individual scattered elements.

[clawsweeper]

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

Summary
Current main still offers separate provider status items or one merged icon, but not the compact multi-glyph group requested here. The idea remains useful, partially overlaps with the hybrid pinning proposal, and needs maintainer direction on interaction behavior before implementation.

Reproducibility: not applicable. as a feature request; the supplied screenshots and current implementation clearly establish the existing layout and the missing grouped presentation.

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
Maintainer sign-off is required on whether this third presentation mode belongs in CodexBar and whether it should reuse the existing merged menu.

Maintainer decision needed

• Question: Should CodexBar add a third menu-bar mode containing multiple provider glyphs in one compact status item, with the whole group opening the existing merged menu?
• Rationale: Current main deliberately supports two presentation models, while this request introduces a third whose interaction contract and maintenance cost cannot be selected from source evidence alone.
• Likely owner: steipete — This is a product-level menu-bar interaction choice, and the repository owner is the clearest available decision owner.
• Options:
  • Grouped item, merged menu (recommended): Add one compact multi-glyph status item that reuses the existing merged menu and provider switcher.
  • Independent glyph targets: Give each glyph its own provider menu inside one visual group, accepting considerably greater AppKit and accessibility complexity.
  • Keep existing modes: Retain separate items and Merge Icons only, coordinating compactness work through the related hybrid-mode discussion.

Review details

Best possible solution:

If accepted, implement one compact status item that renders ordered provider glyphs and opens the existing merged menu, preserving current modes and defaults while avoiding independent per-glyph hit-testing complexity.

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

Not applicable as a feature request; the supplied screenshots and current implementation clearly establish the existing layout and the missing grouped presentation.

Is this the best way to solve the issue?

Unclear until maintainers approve the interaction model; reusing the existing merged menu from one grouped status item is the narrowest maintainable approach.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The issue does not specify whether the grouped glyphs share one menu or retain independent click targets, which leads to substantially different AppKit, accessibility, and lifecycle complexity.
• Adding a third presentation mode may overlap with Merge Icons and Allow selected providers to stay as separate menu bar icons in Merge Icons mode #1167 unless its purpose and settings behavior are narrowly defined.

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

Label changes

Label changes:

• add P3: This is a low-risk menu-bar density and visual-cohesion improvement rather than broken existing behavior.
• add impact:ux-friction: Separate provider status items consume limited menu-bar width and feel visually scattered, particularly on smaller displays.
• 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:fix-shape-clear: 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 low-risk menu-bar density and visual-cohesion improvement rather than broken existing behavior.
• impact:ux-friction: Separate provider status items consume limited menu-bar width and feel visually scattered, particularly on smaller displays.

Evidence reviewed

What I checked:

• Current settings surface: The Menu Bar preferences expose Merge Icons and merged-menu options, but no grouped multi-glyph mode or status-item spacing control. (Sources/CodexBar/PreferencesMenuBarPane.swift, c852c135e10c)
• Current status-item architecture: The controller selects between a merged status item and independent provider status items; it does not implement one status item containing several provider glyphs. (Sources/CodexBar/StatusItemController.swift, c852c135e10c)
• Documented product boundary: The README documents one status item per provider and Merge Icons with a provider switcher as the supported presentation choices. (README.md, c852c135e10c)
• Latest-release comparison: The supplied repository state identifies v0.42.1 as the latest release, while both released documentation and current main still lack the requested grouped presentation. (README.md, 3e05988f5c5f)
• Related request distinction: The related issue proposes keeping selected providers as independent pinned icons while merging the rest; this issue instead asks for several provider glyphs to appear as one cohesive visual group.

Likely related people:

• steipete: As the repository owner and the strongest available routing candidate for a new menu-bar presentation mode, this person is best positioned to decide whether the additional interaction model belongs in CodexBar. (role: likely product and follow-up owner; confidence: medium; files: Sources/CodexBar/StatusItemController.swift, Sources/CodexBar/PreferencesMenuBarPane.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.