Menu bar spacing is way too wide

[jefftriplett]

I noticed this on my MacBook Air and then today on my studio. I thought maybe my Mac needed to be rebooted, or Thaw was conflicting, but then I noticed the same issue on my Mac Studio.

[clawsweeper]

Codex review: this still needs some work. Reviewed September 25, 2026, 11:55 AM ET / 15:55 UTC.

Summary
The screenshot shows unusually spread-out provider indicators on two Macs. The earlier spacing request led to a shipped Tight padding option, but the report does not establish whether that option, separate-item placement, or another setting produced this result. This remains worth checking rather than treating as a resolved duplicate.

Reproducibility: no. high-confidence reproduction path yet. The two-machine screenshot establishes the visible symptom, but the version, Merge Icons state, layout, gap choice, and saved item placement are unknown.

Next step
A current-release settings comparison is needed to isolate item sizing from saved placement before a focused repair can be specified.

Review details

Best possible solution:

Establish the behavior on the current release with separate indicators and the available gap setting; if CodexBar itself adds excess width, tighten that rendering while preserving users' saved item positions.

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

No high-confidence reproduction path yet. The two-machine screenshot establishes the visible symptom, but the version, Merge Icons state, layout, gap choice, and saved item placement are unknown.

Is this the best way to solve the issue?

Unclear. Tight padding and Merge Icons already provide narrower presentations; the right code change depends on whether the remaining space comes from rendered item widths or macOS item placement.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The screenshot does not distinguish excess item width from saved macOS placement, and the installed version and relevant settings are unknown.

Codex review notes: model internal, reasoning medium; reviewed against 51898f3e5c04.

Label changes

Label changes:

• add P2: The reported spacing consumes substantial menu bar space on two Macs, but no blocked workflow is shown.
• add impact:ux-friction: Wide gaps make several provider indicators harder to fit and scan in the menu bar.
• add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.
• add clawsweeper:needs-info: Current issue advisory state selects this label.

Label justifications:

• P2: The reported spacing consumes substantial menu bar space on two Macs, but no blocked workflow is shown.
• impact:ux-friction: Wide gaps make several provider indicators harder to fit and scan in the menu bar.

Evidence reviewed

What I checked:

• Reporter screenshot: The supplied 703-pixel image shows multiple provider indicators with large visible spaces between several of them; the report says this appeared on both a MacBook Air and a Mac Studio. The image does not identify the app version or menu bar settings.
• Separate and merged status items: The controller displays one merged item when Merge Icons is enabled and creates individual provider items otherwise. (Sources/CodexBar/StatusItemController.swift:761, 51898f3e5c04)
• Existing controls: Menu Bar settings expose Merge Icons, while the layout editor exposes a Tight or Regular gap choice. (Sources/CodexBar/PreferencesMenuBarPane.swift:71, 51898f3e5c04)
• Gap scope: The Tight choice reduces calculated padding from 10 to 3 points for rendered layouts; legacy rendering instead uses the variable status-item length, so this setting cannot alone explain all spacing between separate items. (Sources/CodexBar/MenuBarLayoutRenderer.swift:226, 51898f3e5c04)
• Placement history: Recent menu bar work preserves saved item positions across hide and removal, making saved placement a plausible path to inspect without establishing it as the cause here. (Sources/CodexBar/MenuBarStatusItemPlacementPreservation.swift:3, 70941c8f7fe8)
• Released spacing option: The merged layout-editor pull request closed the earlier spacing request, and its Tight/Regular width calculation is present in v0.66.0. This does not establish the reporter's installed version or resolve the pictured spacing. (Sources/CodexBar/MenuBarLayoutRenderer.swift:230, e665cbf64976)

Likely related people:

• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Petr Kratochvíl: Raw commit 70941c8 adds Sources/CodexBar/MenuBarStatusItemPlacementPreservation.swift:3 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: medium; commits: 70941c8f7fe8; files: Sources/CodexBar/MenuBarStatusItemPlacementPreservation.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.

[jefftriplett]

I'm using Tight padding. Here is a screenshot of that:

I am not using Merged icons (it gets worse when I turn it on)

[steipete]

Thanks @jefftriplett. I compared the status-item renderer and sizing code with v0.65.0 and found no change on the default layout: the synthetic default still measures 56 pt (Regular) / 49 pt (Tight) per status item, and a width golden now pins that. So the extra width most likely comes from a layout token or preset rather than a regression in the default. Could you share which preset or the layout string you use (Settings → Display → Menu Bar → Layout; redact any account labels), the Size and Gap values, the Merge Icons style, and which providers are shown? A screenshot of just the menu-bar strip helps too. Keeping this open until that is known.

[jefftriplett]

@steipete thank you.

I'm using: "All providers", "Icon & percent", with menu bar strip: "Icon" "% Auto %" <-- I fiddled with these and the same gap remains.

Size: Regular
Gap: Tight
Vertical: 0

Merge icons: off

[steipete]

Thanks @jefftriplett for the exact settings. I reproduced Icon + Auto %, Regular size, Tight gap, vertical 0, and separate providers synthetically and compared against v0.65.0. All measured widths and both rendered strips match exactly. Tight uses 43 pt at 5%, 49 pt at 15%, and 57 pt at 100%; it does not reserve the maximum percentage width. The three supplied attachments show settings and the editor preview, so they do not expose the live gap. Keeping this open. One thing that would settle it: could you attach a crop of the affected live menu bar with one CodexBar menu open so its highlighted status-item boundary is visible?

With the menu open, the highlighted area is exactly one CodexBar status item. If the empty space sits inside the highlight, it is our width calculation and I can chase it from your numbers; if it sits between highlights, it is macOS's own spacing between separate status items, which CodexBar does not control and which only merging items avoids.

[jefftriplett]

Thank you for looking. I tried your suggestion of merging, and the new menu bar item is floating way to the left next to Help 😆

Feel free to close, but there's a non-zero chance it's a Thaw.app issue (even though nothing else is being weird). Much appreciated!

[steipete]

Thanks for testing that, @jefftriplett. Merged items landing next to Help is macOS deciding where a new status item goes; you can Command-drag it back to the right, and a menu bar manager such as Thaw or Bartender can also re-order items on its own. Since the measured item widths match 0.65.0 exactly and the gap is between separate items rather than inside one, this looks like the system's spacing between status items (or Thaw's handling of it) rather than a CodexBar regression, so I'll close this as not reproducible in CodexBar. If a crop with a CodexBar menu open ever shows empty space inside the highlighted item itself, please reopen with it and I'll dig back in.

[jefftriplett]

Just noting I killed ControlCenter and SystemUIServer after the latest version from home and it fixed it. It's strange it happened on two machines, but thanks for digging in.

[steipete]

Thanks for the follow-up, @jefftriplett; that's a useful data point. Control Center owns the status-item windows on recent macOS, so restarting it (and SystemUIServer) re-lays out every item, which fits the spacing being a system-side artifact rather than CodexBar's width calculation. Noted alongside the other Tahoe status-item reports in case a pattern emerges.